[swift-evolution] [Pitch] Introducing the "Unwrap or Die" operator to the standard library
Dave DeLong
delong at apple.com
Wed Jun 28 09:31:58 CDT 2017
From that point of view, shouldn’t we then be talking about removing the postfix unary operator “!”? With this proposal it could just as easily be replaced with: ?? fatalError(“failed nil check”). But I don’t think anyone would take that suggestion seriously, so why are we not taking the idea of !! seriously either?
I really like the idea of having both:
let last = array.last ?? fatalError(“Reason”) // () → Never
let last = array.last !! “Reason”
The first one fits with the idea of Nil Coalescing and explicitly failing because of a precondition failure. Or as Tony put it, it “leaves no other choice … but to do something that dies”. It leaves open the case of having the error removed at certain -O levels.
The second one fits with the idea of logical failure where the operator itself is doing the dying, just like the unary version. And, like the force unwrap operator, it wouldn’t be removed at -Ounchecked.
Dave
> On Jun 28, 2017, at 7:08 AM, Tony Allevato via swift-evolution <swift-evolution at swift.org> wrote:
>
> The idea behind `?? () -> Never` is that it leaves no other choice in the nil case but to do something that dies, and that something is typically a function call like fatalError() that documents well enough the dying so !! would be unnecessary. And since it was pointed out above that this can be done today in the language with an autoclosure, I strongly believe that's the direction we should go vs. defining a new operator.
>
> In other words, !! doesn't fit with Never because it's not the *operator* that's doing the dying, but the right-hand side of that operator.
>
> On Wed, Jun 28, 2017 at 6:04 AM Erica Sadun via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I'll give this a kick around as soon as I get a moment and revise. I am slightly concerned that we discussed variations of this in the past (throwing if memory serves, with `Error` on the rhs) and that it broke the expectations of nil-coalescing.
>
> In general, does everyone prefer `?? () -> Never` or `!! () -> Never`? I can argue both ways, with the goal in reading code as "unwrap or die".
>
> -- E
>
>> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> The compatibility testing revealed no related errors. And the full test suite only shows one that I listed already.
>>
>> Max
>>
>>
>>> On Jun 27, 2017, at 3:28 PM, Xiaodi Wu <xiaodi.wu at gmail.com <mailto:xiaodi.wu at gmail.com>> wrote:
>>>
>>> This solution is nifty indeed, and has the chief advantage of working.
>>> On Tue, Jun 27, 2017 at 16:55 Max Moiseev via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev <adrian.zubarev at devandartist.com <mailto:adrian.zubarev at devandartist.com>> wrote:
>>>>
>>>> How about?
>>>>
>>>> public func ?? <T>(optional: T?, noreturnOrError: @autoclosure () throws -> Never) rethrows -> T {
>>>> switch optional {
>>>> case .some(let value):
>>>> return value
>>>> case .none:
>>>> try noreturnOrError()
>>>> }
>>>> }
>>>>
>>>
>>> Yeah, I saw your email right after I sent mine =)
>>> This works, I tried it and also ran the test suite. There was only one error.
>>>
>>> var s: String = ns ?? "str" as String as String // expected-error{{cannot convert value of type 'NSString?' to expected argument type 'String?'}}
>>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> cannot convert value of type 'String' to expected argument type 'NSString'
>>>
>>>
>>> I now wonder what the effect on the source compatibility suite would be:
>>> https://github.com/apple/swift/pull/10639 <https://github.com/apple/swift/pull/10639>
>>>
>>>
>>> Max
>>>
>>>>
>>>>
>>>> --
>>>> Adrian Zubarev
>>>> Sent with Airmail
>>>>
>>>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution (swift-evolution at swift.org <mailto:swift-evolution at swift.org>) schrieb:
>>>>
>>>>>
>>>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>>>
>>>>>> As you write, this operator becomes sugar for “?? fatalError()” once Never becomes a true bottom type.
>>>>>>
>>>>>> In the meantime, can’t the same thing be accomplished by overloading fatalError so it’s a generic function that returns a discardable result of type T, which in turn calls the Never-returning overload?
>>>>>
>>>>> I like this idea more than adding an extra operator, but overloading fatalError won’t work now because of https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668 <https://github.com/apple/swift/blob/master/stdlib/public/core/Optional.swift#L668>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> On Tue, Jun 27, 2017 at 12:25 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
>>>>>>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>>
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <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/a6ecccb0/attachment.html>
More information about the swift-evolution
mailing list