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

[Dave Abrahams]

on Fri Jul 22 2016, Bob Wilson <swift-evolution at swift.org> wrote:

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

Very much in favor of Option 1.

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

We do not need to support new use-cases in this release, and this would
be unsatisfying because the “address of a global” property that Jordan
argued for would not hold for the immutable version.

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

Not rushing that into Swift 3 is the same as Option 1.

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

That's exactly the same outcome, with respect to the language/library
surface, as Option 2 AFAICT.  Can we simplify this list of options?

-- 
Dave