> On 28 Jun 2017, at 15:03, Erica Sadun via swift-evolution > <[email protected]> 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 >> <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> wrote: >>>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev >>>>> <[email protected]> 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 >>>>> ([email protected]) schrieb: >>>>> >>>>>> >>>>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution >>>>>>> <[email protected]> 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 >>>>>>>> <[email protected]> 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 >>>>>>>> [email protected] >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> _______________________________________________ >>>>>>> swift-evolution mailing list >>>>>>> [email protected] >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
