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

[Dave Abrahams]

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

> On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>> 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.
>>
>
> Ditto, except that I think there is some value in keeping both (i.e. doing
> nothing): allowing the user to document intent. It would be inconsistent
> and potentially confusing to call the function that returns an
> `UnsafeMutablePointer` `withUnsafePointer`. 

It doesn't return an `UnsafeMutablePointer`, it passes an
`UnsafeMutablePointer` to the body of the closure.

> It's rarely used enough, and the shorter name needlessly raises the
> question of where I'm really "supposed to be" mutating the
> pointee. 

I don't understand; you only have the pointee inside the closure.
That's where you mutate it (obviously?)

> I've not had to use these functions much, but the distinction between
> `Array.withUnsafeBufferPointer(_:)` and
> `Array.withUnsafeMutableBufferPointer(_:)` has conditioned me to
> mutate the pointee using only "mutable" functions.

Not sure if you're just drawing an analogy, but if not, those two
methods are not under discussion here.  They are meaningfully different,
whereas the existing functions are not, and the one currently called
withUnsafePointer is always going to cause people to complain about
having to pass a mutable variable.

As a fallback position, I would suggest we only provide the mutating
one, but with its existing name.  But I still prefer the shorter name.

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

-- 
Dave