<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">I think that "?? fatalError()" clearly conveys the meaning, is future-proof and could be adopted as a best practice.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Elviro </div><br class=""><div><blockquote type="cite" class=""><div class="">Il giorno 30 giu 2017, alle ore 17:39, Jacob Williams via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> ha scritto:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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. <div class=""><br class=""></div><div class="">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.<div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 30, 2017, at 9:31 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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 `!!`.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">As for the `#line` and `#file` issue, that is my biggest concern but I believe that can be surmounted.</div><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 29, 2017, at 11:23 PM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 10:16 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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?</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">guard !lastItem.isEmpty else { return }</font></div><div class=""><font face="Menlo" class="">let lastItem = array.last !! "Array must be non-empty"</font></div><div class=""><br class=""></div><div class="">Details here: <a href="https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b" class="">https://gist.github.com/erica/423e4b1c63b95c4c90338cdff4939a9b</a></div><div class=""><br class=""></div><div class="">Thank you for your thoughtful feedback, -- E</div></div></div></blockquote><br class=""></div><div class="">Finally found a few minutes to read this thread.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">2. It allows you to control the optimization behavior by using `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.</div><div class=""><br class=""></div><div class="">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 `??`.</div><div class=""><br class=""></div><div class="">4. It supports other `Never`-returning operations, like `abort()` or `exit(_:)` or your custom `usage()` function, on the right side of `??`.</div><div class=""><br class=""></div><div class=""><div class="">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.</div><div class=""><br class=""></div></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>