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 > <[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] >> <mailto:[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] <mailto:[email protected]>> wrote: >>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev >>> <[email protected] <mailto:[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 >> <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] <mailto:[email protected]>) schrieb: >>> >>>> >>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution >>>>> <[email protected] <mailto:[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 >>>> >>>> <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] <mailto:[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 >>>>> <https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b> >>>>> >>>>> Thank you for your thoughtful feedback, -- E >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <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
