Russell Lewis wrote:
> Bill Baxter wrote:
>> Robert Fraser wrote:
>>> Russell Lewis Wrote:
>>>
>>>> Let's take this one step further.  Let's say that this is a typedef:
>>>>      typedef dst = src.dup;
>>>> while this is an alias:
>>>>      typedef dst = src;
>>>
>>> Please no!
>>
>> On second thought, let's take a step back again.
>> And forward
>> and back...
>> and then we're cha-cha-ing!
> 
> Yeah, I felt the same way when the syntax first occurred to me: "EEK! RUN!"  But it's growing on me.  There is a certain elegance to the idea that a type is a compile-time variable, and that an alias is copying the (reference to) the type, while a typedef is creating a new type with the same contents (that is, the same semantics) as the old.
> 
> But I still shudder when I see it. :)

Well, I didn't think it was a horrible idea, just not really necessary.  D already has a decent way to distinguish aliases vs definition new types, and as far as I know it doesn't cause any consternation in daily coding (basically you just never use the latter).

For a new language without any established conventions it might be a nice idea to treat types more like values across the board, and I believe there are languages that do exactly this (like lisp and python) but I think it's too late for D to try to make such a big change.

Just reversing the order of arguments to alias and typedef and sticking an '=' between them seems like a good value proposition to me.  Decent gain in readability and consistency, minimal pain in terms of old code breakage (assuming old-style aliases remain allowed for a while.)

--bb

Bill Baxter wrote:
> Russell Lewis wrote:
> 
>> Bill Baxter wrote:
>>
>>> Robert Fraser wrote:
>>>
>>>> Russell Lewis Wrote:
>>>>
>>>>> Let's take this one step further.  Let's say that this is a typedef:
>>>>>      typedef dst = src.dup;
>>>>> while this is an alias:
>>>>>      typedef dst = src;
>>>>
>>>>
>>>> Please no!
>>>
>>>
>>> On second thought, let's take a step back again.
>>> And forward
>>> and back...
>>> and then we're cha-cha-ing!
>>
>>
>> Yeah, I felt the same way when the syntax first occurred to me: "EEK! RUN!"  But it's growing on me.  There is a certain elegance to the idea that a type is a compile-time variable, and that an alias is copying the (reference to) the type, while a typedef is creating a new type with the same contents (that is, the same semantics) as the old.
>>
>> But I still shudder when I see it. :)
> 
> 
> Well, I didn't think it was a horrible idea, just not really necessary.  D already has a decent way to distinguish aliases vs definition new types, and as far as I know it doesn't cause any consternation in daily coding (basically you just never use the latter).
> 
> For a new language without any established conventions it might be a nice idea to treat types more like values across the board, and I believe there are languages that do exactly this (like lisp and python) but I think it's too late for D to try to make such a big change.
> 

In Python, types /are/ values. That is, classes are objects; you can even define classes whose instances are classes. These are called metaclasses. Python's object model is so thoroughly different from D's that this comparison is not a useful one.

> Just reversing the order of arguments to alias and typedef and sticking an '=' between them seems like a good value proposition to me.  Decent gain in readability and consistency, minimal pain in terms of old code breakage (assuming old-style aliases remain allowed for a while.)
> 

As to the actual proposal, I am basically indifferent. The /lack/ of the equals sign makes it clear that it reads left-to-right, in my mind.

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!

The fact that the syntax looks nothing like assignment underscores the fact that /it is not an assignment/. 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.)

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

Kirk McDonald wrote:
> The fact that the syntax looks nothing like assignment underscores the fact that /it is not an assignment/. 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.)
> 

I second the proposal someone already made of allowing

alias Foo as Bar;

This doesn't look like an assignment, but makes the declaration more readable and allows one to easily remember which identifier is the alias being created (at least, if one is a native English speaker...) at the slight cost of adding the keyword 'as'.  The 'as' could be optional so as not to break existing code.

Thanks,
Nathan Reed

Kirk McDonald wrote:
> Bill Baxter wrote:

>> Just reversing the order of arguments to alias and typedef and sticking an '=' between them seems like a good value proposition to me.  Decent gain in readability and consistency, minimal pain in terms of old code breakage (assuming old-style aliases remain allowed for a while.)
>>
> 
> As to the actual proposal, I am basically indifferent. The /lack/ of the equals sign makes it clear that it reads left-to-right, in my mind.

I don't think it's a matter of being difficult to remember where src and dest are supposed to go (though I do admit I type it backwards sometimes) It's just harder to read.  It's like putting the name of a function at the end of the function body.  Or the name of a class at the end.  Names and titles of things go at the beginning, not the end. Unless you're Paul Harvey telling "the rest of the story".

The reader of code runs across a symbol like "value_type" and needs to find out what that is.  I say it's harder to find it here:

alias init_base!(init_with_call_policies!(CallPoliciesT, InitT)) base;
alias InitT.n_arguments n_arguments;
alias InitT.n_defaults n_defaults;
alias InitT.signature signature;
alias pointee!(Ptr).type value_type;
alias objects.pointer_holder!(Ptr,value_type) holder;
alias objects.instance!(holder) instance_t;

than here:

alias base = init_base!(init_with_call_policies!(CallPoliciesT, InitT));
alias n_arguments = InitT.n_arguments;
alias n_defaults = InitT.n_defaults;
alias signature = InitT.signature ;
alias value_type = pointee!(Ptr).type;
alias holder = objects.pointer_holder!(Ptr,value_type);
alias instance_t = objects.instance!(holder);

The fact that it's more consistent with value assignments and with renamed import syntax is a nice added bonus.


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

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


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

--bb

Nathan Reed wrote:
> Kirk McDonald wrote:
>> The fact that the syntax looks nothing like assignment underscores the fact that /it is not an assignment/. 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.)
>>
> 
> I second the proposal someone already made of allowing
> 
> alias Foo as Bar;
> 
> This doesn't look like an assignment, but makes the declaration more readable and allows one to easily remember which identifier is the alias being created (at least, if one is a native English speaker...) at the slight cost of adding the keyword 'as'.  The 'as' could be optional so as not to break existing code.
> 

I wouldn't say it's totally unambiguous.
When I first read it just now I thought "foo as bar ... we're going to refer to foo as bar. Wait, that sounds just like the current alias?!"

Whereas I can't think of any way someone could misinterpret which is the new and which is the old in "alias Foo = Bar;"

--bb

Nathan Reed wrote:
> Kirk McDonald wrote:
>> The fact that the syntax looks nothing like assignment underscores the fact that /it is not an assignment/. 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.)
>>
> 
> I second the proposal someone already made of allowing
> 
> alias Foo as Bar;

Is that:
class Bar;
alias Foo as Bar; // treat identifier Foo the same as Bar

or:
class Foo;
alias Foo as Bar; // refer to Foo as Bar

And I'm a native English speaker.

On the other hand, the equals sign is quite unambiguous because it's a close analogy to existing assignments.

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

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

Bill Baxter wrote:
> Daniel Keep wrote:
>> [snip]
>>
>> 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

If it's any consolation, I'd be over the moon if it really *was* assignment.  Having types as just another value opens up so many interesting possibilities.  Sadly, that's not the case in D just as of yet.

Oh well :)

	-- Daniel

Christopher Wright wrote:
> Is that:
> class Bar;
> alias Foo as Bar; // treat identifier Foo the same as Bar
> 
> or:
> class Foo;
> alias Foo as Bar; // refer to Foo as Bar
> 
> And I'm a native English speaker.
> 
> On the other hand, the equals sign is quite unambiguous because it's a close analogy to existing assignments.

Actually that "[as]" wasn't a proposition to /change/ the syntax, but rather a hint for people who might find the order unintuitive. Personally I don't have a problem with it, as it's simple and straight forwards alias one thing as another. (That's like with x86 assembly: Intel syntax is mov DST, SRC; AT&T syntax is mov SRC, DST -- if AT&T wasn't so unreadable in all other aspects, I'd go for it just because of the order of operands.)

I'm all against the equal sign, because it's used in completely different terms. Assigning one type to the other just doesn't look right.

Kind regards,
Alex