Better distinguishing reference and value in the syntax?

Timon Gehr timon.gehr at gmx.ch
Mon Jan 2 21:43:34 PST 2012


On 01/03/2012 06:10 AM, Gou Lingfeng wrote:
> 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

ref is not a type modifier, it is a storage class, therefore, to compare 
to ref int values a,b for identity, use &a is &b.

> has a consistant meaning everywhere: whether a and b refer to exactly
> the same memory location. And there's no redundency.
>
>

There will always be some redundancy, because a is b implies a == b.


More information about the Digitalmars-d mailing list