[swift-evolution] [swift-evolution-announce] [Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer
kevin at sb.org
Wed Mar 30 00:48:29 CDT 2016
On Tue, Mar 22, 2016, at 02:35 PM, Chris Lattner wrote:
> Hello Swift community,
> 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:
> Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at:
> or, if you would like to keep your feedback private, directly to the review manager.
> What goes into a review?
> 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:
> * What is your evaluation of the proposal?
+1. It solves a legitimate problem, something that the only non-fragile way to accomplish today is with unsafeBitCast (using hashValue is fragile in that hashValue is not defined as returning the pointer as an integer). Personally, I've wanted to convert pointers into integers so I could format them differently than the default formatting of UnsafePointer (usually so I can skip the leading zeroes), but there's other uses cases too.
Prior to reading the proposal I would have expected this to be solved by adding an .intValue or .uintValue property to UnsafePointer/UnsafeMutablePointer, but I think Int(bitPatern:) and UInt(bitPattern:) is actually a more elegant solution.
> * Is the problem being addressed significant enough to warrant a change to Swift?
Yes. It's rather unfortunate to have to resort to unsafeBitCast() simply to convert a pointer into an integer.
> * Does this proposal fit well with the feel and direction of Swift?
Yes. Using initializers for type conversions is idiomatic, and the "bitPattern:" label makes sense and has precedent.
> * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
Other languages typically use whatever built-in type casting functionality there is. If we were to follow suite, that would actually suggest enabling `somePtr as UInt` for doing the conversion, but Swift doesn't use `as` for doing this kind of type conversion so the initializer approach is the most sensible.
> * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
A quick reading.
More information about the swift-evolution