• "Janice Caron" <caron serenityfirefly.com> Sep 05 2007
• Bill Baxter <dnewsgroup billbaxter.com> Sep 05 2007

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

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