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

[Developer]

Whoops, I meant "it is never safe in general to dereference arbitrary memory". 

~Robert Widmann

2016/02/29 13:50、Developer <devteam.codafi at gmail.com> のメッセージ:

> The point is there *are* graceful ways of handling this that aren't unwrapping.  See all the language features I mentioned in the original.  There is really very little excuse to use a dereference operator all the same without a guard, precondition, or other static guarantee, and the language has given you the tools, many times over, to write those kinds of sanity checks.
> 
> Which is why I don't follow the logic for keeping ! around.  In C and Objective-C, it is _never_ safe to dereference memory, even in cases where you have reasonable certainty about its validity.  It seems to me making it more explicit where that logic gap is covered by intuition leads to higher quality code. 
> 
> ~Robert Widmann
> 
> 2016/02/29 12:08、David Owens II <david at owensd.io> のメッセージ:
> 
>> 
>>> On Feb 29, 2016, at 6:54 AM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> I have to clarify here: I am not taking about .!, as!, as?, ?, etc.  I am taking about making naked bang-unwrapping more difficult.  That is, those cases when you write
>>> 
>>> let thing = optVal!
>>> 
>>> These are equivalent to naked unguarded dereferences in C-like languages and are, we can all agree, a code smell, not a feature.  One would not ever recommend to a user of such languages that * or -> be used before checking that an object or region of memory was non-NULL.  So, too, should we discourage this case by removing postfix-! from the language itself (notice it isn't even an operator, it is actually a part of the language).
>> 
>> I don't agree with this assertion. There are _many_ cases where you don't check for the pointer being null before accessing it. Those are programmer errors when the data is null. If there is no graceful way for the program to handle that case, what's the point of silently failing? Maybe later you come along because something keeps coming up with a null problem that you can't track down so you build something around it to recover.
>> 
>> I also don't see `let thing = unwrap(optVal)` or `let thing = optVal.unwrap()` as significantly better. The functionality still needs to be there, and this version is only slightly easier to grep vs. !.
>> 
>> -David