dst = src rather than src dst

Daniel Keep daniel.keep.lists at gmail.com
Wed Sep 5 20:44:02 PDT 2007



Bill Baxter wrote:
> Kirk McDonald wrote:
>> [snip]
>> 
>> Although you might make it syntactically consistent with assignment:
>>
>> int i = 10;
>> alias F = Foo;
>>
>> It will still be different from assignment in very fundamental ways:
>>
>> i = 20; // okay
>> F = Bar; // Huh?
>> alias F = Baz; // Ack!
> 
> I don't get your point with that example. All types are inherently
> 'final' since they are always compile time constants.  So it's just like
> saying:
> 
> final int i = 10;
> i = 20; // huh?
> 
> Yeh, that's just wrong.  You can't do it.  Nothing strange about it.

import module1;
import module2;

alias toString = module1.toString;
alias toString = module2.toString;

If you're going to maintain consistency with assignment, overloading a
symbol should be gotten rid of as well.

>> The fact that the syntax looks nothing like assignment underscores the
>> fact that /it is not an assignment/. 
> 
> I would say that the fact that the syntax looks nothing like assignment
> belies the fact that /it is an assignment/.
> 
> Think of 'alias' as meaning 'metatype', the type of types.
> 
> metatype F = Baz;
> 
> F is a new type variable (metatype) and now it equals the same thing as
> type variable Baz.

But it's *not* assignment.  Variables have a single location in memory.
 A symbol can refer to many things.  Come D 2.0, it'll even be able to
refer to many things of different types (regular functions overloaded on
templates).

>> I would classify the proposal as a foolish consistency, but I wouldn't
>> really care if it were added. (Except that adding redundant syntaxes
>> for the same operation is rarely a good idea.)
> 
> Well redundancy, there is that, yes.  I suppose we could propose to
> leave D1.0 as is and change 2.0 completely.
> 
> But I think it's probably better to leave both in and just think of it
> as a backwards compatibility nod to C/C++ -- just like   foo x[3]; vs
> foo[3] x;

I'm not a big fan of the proposal because you're getting into murky
semantic waters using '='.  I see this as a case of "if it ain't broke,
don't fix it".  :)

	-- Daniel



More information about the Digitalmars-d mailing list