www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - dst = src rather than src dst

reply "Janice Caron" <caron serenityfirefly.com> writes:
Please could D allow the following syntaxes

alias dst = src;
typedef dst = src;

Instead of (or as well as)

alias src dst;
typedef src dst;

I just prefer the destination on the left. Moreover, it would make for greater 
consistency throughout D. It would match up with assignment operators, module 
import renaming, and alias template specializations.
Sep 05 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:

 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.


This has been suggested before.  I'm all for it.  Since types are just a 
kind of value in the realm of compile time evaluation, it makes sense to 
just have them use the same syntax.  It also puts the part you care 
about (the symbol you're going to be using) right up front where it's 
easy to find.  Actually that's the part I really care about.  I wouldn't 
mind if the syntax used ':=' or something instead of '=', I'd just like 
to see the order reversed.

--bb
Sep 05 2007
parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Bill Baxter wrote:

 Janice Caron wrote:

 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;

 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.


 
 This has been suggested before.  I'm all for it.  Since types are just a 
 kind of value in the realm of compile time evaluation, it makes sense to 
 just have them use the same syntax.  It also puts the part you care 
 about (the symbol you're going to be using) right up front where it's 
 easy to find.  Actually that's the part I really care about.  I wouldn't 
 mind if the syntax used ':=' or something instead of '=', I'd just like 
 to see the order reversed.
 
 --bb


I wouldn't be against it, at least as an alternative.  That said, though, I've
always seen 
alias'es and typedef's as being declerations, only directly of a symbol.  In
that case, 
they're fully consistant with other declerations taking the form 'TYPE SYMBOL'.
 All about 
perspective, I guess.

-- Chris Nicholson-Sauls
Sep 05 2007
prev sibling next sibling parent "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Janice Caron" <caron serenityfirefly.com> wrote in message 
news:mailman.91.1188982444.16939.digitalmars-d puremagic.com...

 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;


I doubt this will ever change, so to help you get used to the current 
syntax, here's how I think of it:

int x;
void function(int) fp;
float[] f;

These are some variable declarations, right?  Now just add alias or typedef 
in front.

alias int x;
alias void function(int) fp;
alias float[] f;

Now they're legal aliases.

Think of them like a variable declaration, except instead of making a 
variable, you're making a type.
Sep 05 2007
prev sibling next sibling parent reply "Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message-----
From: digitalmars-d-bounces puremagic.com 
[mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Jarrett Billingsley
Sent: 05 September 2007 14:43
To: digitalmars-d puremagic.com
Subject: Re: dst = src rather than src dst


 I doubt this will ever change,


Mebbe. But there's no harm in asking!



 so to help you get used to the current syntax, <snip>
 Think of them like a variable declaration,


Sure, but alias is also used to importing symbols into the current namespace. A 
good example in D 2.0+ would be

 struct B
 {
     A super_A;
     alias super_A this;
 }

Here the intent is not to declare a variable, but to alias the symbol this. 
Similarly

  class Derived : Base
  {
      int f();
      alias f f;
  }

Which brings the implementations of f defined in Base into Derived. On a 
similar note:

 alias std.path.join join;

might be used to disambiguate between std.path.join and std.string.join. In all 
of these cases, you are /not/ declaring a variable, you are pulling symbol 
definitions into the current namespace, so your mneumonic doesn't work. I'm not 
knocking it, mind. I'm just saying these would be more readable as (for 
example)

 alias join = std.path.join;

Or at least, I think so. Also, type expressions are now becoming more common, 
and frankly

 typedef Tx = typeof(x);

is self-explanatory. In any case, I wasn't necessarily suggesting that the old 
syntax be scrapped, merely that new syntax be allowed.
Sep 05 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Janice Caron wrote:

 so to help you get used to the current syntax, <snip>
 Think of them like a variable declaration,


 
 Sure, but alias is also used to importing symbols into the current 
 namespace. A good example in D 2.0+ would be
 
 struct B
 {
     A super_A;
     alias super_A this;
 }
 
 Here the intent is not to declare a variable, but to alias the symbol 
 this. Similarly
 
  class Derived : Base
  {
      int f();
      alias f f;
  }
 
 Which brings the implementations of f defined in Base into Derived. 



 On a 
 similar note:
 
 alias std.path.join join;
 
 might be used to disambiguate between std.path.join and std.string.join. 
 In all of these cases, you are /not/ declaring a variable, you are 
 pulling symbol definitions into the current namespace, so your mneumonic 
 doesn't work. I'm not knocking it, mind. I'm just saying these would be 
 more readable as (for example)
 
 alias join = std.path.join;
 


This reminds me that this:

import foo = std.foo;

is already valid syntax for declaring an alias.  It's basically (perhaps 
even exactly?) equivalent to typing:

  static import std.foo;
  alias std.foo foo;

That syntax would make even more sense if it were a shortcut for

  static import std.foo;
  alias foo = std.foo;


Mainly though, I think assignment syntax would make code that uses 
generic programming easier to read.  Look at snippets like this (from 
std.bind):

alias DerefFunc!(AllBoundArgs.type[argI]).RetType FuncRetType;
alias DerefFunc!(AllBoundArgs.type[argI]).DynParams FuncDynParams;

or

alias dynArgTypes!(
	i,
	sliceOffTuple!(FuncParams, 1).res,
	Tuple!(BoundArgs.type[1..$]),
	minParamsLeft-1
	).res tmp;

The thing that you're declaring, the thing that's going to be important 
in the code that follows, gets lost.

I think these are significantly easier to read as:

alias FuncRetType = DerefFunc!(AllBoundArgs.type[argI]).RetType;
alias FuncDynParams = DerefFunc!(AllBoundArgs.type[argI]).DynParams;

or

alias tmp = dynArgTypes!(
	i,
	sliceOffTuple!(FuncParams, 1).res,
	Tuple!(BoundArgs.type[1..$]),
	minParamsLeft-1
	).res;


Because it puts the thing you care about up front where it's easy to see.

--bb
Sep 05 2007
prev sibling next sibling parent Alexander Panek <alexander.panek brainsware.org> writes:
Janice Caron wrote:

 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for 
 greater consistency throughout D. It would match up with assignment 
 operators, module import renaming, and alias template specializations.
 
 


alias src [as] dst;
typedef src [as] dst;

Yay.
Sep 05 2007
prev sibling next sibling parent reply Robert Fraser <fraserofthenight gmail.com> writes:
Janice Caron Wrote:


 Please could D allow the following syntaxes
 
 alias dst = src;
 typedef dst = src;
 
 Instead of (or as well as)
 
 alias src dst;
 typedef src dst;
 
 I just prefer the destination on the left. Moreover, it would make for greater 
 consistency throughout D. It would match up with assignment operators, module 
 import renaming, and alias template specializations.
 


I think it was done this way to maintain consistency with C's typedefs.
Personally, I like the existing syntax, but I see no reason the other shouldn't
be added as an alternative.
Sep 05 2007
parent James Dennett <jdennett acm.org> writes:
Robert Fraser wrote:

 Janice Caron Wrote:
 

 Please could D allow the following syntaxes

 alias dst = src;
 typedef dst = src;

 Instead of (or as well as)

 alias src dst;
 typedef src dst;

 I just prefer the destination on the left. Moreover, it would make for greater 
 consistency throughout D. It would match up with assignment operators, module 
 import renaming, and alias template specializations.


 
 I think it was done this way to maintain consistency with C's typedefs.


Interestingly, C++ is introducing something like

using newname = oldname;

which, as a simple case, can replace the existing typedef
notation

typedef oldname newname;

-- James
Sep 06 2007
prev sibling next sibling parent reply Russell Lewis <webmaster villagersonline.com> writes:
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;
Sep 05 2007
parent reply Robert Fraser <fraserofthenight gmail.com> writes:
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!
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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!

--bb [with apologies to Real Genius]
Sep 05 2007
parent reply Russell Lewis <webmaster villagersonline.com> writes:
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. :)
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
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
Sep 05 2007
next sibling parent reply Nathan Reed <nathaniel.reed gmail.com> writes:
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
Sep 05 2007
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
prev sibling next sibling parent reply Christopher Wright <dhasenan gmail.com> writes:
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.
Sep 05 2007
parent Alexander Panek <alexander.panek brainsware.org> writes:
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
Sep 06 2007
prev sibling parent Russell Lewis <webmaster villagersonline.com> writes:
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 don't think that this will add a lot of clarity.  I don't know about 
other people, but when I read that syntax above, I still ask the 
question, "Is Foo being declared to be 'the same as' Bar, or is Bar 
being declared 'as a new alias of' Foo."

Perhaps it is instantly clear to other folks, I don't know.  But I know 
that at least one programmer finds the "as" syntax just as unclear as 
the original.
Sep 06 2007
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Sep 05 2007
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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
Sep 05 2007
next sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
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
Sep 05 2007
prev sibling parent reply Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Bill Baxter wrote:

 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


I do "get it" (an "alias" is the type of a symbol, you initialize the 
alias to the symbol, &c &c), I just don't particularly like it very 
much. This is primarily because it's merely a syntax change. If the old 
syntax is retained, we have redundant syntaxes, which is annoying and 
not a good thing. Before removing the current syntax, we have to of 
course consider the existing body of code which would have to be 
changed. (I do not think I need to belabor this point. Remember when 
implicit .ptr conversion was removed? This would be much worse. Removing 
the existing syntax is Not An Option.) Neither option is a winner.

Last and least, I do not not think it's much of an improvement. It is 
not like the existing syntax is ambiguous. It's not even unclear. In 
fact, my most frequent uses of alias render the "rvalue" and "lvalue" of 
the alias abundantly clear, since the rvalue frequently has keywords and 
things in it, or at least is more complicated than just an identifier. 
(Which is usually why I'm aliasing it in the first place.)

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 06 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Kirk McDonald wrote:

 Bill Baxter wrote:

 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


 
 I do "get it" (an "alias" is the type of a symbol, you initialize the 
 alias to the symbol, &c &c), 


Sorry for saying that.  I know you understand the concept perfectly.  I 
was think something more like "get that it would be a worthwhile change" 
but I just cut out too many words.

--bb
Sep 06 2007
prev sibling next sibling parent "Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message-----
From: digitalmars-d-bounces puremagic.com 
[mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Alexander Panek
Sent: 06 September 2007 08:13
To: digitalmars-d puremagic.com
Subject: Re: dst = src rather than src dst


 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.


And yet, the following is already perfectly good D syntax

 import x = std.stdio;
 import x = std.string;

(allowing x.symbol to resolve as either std.stdio.symbol or std.string.symbol)


The following is also perfectly valid D:

 class Foo(alias A=B)
 {
 }

Anyone see an assignment going on here? I don't. It should also be noted that

 class Foo(alias B A)
 {
 }

is *not* valid D. Consistency anyone?


Arguments that the equals sign should only be used for assignment and nothing 
else are already broken.

Besides, like Bill, my primary  concern is that I want the destination on the 
left. The exact syntax is secondary.
Sep 06 2007
prev sibling next sibling parent "Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message-----
From: digitalmars-d-bounces puremagic.com 
[mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Daniel Keep
Sent: 06 September 2007 04:44
To: digitalmars-d puremagic.com
Subject: Re: dst = src rather than src dst


 But it's *not* assignment.


It's also not a declaration. If we're going to be strict, let us remember that

 int x;

reserves space at run-time for an actual value, to be later used in 
expressions, whereas

 alias int x;

reserves no such space. Saying "it isn't assignment" no more justifies 
declaration syntax, than saying "it isn't declaration" justifies assignment 
syntax.

The bottom line is, it's neither assignment nor declaration. It's its own 
thing. It has declaration syntax purely for historical reasons - because it was 
easier for C compilers to parse it that way. ("typedef int x" parses like 
"const int x" - that is, "typedef" is officially a "storage class").

In reality, it's a type definition - the keyword typedef is closer in meaning 
to struct, class or enum (or in C++, namespace) than anything else. In fact,

 typedef B A;

could reasonably be rewritten in D2.0+ as

 struct A
 {
  B b;
  alias b this;
 }

-- Not that I'm advocating such a strategy, of course. I'm just pointing out 
that a typedef is fundamentally different from a declaration, and so the 
justification for the dst src syntax on these grounds are minimal.
Sep 06 2007
prev sibling next sibling parent reply "Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message-----
From: digitalmars-d-bounces puremagic.com 
[mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Kirk McDonald
Sent: 06 September 2007 09:14
To: digitalmars-d puremagic.com
Subject: Re: dst = src rather than src dst


 I just don't particularly like it very much. This is primarily because
 it's merely a syntax change.


D is an evolving language. It's had lots of syntax changes in the past.



 If the old syntax is retained, we have redundant syntaxes, which is annoying 
 and not a good thing.


Hmmm....

 char[] x;
 char x[];

Double Hmmm....

 void f(static int x) {...}
 void f(int x)() {...}
 template f(int x) { void f() {...} }

Hmmm again...

 find(s,'\n');
 s.find('\n');



 Before removing the current syntax, we have to of course consider
 the existing body of code which would have to be changed.


No one is suggesting making the old syntax illegal.



 Remember when implicit .ptr conversion was removed?


No one is suggesting making the old syntax illegal.



 Removing the existing syntax is Not An Option


No one is suggesting making the old syntax illegal.
Sep 06 2007
parent Kirk McDonald <kirklin.mcdonald gmail.com> writes:
Janice Caron wrote:

 -----Original Message-----
 From: digitalmars-d-bounces puremagic.com 
 [mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Kirk McDonald
 Sent: 06 September 2007 09:14
 To: digitalmars-d puremagic.com
 Subject: Re: dst = src rather than src dst
 

 I just don't particularly like it very much. This is primarily because
 it's merely a syntax change.


 
 D is an evolving language. It's had lots of syntax changes in the past.
 

 If the old syntax is retained, we have redundant syntaxes, which is 
 annoying and not a good thing.


 
 Hmmm....
 
 char[] x;
 char x[];
 


This is precisely the sort of thing I'm talking about. I'd list this as 
a case where the increased clarity of the new syntax is absolutely worth 
it, but these redundant syntaxes are still annoying and I don't like the 
fact we have to have 'em.


 Double Hmmm....
 
 void f(static int x) {...}
 void f(int x)() {...}
 template f(int x) { void f() {...} }
 


The second and third forms you have here aren't so much redundant syntax 
as the full syntax and the shorthand syntactic sugar for same. The first 
syntax is different, in that you call it differently:

f(1);
// vs
f!(2);


 Hmmm again...
 
 find(s,'\n');
 s.find('\n');
 


This I'll grant you. However, when this gets working for all types, it 
will be less a syntactic redundancy and more of an orginizational 
nicety. (You'll be able to split some methods out of a class, and 
perhaps into a seperate module, or even extend an existing class with 
your own "methods.")

I've already spent more time in this thread than I intended to. Despise 
this, /I don't care that much/ about whether this syntax is added. If it 
were put to a vote, I would abstain. I'm merely pointing out that adding 
new syntax which does not actually do anything new should on principle 
be avoided.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org
Sep 06 2007
prev sibling parent "Janice Caron" <caron serenityfirefly.com> writes:
-----Original Message-----
From: digitalmars-d-bounces puremagic.com 
[mailto:digitalmars-d-bounces puremagic.com] On Behalf Of Janice Caron
Sent: 06 September 2007 13:37
To: D
Subject: Re: dst = src rather than src dst


 In reality, it's a type definition - the keyword typedef is closer in
 meaning to struct, class or enum (or in C++, namespace) than anything
 else. In fact,

  typedef B A;

 could reasonably be rewritten in D2.0+ as

  struct A
  {
   B b;
   alias b this;
  }



For that matter, if struct inheritance syntax is ever allowed,

 typedef B A;

could be rewritten as

 struct A : B {}


which really makes it really, really clear that "typedef" is not a declaration. 
Come to think of it, "typedef" is short for TYPE DEFinition, so it's very 
/name/ tells you it's a definition, not a declaration. Of course, that struct 
trick won't work for alias.




Also, let's not forget that alias has many other uses beyond replacing C's 
typedef. Those other uses more than justify having a different syntax. There is 
no logic in saying that

 alias long_and_complicated.name.For!(Something) i;

needs to be that way round, purely because of how typedef evolved in C.
Sep 06 2007