[swift-evolution] Should we rename "class" when referring to protocol conformance?
dabrahams at apple.com
Sat May 7 16:07:34 CDT 2016
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.
> 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 :-)
More information about the swift-evolution