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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
