[swift-evolution] Should we rename "class" when referring to protocol conformance?

[Dave Abrahams]

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