[swift-evolution] [Discussion]: Deprecate !-Unwrapping of Optionals
Charles Kissinger
crk at akkyra.com
Mon Feb 29 23:51:14 CST 2016
> On Feb 29, 2016, at 4:41 PM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>
> 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.
To me, the use of an exclamation point for forced unwrapping is a great choice. It suggests caution, just as it does when it appears on warning signs. I already feel apprehensive on the rare occasions when I use forced unwrapping, even though I know it’s the proper choice.
—CK
>
>> 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
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
More information about the swift-evolution
mailing list