> On Dec 16, 2015, at 10:34 AM, John McCall via swift-dev <swift-dev@swift.org>
> wrote:
>
>> On Dec 16, 2015, at 12:12 AM, Dave Abrahams via swift-dev
>> <swift-dev@swift.org> wrote:
>>> On Dec 15, 2015, at 11:51 PM, Kevin Ballard <ke...@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 <ke...@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@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
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev
