[swift-dev] `withUnsafePointer` mutates `self`

[John McCall]

> On Dec 16, 2015, at 12:12 AM, Dave Abrahams via swift-dev <swift-dev at swift.org> wrote:
>> On Dec 15, 2015, at 11:51 PM, Kevin Ballard <kevin at sb.org> wrote:
>> On Tue, Dec 15, 2015, at 11:25 PM, Dave Abrahams wrote:
>>> 
>>>> On Dec 15, 2015, at 6:46 PM, Kevin Ballard <kevin at sb.org> wrote:
>>>> 
>>>> On Tue, Dec 15, 2015, at 06:39 PM, Dave Abrahams wrote:
>>>>> 
>>>>>> On Dec 15, 2015, at 6:33 PM, Kevin Ballard via swift-dev <swift-dev at swift.org> wrote:
>>>>>> 
>>>>>> On Tue, Dec 15, 2015, at 03:03 PM, Joe Groff via swift-dev wrote:
>>>>>>> 
>>>>>>> Yeah, it seems to me like a reasonable refinement for 'withUnsafePointer' to take an immutable parameter. Since this is a stdlib API change, you should suggest that on swift-evolution.
>>>>>> 
>>>>>> A change like that is going to break any code that relies on the inout optimization (where it uses call-by-reference instead of copy-in copy-out when possible). Yes, such code is in violation of Swift semantics today, but it does work.
>>>>> 
>>>>> Two questions:
>>>>> 
>>>>> 1. Don’t we want a withUnsafeMutablePointer for the mutating cases (where the inout optimization can take effect) anyway?
>>>> 
>>>> I'm thinking here of cases like passing a context pointer to KVO. You're not actually mutating it, you just need a pointer that's the same every time you call the code.
>>> 
>>> Well, it is not possible to code a version of withUnsafePointer that makes that guarantee in Swift.
>> 
>> Yeah but we want to move in the direction of making that more reliable, not less.
> 
> I am not sure I agree with you.  I would defer to John McCall on this one, but my understanding is that it's an explicit non-goal to make that guarantee.

I think it’s useful to be able to make this guarantee for some variables; I just don’t want it to be assumed for all variables.  I’m okay with the idea that &myGlobalStoredVar will consistently yield the same pointer.

John.

>> I forget who but someone said in another thread that global variables can be reliably passed by-ref to functions that take pointers already (even though the Swift documentation does not guarantee this).
>> 
>> Come to think of it, what's the actual use-case for withUnsafePointer()?
> 
> I'm not sure we still have one that isn't covered by &x; that's my point.
> 
>> If a value is mutable, you can already use &x or withUnsafeMutablePointer(), and if it's immutable, you can't call withUnsafePointer() today anyway. The proposed change would just make withUnsafePointer() into the equivalent of `var x = value; callSomethingWith(&x)`. The only reason to really want a withUnsafePointer() function is if it can give you an UnsafePointer to an immutable value without copying it, but we can't do that. I'm inclined to say we should just get rid of withUnsafePointer() entirely, at least until such time as Swift has a way to pass immutable values by-ref.
> 
> I'm inclined to agree.  Proposal?
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev