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

[Elviro Rocca]

Even if ?? is generally assumed as safe, fatalError would be there to clearly assert what's going on. This is true in general for fatalError, which presence in some code simply means that something could go wrong there, so the regular compilation-level safety cannot be a given. And as forced unwrapping, fatalError - and other failures caused by a precondition - is not something that should be used lightly.

I think that "?? fatalError()" clearly conveys the meaning, is future-proof and could be adopted as a best practice.


Elviro  

> Il giorno 30 giu 2017, alle ore 17:39, Jacob Williams via swift-evolution <swift-evolution at swift.org> ha scritto:
> 
> I have been persuaded that extending the capabilities of the current ?? operator has far more advantages than adding a new limited !! operator. While I initially did not like the usage of the generally-assumed-safe ? for throwing operations, the clarity provided by having to explicitly state your ‘fatalError’ or ‘preconditionFailure’ etc, does make it obvious about what is going on. 
> 
> Also, considering how this capability would eventually be possible with ?? anyways once Never become a true bottom type, it does not make sense to add a new operator that would essentially become deprecated in a short matter of time anyways. As many people have stated, the bar for additions to the Swift language should be, and is, exceptionally high. There just aren’t enough pro’s for the !! operator to make it worthwhile.
> 
>> On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> These are all excellent points. I also feel they sidestep the motivation of the proposal. Even if there were a bottom `Never` and you could use `?? fatalError()`, I still think the language would benefit from `!!`.
>> 
>> As the language is right now, you can write your own "or die" function using a `guard` statement, overloading `??`, or implementing `!!`. Being able to duplicate an explanatory fail path isn't the point. Offering a best-practices alternative to `!!` that is easy to use, obvious to understand, and simple to adopt is.
>> 
>> As for the `#line` and `#file` issue, that is my biggest concern but I believe that can be surmounted.
>> 
>> -- E
>> 
>> 
>> 
>>> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>>> 
>>>> On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> Using an operator to provide feedback on the context of a failed unwrap has become a commonly implemented approach in the Swift developer Community. What are your thoughts about adopting this widely-used operator into the standard library?
>>>> 
>>>> guard !lastItem.isEmpty else { return }
>>>> let lastItem = array.last !! "Array must be non-empty"
>>>> 
>>>> Details here:  https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b>
>>>> 
>>>> Thank you for your thoughtful feedback, -- E
>>> 
>>> Finally found a few minutes to read this thread.
>>> 
>>> I'm a big fan of the `Never`-based approach. (I was before, but I am more so now.) Here are the points I can see in its favor:
>>> 
>>> 1. It is extremely clear about what's happening—`!!` is another random operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are fairly self-explanatory, and `??` is something you might already be using.
>>> 
>>> 2. It allows you to control the optimization behavior by using `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.
>>> 
>>> 3. If we later change `throw` from being a statement to being a `Never`-returning expression, you could use `throw` on the right-hand side of `??`.
>>> 
>>> 4. It supports other `Never`-returning operations, like `abort()` or `exit(_:)` or your custom `usage()` function, on the right side of `??`.
>>> 
>>> 5. It supports file-and-line error reporting without having to add any new features; `!!` could not do this because an operator can't have extra, defaulted parameters to carry the file and line.
>>> 
>>> 6. It harmonizes with the eventual idea of making `Never` a universal bottom type, but we don't actually have to implement that today, because we can just overload `??` for now.
>>> 
>>> Against these advantages, the only one I can see for `!!` is that it is terse. Terseness is good, especially for a feature which is competing with the single-character postfix `!` operator, but I can't help but be drawn to the flexibility and power of `??` with a `Never` expression on the right-hand side.
>>> 
>>> -- 
>>> Brent Royal-Gordon
>>> Architechies
>>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170630/04a2b2d1/attachment.html>