[Review] SE-0016 - Adding initializers to Int and UInt to convert from UnsafePointer and UnsafeMutablePointer

Evolution Announcements
1

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:

  swift-evolution/0016-initializers-for-converting-unsafe-pointers-to-ints.md at master · apple/swift-evolution · GitHub

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?
  * Is the problem being addressed significant enough to warrant a change to Swift?
  * Does this proposal fit well with the feel and direction of Swift?
  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

  swift-evolution/process.md at master · apple/swift-evolution · GitHub

Thank you,

-Chris Lattner
Review Manager

2

  * What is your evaluation of the proposal?

+1

  * Is the problem being addressed significant enough to warrant a change to Swift?

Yes, the current-state leaves one unable to do certain things in pure Swift (e.g. tagged pointers) that are clearly useful on occasion.

  * Does this proposal fit well with the feel and direction of Swift?

I do think from the alternatives mentioned that the suggested approach is the cleanest. This sort of programming clearly belongs in the “unsafe” corner, but that doesn’t mean one shouldn’t be able to express these sorts of things in Swift.

  * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

I have not used any aspiring system programming languages that didn’t allow manipulating pointers as integer values.

  * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A quick read of the proposal.

  Daniel.

3

I give the concept a +1. Swift should support dangerous actions but should make them clear and obvious. I do think that there is room to improve the argument label. There are two issues with "bitPattern" that concern me:
1) it should be clear that it will be the bitPattern of the pointer itself not whatever the pointer refers to.
2) it doesn't indicate the danger of using the results of this

I don't have a great alternative to bitPattern but maybe something like: "rawMemoryAddress"

I've read the proposal and given it a little bit of thought but have not yet read preceding or recent comments.

Joseph

···

On Mar 22, 2016, at 9:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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

4

* What is your evaluation of the proposal?

I support this. Currently this requires the use of unsafeBitCast, which works okay but is unwieldy.
I used unsafeBitCast to implement tagged pointers in a previous exploratory project, and I think this proposal would improve readability without being an inducement to recklessness.

“bitPattern” is a decent label, but that is also used for the lossy int-to-int conversions; pointer-to-int casting may be different enough to warrant a different label. “unsafeAddress” comes to mind, but may clash with the similarly-named function.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Like uintptr_t, this requires an intentional step in order to do bit operations on pointers.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A careful read and some experience trying this in swift.

Cheers,
Guillaume Lessard

5

+1

I agree with all of the feedback so far, and I think bitPattern is a good label name.

The dangerous case is the UInt to UnsafePointer conversion that already exists. If we allow that, then adding symmetry is only natural.

I’ll add that I don’t particularly like the practice of using unsafeBitcast on pointer values. It does not sufficiently inform the compiler that the type system is being circumvented because no information is carried through to the point of access. UInt to UnsafePointer has the same problem, but I like the fact that a separate, explicit API is used when pointers are involved.

-Andy

···

On Mar 22, 2016, at 2:35 PM, Chris Lattner <clattner@apple.com> wrote:

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

6

Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1.
(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)

Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splittingUnsafe[Mutable]Pointer into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic

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.

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.

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?**

I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience.

Russ

^ Seriously... This kind of failure has to be responsible for billions of dollars in damages by now. It's an extremely common error.

** 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.

···

On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

7

* What is your evaluation of the proposal?

-1

* Is the problem being addressed significant enough to warrant a change to Swift?

No `UnsafePointer` and `UnsafeMutablePointer` already provide their address as Int by their `hashValue` property (maybe add a dedicated `address` property that returns this???), this means it is already possible to do XOR on the addresses of two pointers.

* Does this proposal fit well with the feel and direction of Swift?

No, UnsafePointer and UnsafeMutablePointer etc. should be only used in rare cases e.g. interaction with C APIs or similar.
But maybe there should be a dedicated `address` property as `hashValue` seems to be a bit non obvious.

* If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

Everything in the proposal is already possible and if one creates a XOR operator for unsafe pointers via their `hashValue` it
does not differ too much from doing the same thing in a language like C.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Implemented functions that make use of XORing unsafe pointers in Swift.

8

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. While it is tempting to have the full power of converting pointers to
ints, it's a recipe for security issues as already mentioned.

        * Does this proposal fit well with the feel and direction of Swift?

No. Swift feels safer than doing raw pointer arithmetic.
I'm for the alternative mentioned in the proposal (comments inline):

...The next alternative was to add functions to Unsafe[Mutable]Pointer which
covered the identified pointer arithmetic cases. This alternative was
rejected because it either would have required us to imagine every use-case
of pointer arithmetic [...] or it would have required adding a full suite
of arithmetic and bitwise operators to Unsafe[Mutable]Pointer.
I think the full suite is worth eliminating potential raw pointer
arithmetic bugs.

Because some of these operations are defined only on signed integers, and
others on unsigned, it would have required splitting
Unsafe[Mutable]Pointer into
signed and unsigned variants, which would have complicated things for users
who did not need to do pointer arithmetic.
What operations are defined only on signed/unsigned ints?

Additionally, the implementations of these operations would have probably
converted the pointers to integers, perform a single operation, and then
convert them back. When chaining operations, this would create a lot of
unnecessary conversions.
Isn't that for the optimizer to optimize?

        * How much effort did you put into your review? A glance, a quick

reading, or an in-depth study?

A quick reading.

···

On Tue, Mar 22, 2016 at 11:35 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:

More information about the Swift evolution process is available at

        https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

9

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

···

On Tue, Mar 22, 2016, at 02:35 PM, Chris Lattner wrote:

10

Just for note, an alternative that works right now (whether intentional or not) is this:

let rawAddress: Int = UnsafeMutablePointer<UInt8>(nil).distanceTo(myPointer)

This gives the distance in bytes (so on 95% of all platforms, the raw address). It currently isn't clear that this is how you can accomplish this in swift, so I'm +1 on the proposal.

···

--
Richard

On Mar 22, 2016, at 8:24 PM, Joseph Lord via swift-evolution <swift-evolution@swift.org> wrote:

On Mar 22, 2016, at 9:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> 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

I give the concept a +1. Swift should support dangerous actions but should make them clear and obvious. I do think that there is room to improve the argument label. There are two issues with "bitPattern" that concern me:
1) it should be clear that it will be the bitPattern of the pointer itself not whatever the pointer refers to.
2) it doesn't indicate the danger of using the results of this

I don't have a great alternative to bitPattern but maybe something like: "rawMemoryAddress"

I've read the proposal and given it a little bit of thought but have not yet read preceding or recent comments.

Joseph
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.swift.org_mailman_listinfo_swift-2Devolution&d=CwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=Ezje1IF3xGXfUMfsj4fBc7oM7BcJys1dhQ6psfXzLMU&m=i019xuJ4IOUV9q48MCnS9R5K_9HDaAIqAAGCp9-HX_k&s=W8720bY71AVSU3_XbLpWfFEh9Vmh9qMh1YTnodVcUHs&e=

11

* What is your evaluation of the proposal?

I support this. Currently this requires the use of unsafeBitCast, which works okay but is unwieldy.
I used unsafeBitCast to implement tagged pointers in a previous
exploratory project, and I think this proposal would improve
readability without being an inducement to recklessness.

“bitPattern” is a decent label, but that is also used for the lossy
int-to-int conversions;

No, we never use “bitPattern” for those conversions. We have
“truncatingBitPattern” where conversions are lossy.

···

on Thu Mar 24 2016, Guillaume Lessard <swift-evolution@swift.org> wrote:

pointer-to-int casting may be different enough to warrant a different
label. “unsafeAddress” comes to mind, but may clash with the
similarly-named function.

* Is the problem being addressed significant enough to warrant a change to Swift?

Yes.

* Does this proposal fit well with the feel and direction of Swift?

Yes.

* If you have you used other languages or libraries with a similar
feature, how do you feel that this proposal compares to those?

Like uintptr_t, this requires an intentional step in order to do bit operations on pointers.

* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

A careful read and some experience trying this in swift.

Cheers,
Guillaume Lessard

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

--
Dave

12

The use of 'hashValue' to get an address is not something you should rely on; it is very possible we'll decide to change the hashing algorithm for pointers in the future. But "I think a property would be a better API" is certainly still valid and useful feedback.

Jordan

···

On Mar 28, 2016, at 4:47, fukurokujo via swift-evolution <swift-evolution@swift.org> wrote:

* What is your evaluation of the proposal?

-1

* Is the problem being addressed significant enough to warrant a change to Swift?

No `UnsafePointer` and `UnsafeMutablePointer` already provide their address as Int by their `hashValue` property (maybe add a dedicated `address` property that returns this???), this means it is already possible to do XOR on the addresses of two pointers.

13

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).

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.

Jordan

···

On Mar 27, 2016, at 10:01, Russ Bishop via swift-evolution <swift-evolution@swift.org> wrote:

Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1.
(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)

>Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splittingUnsafe[Mutable]Pointer into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic

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.

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.

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?**

I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience.

Russ

^ Seriously... This kind of failure has to be responsible for billions of dollars in damages by now. It's an extremely common error.

** 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.

On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

14

One of the alternatives discussed in the proposal was adding mathematical operators to UnsafePointer so you can manipulate the pointers directly, such as XORing them, checking alignment, etc. I would very much prefer that we add operators and functions to UnsafePointer to express intent.

Converting to Int/UInt is first of all an opportunity for the programmer to screw it up royally (and create massive security holes in the process). I don’t believe supporting operators requires bifurcating into signed/unsigned pointers. Our existing math operators trap on overflow and you must explicitly opt-in to wrapping behavior. For obtaining a distance (which may be negative) we already have distanceTo.

UnsafePointer should have functions to perform various operations while clearly expressing intent, eg: `add(otherPointer: UnsafePointer<T>, limit: Int = Int.max) -> T?` that returns `nil` if the pointer would overflow/underflow. Maybe that’s not the right shape of the API but I strongly feel that we should be discussing that rather than this proposal.

Russ

···

On Mar 28, 2016, at 10:53 AM, Jordan Rose <jordan_rose@apple.com> wrote:

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).

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.

Jordan

On Mar 27, 2016, at 10:01, Russ Bishop via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Thinking through this proposal, I really favor the operator approach rather than adding these conversions so my vote is -1.
(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)

>Because some of these operations are defined only on signed integers, and others on unsigned, it would have required splittingUnsafe[Mutable]Pointer into signed and unsigned variants, which would have complicated things for users who did not need to do pointer arithmetic

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.

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.

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?**

I've had a lot of experience doing rather unsafe things in Swift and my evaluation is based on that experience.

Russ

^ Seriously... This kind of failure has to be responsible for billions of dollars in damages by now. It's an extremely common error.

** 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.

On Mar 22, 2016, at 2:35 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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?
   * Is the problem being addressed significant enough to warrant a change to Swift?
   * Does this proposal fit well with the feel and direction of Swift?
   * If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
   * How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Chris Lattner
Review Manager
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution