[swift-evolution] [Review] SE-0176: Enforce Exclusive Access to Memory

[John McCall]

> On May 7, 2017, at 10:41 AM, Paul Cantrell <cantrell at pobox.com> wrote:
> 
> 
>> On May 7, 2017, at 6:01 AM, Jean-Daniel <mailing at xenonium.com <mailto:mailing at xenonium.com>> wrote:
>> 
>>> 
>>> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>> 
>>> 
>>>> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> Concern: `swap` is quoted a lot for a method that would break under this rule, but as it happens, `swap` with the same value on both sides is (should be) a no-op. Is there a way to not trip the static or dynamic checkers in well-defined cases like that one? Is there any way to check that two inout parameters refer to the same value?
>>>> 
>>>> 
>>>> The only reasonable way to do this is statically, and why would you call 'swap' statically with the same l-value for both arguments?
>>> 
>>> When static analysis can determine that a swap is always a noop, I can’t see any reason not to flag it as an error.
>>> 
>>> But Félix’s question was also about the runtime case. And he has a good point.
>>> 
>>> Here’s a compelling example where allowing the noop swap would make sense:
>>> 
>>>     extension Array {
>>>       mutating func shuffle() {
>>>         for i in indices {
>>>           let j = i + Int(arc4random_uniform(UInt32(count - i)))
>>>           swap(&self[i], &self[j])
>>>         }
>>>       }
>>>     }
>>> 
>> 
>> Isn’t this issue already solved by the introduction of swapAt ? 
> 
> Ah, indeed, you’re quite right: I see that SE-0173 removes the “different elements” precondition for swapAt().
> 
> It’s not hard to imagine analogous situations involving data structures other than arrays, so presumably Félix’s point still stands in principle for the original swap().

swapAt is an operation on MutableCollection, not just on Array.

The key thing I think you may be missing here is that swapAt is needed because enforcement will otherwise prohibit two mutating accesses to the containing data structure.  We can't reliably poke a hole in that just for swap.

John.

> But I notice that SE-0173 says swap() will be deprecated & removed in the future?! Surprising, but well of topic: SE-0176 would allow the implementation of swapAt-like methods for other data structures, so no new concerns about this proposal as it stands.
> 
> Cheers, P
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170508/f4c6c1f0/attachment.html>