<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 8, 2016, at 11:06, Dave Abrahams 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=""><div class=""><br class="">on Wed Jun 08 2016, Chris Lattner <<a href="http://clattner-AT-apple.com" class="">clattner-AT-apple.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">On Jun 8, 2016, at 7:52 AM, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Is there a widely used comparison function that throws?<br class=""></blockquote><br class="">Any comparison function that examines external data related to the instance:<br class=""><br class="">* Sorting filenames by the data in the corresponding files<br class="">* Instances backed by a database where actually loading the data could fail<br class="">* Etc.<br class=""></blockquote><br class="">Ok, instead of using rethrows, would it be a better overall design be<br class="">to define two overloads, one that takes a throwing closure and one<br class="">that doesn’t? This allows the throw-supporting implementation to be<br class="">slower without punishing the normal case..<br class=""></blockquote><br class="">There is *no reason* to do this.<br class=""><br class="">* Most sorting algorithms can be written so that even if the comparison<br class=""> throws, no elements are lost<br class=""><br class="">* Even if elements were lost—though it might indeed be surprising—it's<br class=""> not actually a problem we should solve, especially not by penalizing<br class=""> performance. It's *very* unlikely that a partially scrambled<br class=""> collection is of any use to the caller in real code.<br class=""><br class="">* Giving commit-or-rollback semantics for every operation is not<br class=""> something we should do by penalizing performance. Commit-or-rollback<br class=""> does not compose, and therefore ends up uselessly penalizing<br class=""> performance in compositions.</div></div></blockquote><br class=""></div><div>FWIW Dave gave me most of the same feedback in the discussion on the proof-of-concept pull request: <a href="https://github.com/apple/swift/pull/1527#discussion_r60811569" class="">https://github.com/apple/swift/pull/1527#discussion_r60811569</a></div><div><br class=""></div><div>Jordan</div><br class=""></body></html>