<div dir="ltr">On Fri, Jul 22, 2016 at 5:06 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><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>
</span>> <<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>
<span class="">> 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>
</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'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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><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>
</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>
> - 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>
</span>Not rushing that into Swift 3 is the same as Option 1.<br>
<span class=""><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>
</span>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>
<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>