[swift-evolution] Marking sort and sorted with rethrows
jordan_rose at apple.com
Wed Jun 8 15:46:07 CDT 2016
> 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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution