<div dir="ltr">On Fri, Jul 22, 2016 at 5:06 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
on Fri Jul 22 2016, Bob Wilson &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
<br>
&gt; It is not so clear what to do about SR-1956. (Charlie and I had some<br>
&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>
</span>&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>
<span class="">&gt; the objection that when using withUnsafePointer with a global, there<br>
&gt; is an expectation that you’ll get the same address every<br>
&gt; time. Removing inout would cause the argument to be passed by value<br>
&gt; and the address would refer to a copy. Dmitri agreed that this could<br>
&gt; be a problem. On the other hand, if you don’t care about the address,<br>
&gt; or if you’re not using a value type, it would indeed be convenient to<br>
&gt; have a version of withUnsafePointer that does not require an inout<br>
&gt; argument.<br>
&gt;<br>
&gt; Option 1: Keep inout (not addressing SR-1956). In this case, there’s<br>
&gt; no reason to have both withUnsafePointer and<br>
&gt; withUnsafeMutablePointer. If you want to call a function that expects<br>
&gt; an UnsafePointer, you can give it an UnsafeMutablePointer and there<br>
&gt; will be an implicit conversion to make it work. I discussed this with<br>
&gt; Apple’s stdlib team and they recommended that if we have only one<br>
&gt; function we use the shorter name “withUnsafePointer” and have it use<br>
&gt; an UnsafeMutablePointer.<br>
<br>
</span>Very much in favor of Option 1.<br></blockquote><div><br></div><div>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&#39;s rarely used enough, and the shorter name needlessly raises the question of where I&#39;m really &quot;supposed to be&quot; mutating the pointee. I&#39;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 &quot;mutable&quot; functions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
&gt;<br>
&gt; Option 2: Fix SR-1956 and have two functions, one with inout and the<br>
&gt; other not. This would address the inconvenience of not being able to<br>
&gt; use withUnsafePointer with immutable values, while still supporting<br>
&gt; the existing behavior. The question then would be what to call these<br>
&gt; two functions.<br>
<br>
</span>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>
<span class=""><br>
&gt; - Option 2a. Combine the two existing functions as in Option 1 and use<br>
&gt; a new name for the non-inout version, e.g.,<br>
&gt; withUnsafePointer(toCopyOf:), so that it won’t be confused with the<br>
&gt; old function. (That particular name doesn’t work very well when<br>
&gt; dealing with references to objects, since the object itself would not<br>
&gt; be copied. I haven’t yet come up with a better name, though.) One<br>
&gt; advantage of this approach is that we would not need to rush the new<br>
&gt; function into Swift 3 since it would be an additive change.<br>
<br>
</span>Not rushing that into Swift 3 is the same as Option 1.<br>
<span class=""><br>
&gt; - Option 2b. Switch to use withUnsafeMutablePointer for all the cases<br>
&gt; where you care about the getting the same address. Change<br>
&gt; withUnsafePointer to be the non-inout version. Charlie suggested that<br>
&gt; we could have the migrator convert all existing uses on<br>
&gt; withUnsafePointer in Swift 2 code to use withUnsafeMutablePointer in<br>
&gt; Swift 3, but I’m not sure how well that would work.<br>
<br>
</span>That&#39;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>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Dave<br>
</font></span><div class="HOEnZb"><div class="h5"><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>