[swift-evolution] Marking sort and sorted with rethrows

[Jordan Rose]

> On Jun 8, 2016, at 11:06, Dave Abrahams via swift-evolution <swift-evolution at 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 <brent at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160608/efd657fa/attachment.html>