dst = src rather than src dst

[Bill Baxter]

Daniel Keep wrote:
> 
> 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;

Hmm.  Ok that's very interesting.  I didn't realize that was possible 
with symbol aliases (I've been thinking pretty much only about types).

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

Once again, I don't think consistency is the main reason to make the 
change, but it's a nice bonus.  Improved readability of keeping 
everything on the left side is what I'm after.

So I guess my reaction to the above is, yeh, there's an inconsistency 
now between type aliases and symbol aliases, and after the change there 
would be an equivalent inconsistency between value assignment and symbol 
alias assignment.  If that inconsistency bothers people more than the 
current inconsistency for some reason then I'd be happy for there to be 
a different alias assignment syntax besides '=', as long as the thing 
being defined goes on the left side.

>>> 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.  

I don't mean its an assignment in the "D grammar AssignExpression := 
..." sense.  Obviously its not that.  But it *is* assigning a symbol (F) 
a meaning (Baz).

> Variables have a single location in memory.
 > A symbol can refer to many things.

Yeh, but a _type_ alias cannot refer to many _types_.

> Come D 2.0, it'll even be able to
> refer to many things of different types (regular functions overloaded on
> templates).

But a type alias will still only be one type... I think.  Has to be 
since otherwise the compiler has no way of knowing what you mean when 
you declare a new one:
   T foo;

> 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".  :)

Yeh, and that's probably how Walter sees it too.  It ain't broke, just 
sprained a bit.  Just like automatic fallthrough in switch statements. 
It doesn't hurt bad enough to warrant breaking with how C does it.

I thought maybe there was a chance this time, because in the previous 
discussion I don't think anyone mentioned the possibility of maintaining 
the C-compatible alongside the new syntax.  Unlike the switch 
fallthrough issue the new syntax wouldn't preclude the old. Plus by this 
time I was hoping there were enough people seriously immersed in generic 
programming to see the type:value :: metatype:type  analogy more clearly.

But if Kirk doesn't get it, and Don doesn't chime in with "what a great 
idea" in the next 5 minutes, well ... it's hopeless.

--bb