<div dir="ltr">On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
on Fri Jul 22 2016, Xiaodi Wu <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
<br>
> On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution <<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
><br>
>><br>
>> on Fri Jul 22 2016, Bob Wilson <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> > It is not so clear what to do about SR-1956. (Charlie and I had some<br>
>> > comments on this in <a href="https://github.com/apple/swift-evolution/pull/437" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/437</a><br>
>> > <<a href="https://github.com/apple/swift-evolution/pull/437" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/437</a>>.) Jordan raised<br>
>> > the objection that when using withUnsafePointer with a global, there<br>
>> > is an expectation that you’ll get the same address every<br>
>> > time. Removing inout would cause the argument to be passed by value<br>
>> > and the address would refer to a copy. Dmitri agreed that this could<br>
>> > be a problem. On the other hand, if you don’t care about the address,<br>
>> > or if you’re not using a value type, it would indeed be convenient to<br>
>> > have a version of withUnsafePointer that does not require an inout<br>
>> > argument.<br>
>> ><br>
>> > Option 1: Keep inout (not addressing SR-1956). In this case, there’s<br>
>> > no reason to have both withUnsafePointer and<br>
>> > withUnsafeMutablePointer. If you want to call a function that expects<br>
>> > an UnsafePointer, you can give it an UnsafeMutablePointer and there<br>
>> > will be an implicit conversion to make it work. I discussed this with<br>
>> > Apple’s stdlib team and they recommended that if we have only one<br>
>> > function we use the shorter name “withUnsafePointer” and have it use<br>
>> > an UnsafeMutablePointer.<br>
>><br>
>> Very much in favor of Option 1.<br>
>><br>
><br>
> Ditto, except that I think there is some value in keeping both (i.e. doing<br>
> nothing): allowing the user to document intent. It would be inconsistent<br>
> and potentially confusing to call the function that returns an<br>
> `UnsafeMutablePointer` `withUnsafePointer`.<br>
<br>
</div></div>It doesn't return an `UnsafeMutablePointer`, it passes an<br>
`UnsafeMutablePointer` to the body of the closure.<br></blockquote><div><br></div><div>Brainfart. Yes, that's what I meant to write. Sorry.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> It's rarely used enough, and the shorter name needlessly raises the<br>
> question of where I'm really "supposed to be" mutating the<br>
> pointee.<br>
<br>
</span>I don't understand; you only have the pointee inside the closure.<br>
That's where you mutate it (obviously?)<br></blockquote><div><br></div><div>If my closure does not mutate the pointee, `withUnsafePointer(_:)` allows me to document that. Everything *works* with `withUnsafeMutablePointer(_:)`, but I cannot read the code and understand that no mutation has happened within the body of the closure. [Am I wrong on this?]</div><div><br></div><div>For instance, I've been working with some of the Accelerate.framework functions and the arguments are often cryptic. Take this call:</div><div><br></div><div>```</div><div>cblas_sgemm(CblasColMajor, CblasNoTrans, CblasNoTrans, m, n, k, 1, matrix, m, b, k, 1, &c, m)</div><div>```</div><div><br></div><div>There are times when I'd want to call `cblas_sgemm(_:_:_:_:_:_:_:_:_:_:_:_:_:_:)` inside an `withUnsafe[Mutable]Pointer(_:)` closure. Distinguishing `withUnsafePointer(_:)` and `withUnsafeMutablePointer(_:)` would allow a reader to know from the outset if `$0.pointee` is mutated without having to know that the second-from-last argument is the one that stores the result (it is not consistently second-from-last; for vDSP_* functions, it's often the third-from-last argument, and for others it can be the first argument). Removing the current `withUnsafePointer(_:)` would decrease clarity for the reader here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
> I've not had to use these functions much, but the distinction between<br>
> `Array.withUnsafeBufferPointer(_:)` and<br>
> `Array.withUnsafeMutableBufferPointer(_:)` has conditioned me to<br>
> mutate the pointee using only "mutable" functions.<br>
<br>
</span>Not sure if you're just drawing an analogy,</blockquote><div><br></div><div>I was trying to. I guess ineffectively.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">but if not, those two<br>
methods are not under discussion here. They are meaningfully different,<br>
whereas the existing functions are not, and the one currently called<br>
withUnsafePointer is always going to cause people to complain about<br>
having to pass a mutable variable.<br>
<br>
As a fallback position, I would suggest we only provide the mutating<br>
one, but with its existing name. But I still prefer the shorter name.<br>
<div class=""><div class="h5"><br>
><br>
>> ><br>
>> > Option 2: Fix SR-1956 and have two functions, one with inout and the<br>
>> > other not. This would address the inconvenience of not being able to<br>
>> > use withUnsafePointer with immutable values, while still supporting<br>
>> > the existing behavior. The question then would be what to call these<br>
>> > two functions.<br>
>><br>
>> We do not need to support new use-cases in this release, and this would<br>
>> be unsatisfying because the “address of a global” property that Jordan<br>
>> argued for would not hold for the immutable version.<br>
>><br>
>> > - Option 2a. Combine the two existing functions as in Option 1 and use<br>
>> > a new name for the non-inout version, e.g.,<br>
>> > withUnsafePointer(toCopyOf:), so that it won’t be confused with the<br>
>> > old function. (That particular name doesn’t work very well when<br>
>> > dealing with references to objects, since the object itself would not<br>
>> > be copied. I haven’t yet come up with a better name, though.) One<br>
>> > advantage of this approach is that we would not need to rush the new<br>
>> > function into Swift 3 since it would be an additive change.<br>
>><br>
>> Not rushing that into Swift 3 is the same as Option 1.<br>
>><br>
>> > - Option 2b. Switch to use withUnsafeMutablePointer for all the cases<br>
>> > where you care about the getting the same address. Change<br>
>> > withUnsafePointer to be the non-inout version. Charlie suggested that<br>
>> > we could have the migrator convert all existing uses on<br>
>> > withUnsafePointer in Swift 2 code to use withUnsafeMutablePointer in<br>
>> > Swift 3, but I’m not sure how well that would work.<br>
>><br>
>> That's exactly the same outcome, with respect to the language/library<br>
>> surface, as Option 2 AFAICT. Can we simplify this list of options?<br>
>><br>
>> --<br>
>> Dave<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
<br>
--<br>
Dave<br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div></div>