on Sat May 07 2016, Tyler Fleming Cloutier <cloutiertyler-AT-aol.com> wrote:
> No, I'm sorry; this “deep-vs-shallow” thing is a fallacy that comes from > not understanding the boundaries of your value. Or, put more > solicitously: sure, you can look at the world that way, but it just > makes everything prohibitively complicated, so why would you want to? > > In my world, there's no such thing as a “deep copy” or a “shallow copy;” > there's just “copy,” which logically creates an independent version of > everything up to the boundaries of the value. Likewise, there's no > “deep value semantics” or “shallow value semantics.” Equality defines > value semantics, and the boundaries of an Array value always includes > the values of its elements. The *only* problem here is that we have no > way to do equality comparison on some arrays because some types aren't > Equatable. IMO the costs of not having everything be equatable, in > complexity-of-programming-model terms, are too high. > > My point with this is, in case I was a bit rambling, if you’re going to draw > boundaries around a value, for the purpose of copying or immutability, then > equality should always match with those boundaries. Quite. > As you say, “Equality defines value semantics, and the boundaries of > an Array value always includes the values of its elements.” > > Under this reasoning, custom equality violates these boundaries. No, it defines those boundaries. > And without custom equality, equality checks on reference types are > essentially useless. No, comparing reference identity is completely useful. That's why “===” exists. We just spelled it wrong :-) -- -Dave _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution