<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="">I'm not sure what you mean by "the operator approach". Do you mean measuring the distance between a pointer and nil? That assumes that nil's representation is 0 (which admittedly it is on all our platforms, but which shouldn't really be in anyone's mental model of UnsafePointer).</div><div class=""><br class=""></div><div class="">I'd like to note that (IIUC) one of our goals is to make unsafeBitCast unneccessary; if a conversion is a reasonable thing to do regularly, there should always be a more principled way to do it. Someone's "intuitive" understanding of unsafeBitCast may well be wrong.</div><div class=""><br class=""></div><div class="">Jordan</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Mar 27, 2016, at 10:01, Russ Bishop 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=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""></div><div class="">Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1. </div><div class="">(If you really know what you're doing you can already do an unsafeBitCast so this isn't a problem I've had in the real world)</div><div class=""><br class=""></div><div class="">><span style="background-color: rgba(255, 255, 255, 0);" class="">Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splitting<code style="max-width: 100%;" class="">Unsafe[Mutable]Pointer</code> into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic</span></div><div class=""><span style="background-color: rgba(255, 255, 255, 0);" class=""><br class=""></span></div><div class="">This proposal doesn't solve that problem; it relies on the user selecting the correct conversion and checking for invalid results. It leaves things just as error-prone as C. I think we /can/ do better and /should/ do better. </div><div class=""><br class=""></div><div class="">I'd rather see arithmetic operators on UnsafePointer that trap on overflow/underflow, then some functions for checking common scenarios that people always get wrong (how many exploits begin with "this check attempts to determine if size exceeds a bound or wraps but is completely incorrect..."^). Something like "add(Int, max: UnsafePointer = UnsafePointer.max) -> UnsafePointer?" Which returns nil if the value would exceed max or wrap around. </div><div class=""><br class=""></div><div class="">I guess my main problem is that pointers *are* unsigned. For silly implementation reasons we treat them as signed so we can check some overflow/underflow scenarios but why not just solve the real problem and let people express intent clearly instead of obtusely?**</div><div class=""><br class=""></div><div class="">I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience. </div><div class=""><br class=""></div><div class="">Russ</div><div class=""><br class=""></div><div class="">^ Seriously... This kind of failure has to be responsible for billions of dollars in damages by now. It's an extremely common error. </div><div class=""><br class=""></div><div class="">** I'm aware that on many current CPUs the top N bits are either fixed or extended from the highest valid bit so the hardware doesn't actually need to handle a full 64-bit virtual address space. I'm also aware that many architectures place the kernel address space in the upper range so user mode code never sees "negative" pointers. The address space restriction won't be true forever and Swift should be usable to write kernel mode code/drivers in the future. </div><div class=""><br class=""></div><div class=""><br class="">On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><span class="">Hello Swift community,</span><br class=""><span class=""></span><br class=""><span class="">The review of "Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer" begins now and runs through March 25th. The proposal is available here:</span><br class=""><span class=""></span><br class=""><span class=""> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md</a></span><br class=""><span class=""></span><br class=""><span class="">Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:</span><br class=""><span class=""> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""><span class="">or, if you would like to keep your feedback private, directly to the review manager.</span><br class=""><span class=""></span><br class=""><span class=""></span><br class=""><span class="">What goes into a review?</span><br class=""><span class=""></span><br class=""><span class="">The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:</span><br class=""><span class=""></span><br class=""><span class=""> * What is your evaluation of the proposal?</span><br class=""><span class=""> * Is the problem being addressed significant enough to warrant a change to Swift?</span><br class=""><span class=""> * Does this proposal fit well with the feel and direction of Swift?</span><br class=""><span class=""> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</span><br class=""><span class=""> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br class=""><span class=""></span><br class=""><span class="">More information about the Swift evolution process is available at</span><br class=""><span class=""></span><br class=""><span class=""> <a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br class=""><span class=""></span><br class=""><span class="">Thank you,</span><br class=""><span class=""></span><br class=""><span class="">-Chris Lattner</span><br class=""><span class="">Review Manager</span><br class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>