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

[Xiaodi Wu]

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's rarely used enough, and
the shorter name needlessly raises the question of where I'm really
"supposed to be" mutating the pointee. 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.


> >
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160722/8fb18917/attachment.html>