> On May 7, 2017, at 10:41 AM, Paul Cantrell <[email protected]> wrote: > > >> On May 7, 2017, at 6:01 AM, Jean-Daniel <[email protected] >> <mailto:[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().
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 >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
