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?

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

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?

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.

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.

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