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

Wed Jun 28 13:42:26 CDT 2017

On Wed, Jun 28, 2017 at 11:15 AM Dave DeLong <delong at apple.com> wrote:

> On Jun 28, 2017, at 10:44 AM, Adrian Zubarev via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Well the main debate is that, we all want early access to a feature that
> will be part of Swift as soon as `Never` becomes the bottom type. When this
> happens the `??` will automatically support the pitched behavior. Until
> then if we all agree that we should add it now in a way that will not break
> anything we can simply add an overload to `??` as I previously showed.
>
>
> I believe we should add it now, but I like the recent observation that
> making ?? suddenly become a potentially crashing operator violates the
> expectation that ? is an indication of safety.
>

?? does *not* become a potentially crashing operator. The *fatalError* (or
whatever else the user chooses to put there) on the right-hand side is the
crashing operation.

> On the other hand, the existing semantics of Swift are that ! is always
> dangerous, so making !! be the a potentially crashing operator is much
> more consistent with the language.
>
> There is no need for `!!` because it will fade in the future. If you think
> of `Never` as a bottom type now then `??` will already make total sense.
> The default value for T from rhs might be T or Never.
>
>
> I respectfully disagree with your absolute position on this topic. Even
> with Never as a bottom type in the future, it would *still* be more
> convenient for me to type:
>
> let last = array.last !! “Array must be non-empty"
>
> … than it ever would be to type:
>
> let last = array.last ?? fatalError(“Array must be non-empty”)
>
>
There is a very high bar for additions to the standard library—a new
operator added to the language is going to be around (1) forever, or (2)
indefinitely with some migration cost to users if it's ever removed.
Shaving off a few keystrokes doesn't quite meet that bar—especially when an
alternative has been shown to work already that provides the same
functionality, is more general (not coupled to fatalError or String
messages), and that fits better into Swift's design.

To make sure I'm not being too much of a downer, I would completely support
this broader feature being implemented by that alternative: the ?? +
autoclosure () -> Never combo. Then once Never does become a true bottom
type, I believe it could be removed and the calling code would still *just
work*.

> Dave
>
>
> @erica: the rhs argument should be called something like `noreturnOrError`
> and not `defaultValue`. And we should keep in mind that when Never becomes
> the bottom type we have to remove that overload from stdlib, because
> otherwise it will be ambiguous.
>
> ---
>
> On the other hand if we tackle a different operator then we should rething
> the 'default value operator' because the second ? signals an optional but
> not a non-optional or an inplicit unwrapped operator. In that case I
> personally thing ?! would make more sense. Unwrap or (non-optional | IUO |
> trap/die)
>
> --
> Adrian Zubarev
> Sent with Airmail
>
> Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution (
> swift-evolution at swift.org) schrieb:
>
>> It's hard for me to articulate, but "foo !! message" feels a little too
>> much like a Perl-ism for my taste. Objectively that's not a great criticism
>> on its own, but I just don't like the "smell" of an operator that takes a
>> value on one side and a string for error reporting purposes on the other.
>> It doesn't feel like it fits the style of Swift. I prefer a version that
>> makes the call to fatalError (and thus, any other non-returning handler)
>> explicitly written out in code.
>>
>> So, if the language can already support this with ?? and
>> autoclosure/Never as was shown above, I'd rather see that added to the
>> language instead of a new operator that does the same thing (and is
>> actually less general).
>>
>> On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution <
>> swift-evolution at swift.org> wrote:
>>
>>> I feel that the !! operator would be necessary for indicating that if
>>> this fails then something went horribly wrong somewhere and we should throw
>>> the fatalError. This allows the inclusion of optimizations using
>>> -Ounchecked and is clear that this is an operation that could result in a
>>> runtime error just like force unwrapping.
>>>
>>> If we want code clarity and uniformity, then I think !! Is much better
>>> than ?? because it goes right along with the single ! Used for force
>>> unwrapping. However, this does depend on if the operator would be returning
>>> some kind of error that would cause the program to exit.
>>>
>>> I think the ?? operator should not cause a program to exit early. It
>>> goes against optional unwrapping principles. I think code could get very
>>> confusing if some ? would return nil/a default value, and others would be
>>> causing your program to crash and exit. The ? operators should always be
>>> classified as safe operations.
>>>
>>> On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>>
>>> On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution <
>>> swift-evolution at swift.org> wrote:
>>>
>>> Count me in as a strong proponent of ?? () -> Never. We don't need to
>>> burden the language with an extra operator just for that.
>>>
>>>
>>> You could say the same about ??
>>>
>>> The concern that an additional operator (and one that, IMO, fits well
>>> into existing patterns) is so burdensome seems way overweighted in this
>>> discussion IMO.
>>>
>>> Adding the operator, and encouraging its use, will help foster better
>>> understanding of optionals and legitimate use of force-unwrapping in a way
>>> that I don’t think `?? fatalError` could.
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> 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
>>>
>> _______________________________________________
>> swift-evolution mailing list
>> 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/20170628/94ae92dd/attachment.html>