[swift-evolution] [Pitch] Add overrides with UnsafePointer sources to non-destructive copying methods on UnsafeMutablePointer

Janosch Hildebrand jnosh at jnosh.com
Tue Feb 9 16:34:31 CST 2016

> On 09 Feb 2016, at 22:55, Rob Mayoff via swift-evolution <swift-evolution at swift.org> wrote:
> On Tue, Feb 9, 2016 at 10:53 AM, Janosch Hildebrand via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> Great question.
> I think it might be useful for a case where you don't know if you have overlapping ranges and use `assignBackwardFrom()` defensively?
> 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.)

Thanks for catching that, I didn't think that through properly.

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.

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

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

- Janosch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160209/223b2f51/attachment.html>

More information about the swift-evolution mailing list