www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - basic types and alias

reply Timon Gehr <timon.gehr gmx.ch> writes:
alias int I; // OK
template T(alias I){}
mixin T!int; // NG

Is there any reason why we should not get rid of this inconsistency as 
fast as possible? What does not accepting basic types as template alias 
parameters buy anyone?
Feb 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2012 11:27 AM, Timon Gehr wrote:
 alias int I; // OK
 template T(alias I){}
 mixin T!int; // NG

 Is there any reason why we should not get rid of this inconsistency as fast as
 possible? What does not accepting basic types as template alias parameters buy
 anyone?

alias parameters accept symbols. Keywords are not symbols. To pass a type, just use template T(I).
Feb 12 2012
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 02/12/2012 09:44 PM, Walter Bright wrote:
 On 2/12/2012 11:27 AM, Timon Gehr wrote:
 alias int I; // OK
 template T(alias I){}
 mixin T!int; // NG

 Is there any reason why we should not get rid of this inconsistency as
 fast as
 possible? What does not accepting basic types as template alias
 parameters buy
 anyone?

alias parameters accept symbols. Keywords are not symbols.

I know what the status quo is. I was suggesting it might be a sub-optimal design rooted in some arbitrary restriction that originated from the compiler implementation. Therefore I was asking what the rationale for such design would be. Furthermore, alias declarations accept symbols and built-in types.
 To pass a type, just use template T(I).

The only workaround is to use template T(I...) if(I.length==1){}. Why does it make sense to treat alias parameters differently from alias declarations and tuple members? Why does it make sense to treat built-in types differently from user-defined types in this case?
Feb 12 2012
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 2/12/2012 12:59 PM, Timon Gehr wrote:
 The only workaround is to use template T(I...) if(I.length==1){}. Why does it
 make sense to treat alias parameters differently from alias declarations and
 tuple members? Why does it make sense to treat built-in types differently from
 user-defined types in this case?

They really aren't the same thing, although alias declarations try to conflate the two, causing ugly hacks.
Feb 14 2012
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 02/14/2012 09:54 AM, Walter Bright wrote:
 On 2/12/2012 12:59 PM, Timon Gehr wrote:
 The only workaround is to use template T(I...) if(I.length==1){}. Why
 does it
 make sense to treat alias parameters differently from alias
 declarations and
 tuple members? Why does it make sense to treat built-in types
 differently from
 user-defined types in this case?

They really aren't the same thing,

That is my point: they should be, wherever practical.
 although alias declarations try to
 conflate the two, causing ugly hacks.

What kind of ugly hacks? Conflating them as much as possible is the right thing to do. This makes alias declarations, alias parameters and tuple parameters uniform. It is a special case less to remember and/or get confused about.
Feb 14 2012
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Sun, 12 Feb 2012 15:44:22 -0500, Walter Bright  
<newshound2 digitalmars.com> wrote:

 On 2/12/2012 11:27 AM, Timon Gehr wrote:
 alias int I; // OK
 template T(alias I){}
 mixin T!int; // NG

 Is there any reason why we should not get rid of this inconsistency as  
 fast as
 possible? What does not accepting basic types as template alias  
 parameters buy
 anyone?

alias parameters accept symbols. Keywords are not symbols. To pass a type, just use template T(I).

Yeah, but types can be keywords, and types can be symbols. There are good use cases to being able to alias int in a template. This works: // would have used typedef, but typedef is deprecated... struct S { int ___val; alias ___val this; } template T(alias I) {} mixin T!S; I don't see the reason to present such an obstacle. You could ease the restriction to "you can alias only symbols or keywords that could be aliased to symbols". -Steve
Feb 17 2012