<div dir="ltr">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.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 6, 2016 at 5:31 PM Dave Abrahams via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
on Sun Jun 05 2016, Haravikk <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
<br>
>> On 5 Jun 2016, at 19:14, Tim Vermeulen via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> Most standard library functions that take a closure allow that<br>
>> closure to throw (and those functions are subsequently marked with<br>
>> rethrows). sort and sorted are exceptions to this. I couldn’t find<br>
><br>
>> this documented anywhere, but I assume this is because sorting can<br>
>> happen in-place and it would be impossible to restore the array to<br>
>> its original state without giving up performance. Correct me if I’m<br>
>> wrong.<br>
>><br>
>> I’d like to propose that we let sort rethrow anyways, and leave the<br>
>> array in an intermediate state (where the elements are in an<br>
>> arbitrary order) when an error is thrown. As long as this is<br>
>> properly documented, this shouldn’t lead to any confusion. Best of<br>
>> all, it would allow sorted to rethrow as well in which there is no<br>
>> room for confusion at all because it doesn’t mutate any of the<br>
>> user’s variables.<br>
><br>
> This sounds reasonable; worst case with in-place sorting is that the<br>
> collection was sorted in one order, and is only partially sorted in a<br>
> new one, but the exception and your handling of it should be able to<br>
> account for this.<br>
><br>
> It will require documentation to be clear that sorting methods should<br>
> take care not to leave anything incomplete if a closure throws; most<br>
> algorithms should be fine since they usually just test the closure<br>
> then swap two values afterwards (where necessary) so there’s nothing<br>
> really to interrupt, but anything that uses some kind of buffering may<br>
> need to be redesigned to ensure there’s a fallback to ensure no<br>
> elements are ever lost.<br>
<br>
Ensuring that no elements are ever lost is not a particularly useful<br>
goal, and not a constraint to which I would want to hold the standard<br>
library.<br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div data-smartmail="gmail_signature"><div dir="ltr">-Saagar Jha</div></div>