> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution > <swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution> > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
