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

[Joe Groff]

> On Dec 16, 2015, at 10:34 AM, John McCall via swift-dev <swift-dev at swift.org> wrote:
> 
>> 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.

I agree we can make that guarantee for globals, and maybe local stored properties as well. It's tricky to do that for potentially computed properties, which includes any class properties or properties outside your resilience domain, so though we can make a best effort not to wantonly change pointer identity across calls that take pointers to the same property, I don't think we can fully eliminate the need for an explicit withUnsafePointer form.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151216/5733fd07/attachment.html>