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:
> 
>       
> https://github.com/apple/swift-evolution/blob/master/proposals/0016-initializers-for-converting-unsafe-pointers-to-ints.md
> 
> Reviews are an important part of the Swift evolution process. All reviews 
> should be sent to the swift-evolution mailing list at:
>       https://lists.swift.org/mailman/listinfo/swift-evolution
> 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.

-Kevin Ballard
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to