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

Erica Sadun erica at ericasadun.com
Fri Jun 30 10:31:22 CDT 2017


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> 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
> 

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


More information about the swift-evolution mailing list