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

Max Moiseev moiseev at apple.com
Tue Jun 27 20:16:27 CDT 2017


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170627/80f16c40/attachment.html>


More information about the swift-evolution mailing list