<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="">These are good points, Brent.<div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 29, 2017, at 11:24 PM, Brent Royal-Gordon 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 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></div></blockquote><div><br class=""></div><div><font face="Menlo" class=""><span style="font-size: 11px;" class="">!!</span></font> is also clear about what’s happening, because it’s just like the existing <font face="Menlo" class=""><span style="font-size: 11px;" class="">!</span></font> operator.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">2. It allows you to control the optimization behavior by using `fatalError`, `preconditionFailure`, or `assertionFailure` as desired.</div></div></blockquote><div><br class=""></div><div>Yep. That’s cool.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></blockquote><div><br class=""></div><div>Neat idea. 👍 </div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></blockquote><div><br class=""></div><div>Yep. That’s cool.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" 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></blockquote><div><br class=""></div><div>Erica’s proposal addresses this. Allowing operator functions to accept more than 2 parameters that all have default arguments looks like it would be a pretty straight-forward and non-controversial change. It would also allow the FRP crowd to make their <font face="Menlo" class=""><span style="font-size: 11px;" class=""><~</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">|></span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">ಠ_ಠ</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">(╯°□°)╯︵ ┻━┻</span></font> operators all capture the <font face="Menlo" class=""><span style="font-size: 11px;" class="">#file</span></font> and <font face="Menlo" class=""><span style="font-size: 11px;" class="">#line</span></font> they’re used on, which would make debugging those style of apps <i class="">much</i> easier.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><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></div></blockquote><div><br class=""></div><div>Yep. That’s cool.</div><br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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></div></blockquote><div><br class=""></div><div>I would argue that terseness is a goal of Swift. If it weren’t, we shouldn’t have <font face="Menlo" class=""><span style="font-size: 11px;" class="">[Element]</span></font> as sugar syntax for <font face="Menlo" class=""><span style="font-size: 11px;" class="">Array<Element></span></font>, or even a bunch of our operators (postfix <font face="Menlo" class=""><span style="font-size: 11px;" class="">!</span></font>, postfix <font face="Menlo" class=""><span style="font-size: 11px;" class="">?</span></font>, overflow checking operators, nil coalescing, etc). </div><div><br class=""></div><div>IMO, having both <font face="Menlo" class=""><span style="font-size: 11px;" class="">!!</span></font> that takes an error message and <font face="Menlo" class=""><span style="font-size: 11px;" class="">??</span></font> that takes a <font face="Menlo" class=""><span style="font-size: 11px;" class="">() → Never</span></font> seem like worthwhile goals. The former allows me to be terse, yet still expressive, and the latter allows me the customization to do what I want for whatever is contextually appropriate in my situation.</div><div><br class=""></div><div>I don’t think anyone is arguing that <font face="Menlo" class=""><span style="font-size: 11px;" class="">?? () → Never</span></font> <i class="">isn’t</i> useful. The purpose of this proposal is to put forward and defend the claim that “<font face="Menlo" class=""><span style="font-size: 11px;" class="">!! String</span></font>” is <i class="">also</i> useful and meets the barrier to entry in to the Standard Library.</div><div><br class=""></div><div>Dave</div><div><br class=""></div></div></div></body></html>