Actually, `swapAt` does have a precondition that the elements differ.
On Sun, May 7, 2017 at 09:41 Paul Cantrell via swift-evolution <
swift-evolution@swift.org> wrote:
>
> On May 7, 2017, at 6:01 AM, Jean-Daniel <mail...@xenonium.com> wrote:
>
>
> Le 7 mai 2017 à 03:54, Paul Cantrell via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
>
> On May 6, 2017, at 12:36 PM, John McCall via swift-evolution <
> swift-evolution@swift.org> wrote:
>
>
> On May 6, 2017, at 1:11 PM, Félix Cloutier via swift-evolution <
> swift-evolution@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(). 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
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
