> On 29 Jun 2017, at 09:19, Elviro Rocca via swift-evolution 
> <[email protected]> wrote:
> 
> 
>> Il giorno 29 giu 2017, alle ore 03:18, Ben Cohen via swift-evolution 
>> <[email protected]> ha scritto:
>> 
>> Finally, there’s a woolier justification: there’s an often-touted 
>> misconception out there that force unwraps are bad, that they were only 
>> created to accommodate legacy apps, and that force-unwrapping is always bad 
>> and you should never do it. This isn’t true – there are many good reasons to 
>> use force unwrap (though if you reaching for it constantly it’s a bad sign). 
>> Force-unwrapping is often better than just whacking in a default value or 
>> optional chaining when the presence of nil would indicate a serious failure. 
>> Introduction of the `!!` operator could help endorse/encourage the use of 
>> “thoughtful” force-unwrapping, which often comes with a comment of the 
>> reasoning why it’s safe (of why the array can’t be empty at this point, not 
>> just that it is empty). And if you’re going to write a comment, why not make 
>> that comment useful for debugging at the same time.
>> 
> 
> If one could still just "!" I'm not sure that the "!!" would really encourage 
> a more thoughtful force unwrapping. Almost every crash related to a force 
> unwrap that I see from Swift beginners is 100% due to the fact that adding 
> and exclamation point makes the code compile, so they add it.
> 
> Also, I strongly disagree with your statement that the idea that 
> force-unwraps are bad is a misconception: if something is Optional, there's a 
> reason why it is, otherwise it would not be Optional at all, and that's the 
> reason why Optional exists in Swift and represents a substantial 
> technological advancement over Objective-C. Using an Optional means that we 
> are actually adding a thoughtful information to an instance: it could be 
> there, or it could not, and that's perfectly fine. Crashing an app in 
> production for a force-unwrap results in the poorest user experience ever, 
> and it should never happen.

If forced unwraps are only used in instances where you specifically expect the 
optional to not be nil, it is essentially sugar for a guard with 
preconditionFailure: it is used to enforce invariants the app should never 
break. It is very similar to a trap when accessing an out of bounds index in an 
array. In those cases, I actually prefer it crashing than having the app 
silently fail for the user, and you never finding out.

I try to limit my use of optional unwrapping but there are sometimes quite 
useful. IMHO, they are not inherently bad, but can be badly used.

> I feel compelled to link another article, where Soroush Khanlou shows that 
> sometimes the bare semantics of an Optional (that is, something is there or 
> not) is not enough: http://khanlou.com/2017/03/that-one-optional-property/
> 
> I also disagree with the idea that the "?? fatalError()" alternative suffers 
> from cognitive dissonance, for the following reasons:
> 
> - on the right of the "??" operator there could be both an Optional or a 
> non-Optional, which would result in a different type for the resulting 
> instance;
> - fatalError() by itself is an operation that changes the meaning of a 
> function, making it non-total, and its very name conveys a clear meaning to a 
> person that reads the code, thus it really doesn't seem to me that "?? 
> fatalError()" could be misinterpreted;
> 
> Anyway, it would be interesting to consider "!! message" as an alternative to 
> "!", thus forcing the user to at least do extra effort: that could discourage 
> a light use of !.
> 
> 
> Elviro
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to