> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution
> <swift-evolution@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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
