[swift-evolution] Marking sort and sorted with rethrows

[Saagar Jha]

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.

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
>
-- 
-Saagar Jha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160607/bec1a5c4/attachment.html>