> * What is your evaluation of the proposal? It makes sense to have `assignFrom` and `initializeFrom` defined for `UnsafePointer` sources.
I would much rather see them defined simply with `UnsafePointer` rather than having overloads. The ability to use UnsafeMutablePointer with UnsafePointer parameters is not so much compiler magic as it is an acknowledgement of how memory works. Defining `assignBackwardFrom` for an `UnsafePointer` source is unneeded, because its purpose is copying between overlapping ranges of memory — that’s destructive. The source range of `assignBackwardFrom` *must* be an `UnsafeMutablePointer`, by definition. This being said, C’s memmove has a `const void*` source, even though the ranges may overlap. I’d prefer having all three than having none, but IMO the best outcome is to change only the first 2. > * Is the problem being addressed significant enough to warrant a change to > Swift? Yes. This has always seemed like a mistake to me. > * Does this proposal fit well with the feel and direction of Swift? Yes. I like how non-magical these methods are. > * If you have used other languages or libraries with a similar feature, how > do you feel that this proposal compares to those? There’s no need to remember which of memmove() or memcpy() allows overlapping ranges! > * How much effort did you put into your review? A glance, a quick reading, or > an in-depth study? Decades of using pointers informed my thoughts. Cheers, Guillaume Lessard _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
