[swift-evolution] [swift-evolution-announce] [Review] SE-0127: Cleaning up stdlib Pointer and Buffer Routines

[Bob Wilson]

I have been looking at the parts of this proposal related to withUnsafe[Mutable]Pointer:

- https://bugs.swift.org/browse/SR-1937: <https://bugs.swift.org/browse/SR-1937:> withUnsafePointer(&x) should have an argument label 'to:’
- https://bugs.swift.org/browse/SR-1956: <https://bugs.swift.org/browse/SR-1956:> `withUnsafePointer` shouldn't take its argument as `inout`

Adding the “to:” argument label seems like an obviously good thing to do for the one-argument version of these functions. Besides that, I'd like to suggest that we remove the 2- and 3-argument versions: withUnsafe[Mutable]Pointers. The naming is already different than the 1-argument functions (plural vs. singular) and the argument label doesn't work so well with multiple arguments. These extra functions are not a complete solution (if you need more than 3 arguments) and they're not used much -- there is only one real use in the stdlib, with one more use in a validation-test. We can replace them by composing nested uses of the 1-argument functions in the few places where they are needed. I have already prototyped that and it seems to work fine.

It is not so clear what to do about SR-1956. (Charlie and I had some comments on this in https://github.com/apple/swift-evolution/pull/437 <https://github.com/apple/swift-evolution/pull/437>.) Jordan raised the objection that when using withUnsafePointer with a global, there is an expectation that you’ll get the same address every time. Removing inout would cause the argument to be passed by value and the address would refer to a copy. Dmitri agreed that this could be a problem. On the other hand, if you don’t care about the address, or if you’re not using a value type, it would indeed be convenient to have a version of withUnsafePointer that does not require an inout argument.

Option 1: Keep inout (not addressing SR-1956). In this case, there’s no reason to have both withUnsafePointer and withUnsafeMutablePointer. If you want to call a function that expects an UnsafePointer, you can give it an UnsafeMutablePointer and there will be an implicit conversion to make it work. I discussed this with Apple’s stdlib team and they recommended that if we have only one function we use the shorter name “withUnsafePointer” and have it use an UnsafeMutablePointer.

Option 2: Fix SR-1956 and have two functions, one with inout and the other not. This would address the inconvenience of not being able to use withUnsafePointer with immutable values, while still supporting the existing behavior. The question then would be what to call these two functions.

- Option 2a. Combine the two existing functions as in Option 1 and use a new name for the non-inout version, e.g., withUnsafePointer(toCopyOf:), so that it won’t be confused with the old function. (That particular name doesn’t work very well when dealing with references to objects, since the object itself would not be copied. I haven’t yet come up with a better name, though.) One advantage of this approach is that we would not need to rush the new function into Swift 3 since it would be an additive change.

- Option 2b. Switch to use withUnsafeMutablePointer for all the cases where you care about the getting the same address. Change withUnsafePointer to be the non-inout version. Charlie suggested that we could have the migrator convert all existing uses on withUnsafePointer in Swift 2 code to use withUnsafeMutablePointer in Swift 3, but I’m not sure how well that would work.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/fda04ad8/attachment.html>