[swift-evolution] [Discussion]: Deprecate !-Unwrapping of Optionals

Developer devteam.codafi at gmail.com
Mon Feb 29 18:41:19 CST 2016


To move the discussion forward, perhaps a better analogy is not pointers, but casting.  C++ uses the well-known const_cast, static_cast, and reinterpret_cast, primitives as a sin-tax on the usage of casting.  It makes a fundamentally unsafe operation incredibly obvious, and makes the programmer think twice about asking C++ to violate its internal consistency checks in the name of a “leap of logic” made by the programmer.  While it is possible to use casting safely, just as it is possible to use bang safely, the language makes it clear it doesn’t wish to encourage a bad pattern.  Casting didn’t go away here, casting didn’t get “harder”, but casting in C++ versus C got syntactically heavier and thus makes the programmer pause, if only for a second longer, to consider other options.

> On Feb 29, 2016, at 6:29 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> These are equivalent to naked unguarded dereferences in C-like languages and are, we can all agree, a code smell, not a feature.
> 
> I previously wrote a 463-word post in this thread arguing that these are *not* code smells. Maybe you don't agree with that position, but if you really think "we can all agree" it's a code smell, you're not actually listening to the arguments against you.
> 
> I also object to the idea that these are "unguarded" dereferences. `!` *is* guarded by code which always reliably causes a crash if the value is nil. If this unwrap is guarded:
> 
> 	guard let foo = foo else {
> 		fatalError("foo is nil!")
> 	}
> 	doSomething(foo)
> 
> Then so is this:
> 
> 	doSomething(foo!)
> 
> -- 
> Brent Royal-Gordon
> Architechies
> 



More information about the swift-evolution mailing list