on Sun Jun 05 2016, Haravikk <swift-evolution@swift.org> wrote: >> 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.
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@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
