<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1. </div><div>(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><br></div><div>><span style="background-color: rgba(255, 255, 255, 0);">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%;">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><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>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><br></div><div>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><br></div><div>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><br></div><div>I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience. </div><div><br></div><div>Russ</div><div><br></div><div>^ 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><br></div><div>** 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><br></div><div><br>On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>Hello Swift community,</span><br><span></span><br><span>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><span></span><br><span> <a href="https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md">https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md</a></span><br><span></span><br><span>Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:</span><br><span> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br><span>or, if you would like to keep your feedback private, directly to the review manager.</span><br><span></span><br><span></span><br><span>What goes into a review?</span><br><span></span><br><span>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><span></span><br><span> * What is your evaluation of the proposal?</span><br><span> * Is the problem being addressed significant enough to warrant a change to Swift?</span><br><span> * Does this proposal fit well with the feel and direction of Swift?</span><br><span> * 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><span> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</span><br><span></span><br><span>More information about the Swift evolution process is available at</span><br><span></span><br><span> <a href="https://github.com/apple/swift-evolution/blob/master/process.md">https://github.com/apple/swift-evolution/blob/master/process.md</a></span><br><span></span><br><span>Thank you,</span><br><span></span><br><span>-Chris Lattner</span><br><span>Review Manager</span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>