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