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

[David Hart]

> On 28 Jun 2017, at 15:03, Erica Sadun via swift-evolution <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

Count me in as a strong proponent of ?? () -> Never. We don't need to burden the language with an extra operator just for that.

>> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution <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> 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> wrote:
>>>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev <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
>>>> 
>>>> 
>>>> Max
>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Adrian Zubarev
>>>>> Sent with Airmail
>>>>> 
>>>>> Am 27. Juni 2017 um 21:54:57, Max Moiseev via swift-evolution (swift-evolution at swift.org) schrieb:
>>>>> 
>>>>>> 
>>>>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution <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
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> On Tue, Jun 27, 2017 at 12:25 Erica Sadun via swift-evolution <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
>>>>>>>> 
>>>>>>>> Thank you for your thoughtful feedback, -- E
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>> 
>> _______________________________________________
>> 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/bda9d1dc/attachment.html>