<div dir="ltr">On Fri, Jul 22, 2016 at 6:49 PM, Dave Abrahams via swift-evolution <span dir="ltr">&lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt;</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 &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; On Fri, Jul 22, 2016 at 5:06 PM, Dave Abrahams via swift-evolution &lt;<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; on Fri Jul 22 2016, Bob Wilson &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; &gt; It is not so clear what to do about SR-1956. (Charlie and I had some<br>
&gt;&gt; &gt; 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>
&gt;&gt; &gt; &lt;<a href="https://github.com/apple/swift-evolution/pull/437" rel="noreferrer" target="_blank">https://github.com/apple/swift-evolution/pull/437</a>&gt;.) Jordan raised<br>
&gt;&gt; &gt; the objection that when using withUnsafePointer with a global, there<br>
&gt;&gt; &gt; is an expectation that you’ll get the same address every<br>
&gt;&gt; &gt; time. Removing inout would cause the argument to be passed by value<br>
&gt;&gt; &gt; and the address would refer to a copy. Dmitri agreed that this could<br>
&gt;&gt; &gt; be a problem. On the other hand, if you don’t care about the address,<br>
&gt;&gt; &gt; or if you’re not using a value type, it would indeed be convenient to<br>
&gt;&gt; &gt; have a version of withUnsafePointer that does not require an inout<br>
&gt;&gt; &gt; argument.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Option 1: Keep inout (not addressing SR-1956). In this case, there’s<br>
&gt;&gt; &gt; no reason to have both withUnsafePointer and<br>
&gt;&gt; &gt; withUnsafeMutablePointer. If you want to call a function that expects<br>
&gt;&gt; &gt; an UnsafePointer, you can give it an UnsafeMutablePointer and there<br>
&gt;&gt; &gt; will be an implicit conversion to make it work. I discussed this with<br>
&gt;&gt; &gt; Apple’s stdlib team and they recommended that if we have only one<br>
&gt;&gt; &gt; function we use the shorter name “withUnsafePointer” and have it use<br>
&gt;&gt; &gt; an UnsafeMutablePointer.<br>
&gt;&gt;<br>
&gt;&gt; Very much in favor of Option 1.<br>
&gt;&gt;<br>
&gt;<br>
&gt; Ditto, except that I think there is some value in keeping both (i.e. doing<br>
&gt; nothing): allowing the user to document intent. It would be inconsistent<br>
&gt; and potentially confusing to call the function that returns an<br>
&gt; `UnsafeMutablePointer` `withUnsafePointer`.<br>
<br>
</div></div>It doesn&#39;t return an `UnsafeMutablePointer`, it passes an<br>
`UnsafeMutablePointer` to the body of the closure.<br></blockquote><div><br></div><div>Brainfart. Yes, that&#39;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="">
&gt; It&#39;s rarely used enough, and the shorter name needlessly raises the<br>
&gt; question of where I&#39;m really &quot;supposed to be&quot; mutating the<br>
&gt; pointee.<br>
<br>
</span>I don&#39;t understand; you only have the pointee inside the closure.<br>
That&#39;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&#39;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, &amp;c, m)</div><div>```</div><div><br></div><div>There are times when I&#39;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&#39;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="">
&gt; I&#39;ve not had to use these functions much, but the distinction between<br>
&gt; `Array.withUnsafeBufferPointer(_:)` and<br>
&gt; `Array.withUnsafeMutableBufferPointer(_:)` has conditioned me to<br>
&gt; mutate the pointee using only &quot;mutable&quot; functions.<br>
<br>
</span>Not sure if you&#39;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>
&gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Option 2: Fix SR-1956 and have two functions, one with inout and the<br>
&gt;&gt; &gt; other not. This would address the inconvenience of not being able to<br>
&gt;&gt; &gt; use withUnsafePointer with immutable values, while still supporting<br>
&gt;&gt; &gt; the existing behavior. The question then would be what to call these<br>
&gt;&gt; &gt; two functions.<br>
&gt;&gt;<br>
&gt;&gt; We do not need to support new use-cases in this release, and this would<br>
&gt;&gt; be unsatisfying because the “address of a global” property that Jordan<br>
&gt;&gt; argued for would not hold for the immutable version.<br>
&gt;&gt;<br>
&gt;&gt; &gt; - Option 2a. Combine the two existing functions as in Option 1 and use<br>
&gt;&gt; &gt; a new name for the non-inout version, e.g.,<br>
&gt;&gt; &gt; withUnsafePointer(toCopyOf:), so that it won’t be confused with the<br>
&gt;&gt; &gt; old function. (That particular name doesn’t work very well when<br>
&gt;&gt; &gt; dealing with references to objects, since the object itself would not<br>
&gt;&gt; &gt; be copied. I haven’t yet come up with a better name, though.) One<br>
&gt;&gt; &gt; advantage of this approach is that we would not need to rush the new<br>
&gt;&gt; &gt; function into Swift 3 since it would be an additive change.<br>
&gt;&gt;<br>
&gt;&gt; Not rushing that into Swift 3 is the same as Option 1.<br>
&gt;&gt;<br>
&gt;&gt; &gt; - Option 2b. Switch to use withUnsafeMutablePointer for all the cases<br>
&gt;&gt; &gt; where you care about the getting the same address. Change<br>
&gt;&gt; &gt; withUnsafePointer to be the non-inout version. Charlie suggested that<br>
&gt;&gt; &gt; we could have the migrator convert all existing uses on<br>
&gt;&gt; &gt; withUnsafePointer in Swift 2 code to use withUnsafeMutablePointer in<br>
&gt;&gt; &gt; Swift 3, but I’m not sure how well that would work.<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s exactly the same outcome, with respect to the language/library<br>
&gt;&gt; surface, as Option 2 AFAICT.  Can we simplify this list of options?<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; Dave<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<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>