[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library

[Djura Retired Hunter]

> Il giorno 29 giu 2017, alle ore 19:05, Erica Sadun via swift-evolution <swift-evolution at swift.org> ha scritto:
> 
> 
>> On Jun 29, 2017, at 9:13 AM, Dave DeLong <delong at apple.com <mailto:delong at apple.com>> wrote:
>> 
>> My usage of “!!” generally falls in to two big buckets:
>> 
> 
> I've incorporated all the feedback to date and updated the gist:
> 
> https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
> 
> -- E

In my opinion the phrase "An often-touted misconception ... a serious failure." taken from Ben Cohen's comment should not be included in the proposal because, other than being a personal opinion, it's a extremely generic statement that doesn't suggest at all "when" force unwrap is good and it's not useful as a guideline for people that read this things to learn something. Saying things like "this is kind of ok but too much of it is wrong" is not useful.

> // in a custom view controller subclass that only accepts children of a certain kind:
> let existing = childViewControllers as? Array<TableRowViewController> !! "TableViewController must only have TableRowViewControllers as children"
> 

In my opinion this example shows very well how you can always switch the need to force unwrap with a more specific contract for a class, or in other words, with a more specific type. Instead of referring to childViewControllers, you could simply have an array of objects of the specific type that mediates the addition and reference to the underlying "childViewControllers" storage. It uses the type system to enforce correctness.

Now, I'm NOT saying that force unwrapping is always bad, but adding examples like these to a official proposal could make people think that force unwrapping is a perfectly fine thing to do for production code instead of designing types for safety, and safety enforced with a strong type system IS a cornerstone of Swift, like it or not, as reported on swift.org/about: "The most obvious way to write code should also behave in a safe manner. Undefined behavior is the enemy of safety, and developer mistakes should be caught before software is in production. Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run.".


Elviro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170629/b4ea6b9d/attachment.html>