>From that point of view, shouldn’t we then be talking about removing the >postfix unary operator “!”? With this proposal it could just as easily be >replaced with: ?? fatalError(“failed nil check”). But I don’t think anyone >would take that suggestion seriously, so why are we not taking the idea of !! >seriously either?
I really like the idea of having both: let last = array.last ?? fatalError(“Reason”) // () → Never let last = array.last !! “Reason” The first one fits with the idea of Nil Coalescing and explicitly failing because of a precondition failure. Or as Tony put it, it “leaves no other choice … but to do something that dies”. It leaves open the case of having the error removed at certain -O levels. The second one fits with the idea of logical failure where the operator itself is doing the dying, just like the unary version. And, like the force unwrap operator, it wouldn’t be removed at -Ounchecked. Dave > On Jun 28, 2017, at 7:08 AM, Tony Allevato via swift-evolution > <swift-evolution@swift.org> wrote: > > The idea behind `?? () -> Never` is that it leaves no other choice in the nil > case but to do something that dies, and that something is typically a > function call like fatalError() that documents well enough the dying so !! > would be unnecessary. And since it was pointed out above that this can be > done today in the language with an autoclosure, I strongly believe that's the > direction we should go vs. defining a new operator. > > In other words, !! doesn't fit with Never because it's not the *operator* > that's doing the dying, but the right-hand side of that operator. > > On Wed, Jun 28, 2017 at 6:04 AM Erica Sadun via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 > >> On Jun 27, 2017, at 7:16 PM, Max Moiseev via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 <xiaodi...@gmail.com >>> <mailto:xiaodi...@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@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> On Jun 27, 2017, at 1:03 PM, Adrian Zubarev >>>> <adrian.zuba...@devandartist.com <mailto:adrian.zuba...@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@swift.org <mailto:swift-evolution@swift.org>) schrieb: >>>> >>>>> >>>>>> On Jun 27, 2017, at 10:38 AM, Xiaodi Wu via swift-evolution >>>>>> <swift-evolution@swift.org <mailto: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 <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 <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 <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 <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 <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
