<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On 09 Feb 2016, at 22:55, Rob Mayoff via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote">On Tue, Feb 9, 2016 at 10:53 AM, Janosch Hildebrand via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Great question.<br class="">
<br class="">
I think it might be useful for a case where you don't know if you have overlapping ranges and use `assignBackwardFrom()` defensively?<br class=""></blockquote><div class=""><br class=""></div><div class="">You cannot use assignBackwardFrom "defensively" if you don't know whether you have overlapping ranges. If the ranges overlap, and the source range starts after the destination range, then assignBackwardFrom copies destructively. (It overwrites some prefix of the source range with some suffix of the source range, before copying the original prefix to the destination.)</div></div></div></div></div></blockquote><div><br class=""></div><div>Thanks for catching that, I didn't think that through properly.</div><div><br class=""></div><div>Although I think my point still stands. You can have two pointers for which you cannot guarantee that they don't overlap so you need to test and select `assignFrom` or `assignBackwardFrom` appropriately so there is a use case for the `assignBackwardFrom` overload.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">It would be better to just have assignFrom behave like memmove (always non-destructively) and not have assignBackwardFrom at all… but that's not the point of this proposal.</div></div></div></div></div></blockquote><div><br class=""></div><div>I guess performance was considered to be more important than convenience in this case, especially since (potentially) overlapping memory ranges should be a relatively limited occurrence in Swift. Although a point could probably be made for adding a convenience method à la memmove; as you said though, different proposal :-)</div></div><br class=""><div class="">- Janosch</div></body></html>