<div dir="ltr">Hi Michael,<div><br></div><div>Thank you for working on this proposal!<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 8, 2015 at 7:54 PM, Michael Buckley via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>UnsafePointer and UnsafeMutablePointer both contain initializers to convert from Int and Uint, but Int and UInt lack initializers to convert from UnsafePointer and UnsafeMutablePointer. Over in swift-dev, Dimitri Gribenko proposed adding something like the following initializers to stdlib.</div><div><br></div><div><div>extension UInt {</div><div> init<T>(bitPattern: UnsafePointer<T>) {</div><div> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))</div><div> }</div><div><br></div><div> init<T>(bitPattern: UnsafeMutablePointer<T>) {</div><div> self = UInt(Builtin.ptrtoint_Word(bitPattern._rawValue))</div><div> }</div><div>}</div><div><br></div><div>extension Int {</div><div> init<T>(bitPattern: UnsafePointer<T>) {</div><div> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))</div><div> }</div><div><br></div><div> init<T>(bitPattern: UnsafeMutablePointer<T>) {</div><div> self = Int(Builtin.ptrtoint_Word(bitPattern._rawValue))</div><div> }</div><div>}</div></div><div><br></div><a href="https://bugs.swift.org/browse/SR-131" target="_blank">https://bugs.swift.org/browse/SR-131</a><br><div><br></div><div>There are two motivations behind this proposal. First, it would allow more complicated pointer arithmetic, such as checking pointer alignment. Second, some C functions take intptr_t and uintptr_t parameters, which are not compatible with UnsafePointer.</div><div><br></div><div>As noted in UnsafePointer.swift.gyb the conversions from UInt and Int are fundamentally unsafe, and these proposed conversions would also be unsafe. They would also allow for more unsafe pointer arithmetic operations. For example, it would allow users to convert two UnsafePointers to UInt8s in order to find the distance between them, which would be a problem if the user subtracted the larger pointer from the smaller pointer.</div></div></blockquote><div><br></div><div>Another use case is tagged pointers, which there are at least two flavors of: Lisp-style (low bits are the tag), or NSString-style (the pointer payload contains character data).</div><div> </div><div>We could consider adding APIs for tagged pointers, too (although I'm concerned that an API that exposes the operations with zero overhead would be probably as unsafe as direct arithmetic and possibly more clumsy and less readable).</div><div><br></div><div>A meta point is, though, that Swift, being a systems programming language, should allow expressing these patterns (working with alignment, creating tagged pointers), and any other things people might imagine (e.g., a XOR linked list) directly in the language, without builtins.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Because of this, and because it's part of the Swift evolution process, it's worth considering alternatives. Pointer arithmetic could be taken care of by adding functions to UnsafePointer, and these may be worth proposing separately. I'm thinking something like this.</div><div><br></div><div><div style="font-size:13px">func distanceToBoundary(_ boundary: Int) -> Int {</div><div style="font-size:13px"> return Int(Builtin.ptrtoint_Word(self._rawValue)) % boundary</div><div style="font-size:13px">}</div><div style="font-size:13px"><br></div><div style="font-size:13px">func isAlignedToBoundary(_ boundary: Int) -> Bool {</div><div style="font-size:13px"> return distanceToBoundary(boundary) == 0</div><div style="font-size:13px">}</div></div></div></blockquote><div><br></div><div>Then one would also need two other methods, I think: to align the pointer to the nearest boundary, up and down.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>As for intptr_t parameters, the only alternative I can think of is to require users to write adaptor functions in C. Requiring users to write C code also works for pointer alignment and other pointer arithmetic, but it doesn't feel like a great solution to the problem.</div><div></div></div></blockquote></div><div class="gmail_extra"><br></div>Even writing wrappers for intptr_t doesn't feel great. One of the goals is to be able to wrap C libraries and improve their API by augmenting with Swift code to the extent possible (for multiple reasons).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Dmitri<br><div><br></div>-- <br><div class="gmail_signature">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div>
</div></div></div>