On Mon, 2012-01-02 at 13:18 +0100, Alex Rønne Petersen wrote: > On 02-01-2012 06:25, Gou Lingfeng wrote: > > D's definitions of "is" and "==" have so much redundency. That might > > indicate some flaw. If references and values (for classes and arrays) > > could be clearly distinguished in the syntax, the "is" operator is not > > necessary at all. > > Of course it is. 'is' is strictly identity, while == would call an > overloaded opEquals, if any exists. This difference in semantics is > *very* important when you do *not* want to call opEquals.
My impression is that, in D, references are wrapped (protected) pointers, and there are values behind. Although opEquals can be defined anyway, it's usually some function depending on the values, not pointers. If we could clearly show whether we wan't pointer comparison or value comparison, then "a is b" would be "pointer(a)==pointer(b)", and "a==b" "value(a)==value(b)". Or "is" sould evaluate false for "int is int", and true or false for expressions like "int is (ref int)" and "(ref int) is (ref int)". So it has a consistant meaning everywhere: whether a and b refer to exactly the same memory location. And there's no redundency.