> On May 7, 2017, at 6:01 AM, Jean-Daniel <[email protected]> wrote:
> 
>> 
>> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution 
>> <[email protected] <mailto:[email protected]>> a écrit :
>> 
>> 
>>> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution 
>>> <[email protected] <mailto:[email protected]>> wrote:
>>> 
>>> 
>>>> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution 
>>>> <[email protected] <mailto:[email protected]>> 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(). 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

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to