[swift-evolution] Marking sort and sorted with rethrows

[Dave Abrahams]

on Sun Jun 05 2016, Haravikk <swift-evolution at swift.org> wrote:

>> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> Most standard library functions that take a closure allow that
>> closure to throw (and those functions are subsequently marked with
>> rethrows). sort and sorted are exceptions to this. I couldn’t find
>
>> this documented anywhere, but I assume this is because sorting can
>> happen in-place and it would be impossible to restore the array to
>> its original state without giving up performance. Correct me if I’m
>> wrong.
>> 
>> I’d like to propose that we let sort rethrow anyways, and leave the
>> array in an intermediate state (where the elements are in an
>> arbitrary order) when an error is thrown. As long as this is
>> properly documented, this shouldn’t lead to any confusion. Best of
>> all, it would allow sorted to rethrow as well in which there is no
>> room for confusion at all because it doesn’t mutate any of the
>> user’s variables.
>
> This sounds reasonable; worst case with in-place sorting is that the
> collection was sorted in one order, and is only partially sorted in a
> new one, but the exception and your handling of it should be able to
> account for this.
>
> It will require documentation to be clear that sorting methods should
> take care not to leave anything incomplete if a closure throws; most
> algorithms should be fine since they usually just test the closure
> then swap two values afterwards (where necessary) so there’s nothing
> really to interrupt, but anything that uses some kind of buffering may
> need to be redesigned to ensure there’s a fallback to ensure no
> elements are ever lost.

Ensuring that no elements are ever lost is not a particularly useful
goal, and not a constraint to which I would want to hold the standard
library.

-- 
Dave