Well the main debate is that, we all want early access to a feature that will be part of Swift as soon as `Never` becomes the bottom type. When this happens the `??` will automatically support the pitched behavior. Until then if we all agree that we should add it now in a way that will not break anything we can simply add an overload to `??` as I previously showed.
There is no need for `!!` because it will fade in the future. If you think of `Never` as a bottom type now then `??` will already make total sense. The default value for T from rhs might be T or Never. @erica: the rhs argument should be called something like `noreturnOrError` and not `defaultValue`. And we should keep in mind that when Never becomes the bottom type we have to remove that overload from stdlib, because otherwise it will be ambiguous. --- On the other hand if we tackle a different operator then we should rething the 'default value operator' because the second ? signals an optional but not a non-optional or an inplicit unwrapped operator. In that case I personally thing ?! would make more sense. Unwrap or (non-optional | IUO | trap/die) -- Adrian Zubarev Sent with Airmail Am 28. Juni 2017 um 18:13:18, Tony Allevato via swift-evolution (swift-evolution@swift.org(mailto:swift-evolution@swift.org)) schrieb: > > It's hard for me to articulate, but "foo !! message" feels a little too much > like a Perl-ism for my taste. Objectively that's not a great criticism on its > own, but I just don't like the "smell" of an operator that takes a value on > one side and a string for error reporting purposes on the other. It doesn't > feel like it fits the style of Swift. I prefer a version that makes the call > to fatalError (and thus, any other non-returning handler) explicitly written > out in code. > > So, if the language can already support this with ?? and autoclosure/Never as > was shown above, I'd rather see that added to the language instead of a new > operator that does the same thing (and is actually less general). > > On Wed, Jun 28, 2017 at 8:52 AM Jacob Williams via swift-evolution > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > I feel that the !! operator would be necessary for indicating that if this > > fails then something went horribly wrong somewhere and we should throw the > > fatalError. This allows the inclusion of optimizations using -Ounchecked > > and is clear that this is an operation that could result in a runtime error > > just like force unwrapping. > > > > If we want code clarity and uniformity, then I think !! Is much better than > > ?? because it goes right along with the single ! Used for force unwrapping. > > However, this does depend on if the operator would be returning some kind > > of error that would cause the program to exit. > > > > I think the ?? operator should not cause a program to exit early. It goes > > against optional unwrapping principles. I think code could get very > > confusing if some ? would return nil/a default value, and others would be > > causing your program to crash and exit. The ? operators should always be > > classified as safe operations. > > > > > On Jun 28, 2017, at 9:41 AM, Ben Cohen via swift-evolution > > > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > > > > > > On Jun 28, 2017, at 8:27 AM, David Hart via swift-evolution > > > > <swift-evolution@swift.org(mailto:swift-evolution@swift.org)> wrote: > > > > Count me in as a strong proponent of ?? () -> Never. We don't need to > > > > burden the language with an extra operator just for that. > > > > > > You could say the same about ?? > > > > > > The concern that an additional operator (and one that, IMO, fits well > > > into existing patterns) is so burdensome seems way overweighted in this > > > discussion IMO. > > > > > > Adding the operator, and encouraging its use, will help foster better > > > understanding of optionals and legitimate use of force-unwrapping in a > > > way that I don’t think `?? fatalError` could. > > > > > > > > > _______________________________________________ > > > swift-evolution mailing list > > > swift-evolution@swift.org(mailto:swift-evolution@swift.org) > > > 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 > _______________________________________________ > 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
