[swift-evolution] Marking sort and sorted with rethrows

[Dave Abrahams]

on Mon Jun 06 2016, Saagar Jha <saagarjha28-AT-gmail.com> wrote:

> Might I add that leaving an array in an arbitrary and
> implementation-dependent state is also surprising to users as well as not
> very useful-to the user this is nothing more than a random permutation.

True, but the cost of being able to restore the original ordering, when
that restoration may not be needed at all, is prohibitive.  It's often
the case that the caller will be throwing away the partially-modified
original when an error is thrown.

> On Mon, Jun 6, 2016 at 5:31 PM Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> 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
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>

-- 
Dave