Better distinguishing reference and value in the syntax?
Alex Rønne Petersen
xtzgzorex at gmail.com
Tue Jan 3 06:33:17 PST 2012
On 03-01-2012 07:53, Gou Lingfeng wrote:
> On Tue, 2012-01-03 at 06:43 +0100, Timon Gehr wrote:
>> 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.
>
> Or, "&a ==&b". If similar notations could apply to other types (arrays
> and classes), binary "is" is not needed at all.
That's uglier than 'is'.
>
> On the other hand, if "is" is introduced, it should make some special
> sense than "==", like this:
Introduced? It's a feature in the language today.
>
> import std.stdio;
> int a=1,b=1;
> void fun(ref int c,ref int d,ref int e){
> writeln("'c is d' evaluates ",c is d,", should be true.");
> writeln("'c is e' evaluates ",c is e,", should be false.");
> writeln("'c is a' evaluates ",c is a,", should be true.");
> writeln("'c is b' evaluates ",c is b,", should be false.");
> }
> void main() {
> writeln("'a is b' evaluates ",a is b,", should be false.");
> fun(a,a,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.
>
> Implication is not redundant, but equivalence is. And the current
> definition of "is" for integers is equivalent to "==".
>
- Alex
More information about the Digitalmars-d
mailing list