[swift-evolution] Marking sort and sorted with rethrows

[Dave Abrahams]

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

> Exactly. While rethrows for sort make sense, since there is no user
> variable modification, sortInPlace either needs to revert the array (which
> is potentially expensive) or leave it in an arbitrary state, neither of
> which are good choices. I can’t seem to find any mutating function that
> rethrows, and I think it’s for precisely this reason.

Please trust me when I tell you that that is not the reason.

> On Tue, Jun 7, 2016 at 10:20 AM Dave Abrahams <dabrahams at apple.com> wrote:
>
>>
>> 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
>>

-- 
-Dave