[swift-evolution] Marking sort and sorted with rethrows

[Tim Vermeulen]

> True, but the cost of being able to restore the original ordering, when
> that restoration may not be needed at all, is prohibitive.

What about simply restoring the elements, in no particular order? This seems like an easy enough task, and I don’t think it requires the sorting algorithm to allocate any extra memory (in case no error is thrown, at least).

> 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
> 
> 
>