<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hi everyone!</div><div class=""><br class=""></div><div class="">I have a small change to `UnsafeMutablePointer` that I'd like to pitch here before turning it into a full proposal and I'd love to hear your feedback on it.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">`UnsafeMutablePointer` offers the following methods to copy memory contents non-destructively:</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">func assignBackwardFrom(source: UnsafeMutablePointer<Pointee>, count: Int)</font></div><div class=""><font face="Menlo" class="">func assignFrom(source: UnsafeMutablePointer<Pointee>, count: Int)</font></div><div class=""><font face="Menlo" class="">func initializeFrom(source: UnsafeMutablePointer<Pointee>, count: Int)</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class="">Basically my proposal boils down to adding overloads for these methods to `UnsafeMutablePointer` that take `UnsafePointer` source arguments instead.</div><div class=""><br class=""></div><div class="">Currently it is necessary to cast an `UnsafePointer` to `UnsafeMutablePointer` before using it with one of these methods:</div></div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class="">let source: UnsafePointer<Int> = ...</font></div><div class=""><font face="Menlo" class="">let destination: UnsafeMutablePointer<Int> = ...</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class="">destination.assignFrom(UnsafeMutablePointer(source), count: count)</font></div></div><div class=""><br class=""></div><div class="">I'd like to get rid of these casts. I would argue that they are not only technically unnecessary and add visual noise but that they could actually be a source of confusion.</div><div class="">A cast of an `UnsafePointer` to its mutable variant should throw up a red flag in most cases and even though this case is ultimately innocuous it still increases cognitive load on the reader.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Alternatives:</b></div><div class=""><br class=""></div><div class="">* The obvious alternative is to simply not add these methods. I'd argue that they provide enough benefit to justify their existence while only minimally increasing the stdlib surface area, especially by merit of being overloads.</div><div class=""><br class=""></div><div class="">* One way of working around the overloads would be to, for example, add a `PointerProtocol` to the standard library and make use of that in these methods. However, that would be a much more intrusive change with little immediate (if any) benefit and introduces more questions than it answers.</div><div class=""><br class=""></div><div class="">* Finally, the implicit conversions from `UnsafeMutablePointer<T>` to `UnsafePointer<T>` could be leveraged to work around the need for overloads by dropping the existing methods taking `UnsafeMutablePointer` source arguments. If I had to guess, I'd say that bit of compiler magic probably exists more in service of (Obj)-C interaction and I would be wary to depend on it here. It's also non-obvious from a documentation and auto-completion perspective.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><b class="">Related:</b></div><div class="">I also have a few related items that might make sense to discuss in tandem while we're talking about `UnsafePointer` and friends.</div><div class=""><br class=""></div><div class="">* <i class="">func distanceTo(x: Unsafe(Mutable)Pointer<Memory>) -> Int</i></div><div class="">This is the only other method on `UnsafePointer` and `UnsafeMutablePointer` for which similar overloads might make sense. However, I cannot really see enough of a use case to justify adding overloads here. Also the current methods match protocol requirements whereas the overloads would not.</div><div class=""><br class=""></div><div class="">* <i class="">UnsafeBufferPointer.init()</i></div><div class="">One might argue that if we are not going to (a)buse implicit conversions that we should perhaps also add an explicitly overloaded initializer to `UnsafeBufferPointer` that takes an `UnsafeMutablePointer`. I'd agree that is a minor sore point but this is less problematic to begin with and given that one can already use the implicit conversion here I'm not particularly inclined to add this. Also I'd strongly argue against its symmetrical other (an initializer to `UnsafeMutableBufferPointer` taking an `UnsafePointer`).</div><div class=""><br class=""></div><div class="">* <i class="">`Unsafe(Mutable)Pointer` conversion initializers. </i></div><div class="">The generic conversion initializers for `UnsafePointer` and `UnsafeMutablePointer` suffer from a minor type inference deficiency. For example:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; line-height: normal; font-family: Menlo;" class="">let ptr: UnsafeMutablePointer<Int> = nil</div><div style="margin: 0px; line-height: normal; font-family: Menlo;" class="">let ptr2 = UnsafePointer(ptr) // Error: Cannot invoke initializer for type 'UnsafePointer<_>' with an argument list of type '(UnsafeMutablePointer<Int>)'</div></div><div class=""><br class=""></div><div class="">In this and similar cases, the compiler cannot currently infer the seemingly obvious choice of retaining the same generic parameter without some additional context.</div><div class="">Technically this could be solved by adding non-generic initializers but that seems like a clutch. This is probably a conscious design decision or at least known limitation with the type inference system and should be addressed there.</div><div class=""><br class=""></div><br class=""><div class="">
<div class="">- Janosch</div>
</div>
<br class=""></body></html>