What are the current language features of Swift that stand out to you most in your mind?
Think about something that you found especially unique and/or beneficial, something you just feel everybody ought to hear about when seeing Swift for the first time regardless of their experience.
No matter what it is, it would be really interesting for me to see what about Swift touched you in a positive way from your experience and not what you think others want to hear. Don't worry, this is not a quiz!
Protocols, Extensions, Concurrency and many other stuff are all nice but there are tons of languages that supports something similar with somewhat similar usability. But Codable, I haven't seen something that is this easy to use and safe to use at the same time!
Maybe too simple, and you can't not hear about it when starting Swift, but I constantly miss it in other languages: Argument labels on almost all parameters.
It just takes away so many moments of "ok, just gonna check the declaration again to remind me which parameter at this call site is which", especially when browsing unfamiliar code on something like github or somewhere else without tooling to quickly show the signature/docs.
This is perhaps unfair since I help maintain it, but I think the post-UTF8-rewrite implementation of String is one of the more interesting contributions Swift has made to the world. I'm not aware of any other language that attempts anything close to its level of ambition. There are, admittedly, reasons why nobody else has attempted this model (for example, random access indexing being O(n)), but I personally think the benefits are so compelling that over the next 5-10 years we'll see more new languages going down this path.
The two examples I always give to programmers of other languages:
Argument labels and enums.
Enums having the ability to be represented as Strings or Integers makes them more capable than plain C enums, and the ability to go further to have associated data payloads means building highly expressive state machines with the help of the compiler.
The enum is my answer too, and I’d like to point out something not everyone is aware of. If your custom type is expressible as a literal and you use that literal to define the raw values you can make your custom type the raw value type of an enum.
It's one of the original features: Optionals and the mechanisms of optional chaining. Replicated now in even dynamic languages, that single feature drove home the idea of "fully specified" code vs. code with "unspecified results", and has probably been the single most impactful "safety" improvement in terms of the code I've written.
I really love that Swift has such a strong emphasis on value types. Almost every other popular, modern language is object-oriented, from Obj-C, C++, Java, and C#, to Python. But we also know that as programs becomes more complex, the shared mutable state becomes exponentially harder to understand. It leads to bugs, frustrating development, and it's difficult to have a high level of confidence in the code. So Swift greatly de-emphasises reference semantics in favour of values, and even if you have a class, you can wrap it in a struct and use reference counting to cheaply implement copy-on-write makes things easier on yourself.
There have actually been times when I was thinking about some code, wondering if I'd covered every edge-case, then suddenly - Oh, no! I haven't considered that somebody else might be holding a mutable reference to someData! I should make a defensive copy! - then I remember that Swift deals in values. It's just the ghost of a problem I don't need to care about any more.
Generics.
I'm also really happy that they've been given friendlier syntax and that we've finally fixed the existential <-> generics interop trap. I definitely think it'll make generics easier to use.
Personally, I try to write code generic-first. Programming, like all sciences, involves creating models, and I like the clarity of thinking that comes with generics and expressing data in terms of constraints. Every step encodes what it needs to do with its data, and the layer of abstraction makes it easier to stub out operations and fill them in later with minimal changes, and it makes code flow more easily with fewer type conversions.
My vote goes to overall usability and dev friendliness. It's the most beautiful language out there while still being type safe.
Occasionally I go back to C++, and Rust (which I love with all my heart), and they both burn my eyes and fog my mind until I adapt. It's never the other way around.
Swift is the only language with built-in differentiation for gradient descent optimization. Everywhere else, you have to re-implement it from scratch (Python TensorFlow, PyTorch, DL4S, etc.).
dot notation.
Both serve to make your code so much succinct, and it is something I always miss when dabbling with Kotlin.
And yes, argument labels are indispensable. A lot of languages have labeled constructors for structs, yet they eschew them for functions, even though those functions may be convenience constructors.
Really just that ability to make a domain-specific language out of Swift like Regex string processing using function builders or building ML models out of structs and calls to gradient using trailing closures.
My fave bits: Totally optional abbreviations: Skip the closure label, skip the return, skip the parameters, skip the braces, or use them all if you need a high degree of readability.
The result builder stuff is awesome.
No semi colons unless you need 'em.
The top level can be a script if ya wanna, making Swift a potential great system script language replacement.
I am especially pleased with algebraic data types, especially recursive
enums, and binding pattern matches. They have let me write algorithms
for a symbolic calculator and a tree-shaped data structure in a
straightforward way.
Hey Ashley I always thought Apple's guidelines to writing semantic Swift code are unique: Swift.org - API Design Guidelines I feel that Swift has become a very complex language that ought to be difficult to pick up as a beginner. If authors adhered more to these guidelines above, it could make it much, much easier to understand even for people who are just starting with the language.
This is perhaps unfair because I worked on it, but I hope the next generation does better. Don't lazily bridge in a different programming language's string, it's not worth it.
I always thought Apple's guidelines to writing semantic Swift code are unique: 