Even if ?? is generally assumed as safe, fatalError would be there to clearly assert what's going on. This is true in general for fatalError, which presence in some code simply means that something could go wrong there, so the regular compilation-level safety cannot be a given. And as forced unwrapping, fatalError - and other failures caused by a precondition - is not something that should be used lightly.
I think that "?? fatalError()" clearly conveys the meaning, is future-proof and could be adopted as a best practice. Elviro > Il giorno 30 giu 2017, alle ore 17:39, Jacob Williams via swift-evolution > <swift-evolution@swift.org> ha scritto: > > I have been persuaded that extending the capabilities of the current ?? > operator has far more advantages than adding a new limited !! operator. While > I initially did not like the usage of the generally-assumed-safe ? for > throwing operations, the clarity provided by having to explicitly state your > ‘fatalError’ or ‘preconditionFailure’ etc, does make it obvious about what is > going on. > > Also, considering how this capability would eventually be possible with ?? > anyways once Never become a true bottom type, it does not make sense to add a > new operator that would essentially become deprecated in a short matter of > time anyways. As many people have stated, the bar for additions to the Swift > language should be, and is, exceptionally high. There just aren’t enough > pro’s for the !! operator to make it worthwhile. > >> On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> These are all excellent points. I also feel they sidestep the motivation of >> the proposal. Even if there were a bottom `Never` and you could use `?? >> fatalError()`, I still think the language would benefit from `!!`. >> >> As the language is right now, you can write your own "or die" function using >> a `guard` statement, overloading `??`, or implementing `!!`. Being able to >> duplicate an explanatory fail path isn't the point. Offering a >> best-practices alternative to `!!` that is easy to use, obvious to >> understand, and simple to adopt is. >> >> As for the `#line` and `#file` issue, that is my biggest concern but I >> believe that can be surmounted. >> >> -- E >> >> >> >>> On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon <br...@architechies.com >>> <mailto:br...@architechies.com>> wrote: >>> >>>> On Jun 27, 2017, at 10:16 AM, 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 >>> >>> Finally found a few minutes to read this thread. >>> >>> I'm a big fan of the `Never`-based approach. (I was before, but I am more >>> so now.) Here are the points I can see in its favor: >>> >>> 1. It is extremely clear about what's happening—`!!` is another random >>> operator to learn, but `fatalError(_:)` or `preconditionFailure(_:)` are >>> fairly self-explanatory, and `??` is something you might already be using. >>> >>> 2. It allows you to control the optimization behavior by using >>> `fatalError`, `preconditionFailure`, or `assertionFailure` as desired. >>> >>> 3. If we later change `throw` from being a statement to being a >>> `Never`-returning expression, you could use `throw` on the right-hand side >>> of `??`. >>> >>> 4. It supports other `Never`-returning operations, like `abort()` or >>> `exit(_:)` or your custom `usage()` function, on the right side of `??`. >>> >>> 5. It supports file-and-line error reporting without having to add any new >>> features; `!!` could not do this because an operator can't have extra, >>> defaulted parameters to carry the file and line. >>> >>> 6. It harmonizes with the eventual idea of making `Never` a universal >>> bottom type, but we don't actually have to implement that today, because we >>> can just overload `??` for now. >>> >>> Against these advantages, the only one I can see for `!!` is that it is >>> terse. Terseness is good, especially for a feature which is competing with >>> the single-character postfix `!` operator, but I can't help but be drawn to >>> the flexibility and power of `??` with a `Never` expression on the >>> right-hand side. >>> >>> -- >>> Brent Royal-Gordon >>> Architechies >>> >> >> _______________________________________________ >> 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
