dst = src rather than src dst
Bill Baxter
dnewsgroup at billbaxter.com
Wed Sep 5 21:50:28 PDT 2007
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
More information about the Digitalmars-d
mailing list