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