[edblarney]

This is a big thing for Swift - the 'optional' paradigm is totally unavoidable, and heavily affects the code as usage is fairly pervasive.

Not having used them much in the past, I rather don't like them, but I'm aware of the fact they could simply take getting used to.

Anyone chime in on whether or not Optionals are really the 'future of good syntax'? Or they are quirk? Or good in some cases, not for others?

[masklinn]

Optionals should be used sparingly in de-novo Swift code, as the corresponding features (Option/Maybe types) are in other languages (Haskell, Elm, OCaml, Rust, …): only make something an Optional if, well, it's actually optional.

Optionals have lots of syntactic sugar because Swift has to deal with reams of native and objective-c code which is ubiquitously nullable, dealing with that without the syntactic sugar would be nothing short of horrendous. This is also an issue with ported/converted API (which is most of them at this point) as the underlying system tends to leverage nullability extensively (it's a very common Obj-C pattern as nil is a message sink), which is usually left shining through by simple conversion rather than wrap every historical API in a converted Swift version.

[interpol_p]

Optionals being clumsy means you start to eliminate them as you write more Swift. It becomes a carefully considered decision to use an optional in your interface. And the compiler keeps you in line.

I love the compile-time optional support now and severely miss it when using languages that don't have the feature. They are brilliant when you are working with all-Swift code or Objective-C code that has been decorated with nullability keywords.

However optionals become a burden when you are working with old Objective-C code that has not been annotated.