I know this has probably been asked for a hundred times before, but I don't understand why D doesn't support this. Template alias parameters can accept nearly anything as an argument that standard aliases don't. I think standard aliases should be equally as powerful as their template counterpart.

If you can write this:
template Eval(alias arg){ alias arg Eval; }
alias Eval!(cond ? a : b) al;

Why not simply allow this?
alias (cond ? a : b) al;

Or perhaps this:
alias al = cond ? a : b;

On Monday, 23 April 2012 at 03:17:49 UTC, Xinok wrote:
> I know this has probably been asked for a hundred times before, but I don't understand why D doesn't support this. Template alias parameters can accept nearly anything as an argument that standard aliases don't. I think standard aliases should be equally as powerful as their template counterpart.
>
> If you can write this:
> template Eval(alias arg){ alias arg Eval; }
> alias Eval!(cond ? a : b) al;
>
> Why not simply allow this?
> alias (cond ? a : b) al;
>
> Or perhaps this:
> alias al = cond ? a : b;

Do equivalent expressions instantiate the same template?

class Foo(alias E) {}
int x, y;
alias (x + y) A;
alias (x + y) B;
alias (y + x) C;

Are Foo!A and Foo!B the same type? What about Foo!C?

Either way, it will require name-mangling of arbitrary expressions, which is just plain nasty.

On Monday, 23 April 2012 at 12:25:21 UTC, Peter Alexander wrote:
> On Monday, 23 April 2012 at 03:17:49 UTC, Xinok wrote:
>> I know this has probably been asked for a hundred times before, but I don't understand why D doesn't support this. Template alias parameters can accept nearly anything as an argument that standard aliases don't. I think standard aliases should be equally as powerful as their template counterpart.
>>
>> If you can write this:
>> template Eval(alias arg){ alias arg Eval; }
>> alias Eval!(cond ? a : b) al;
>>
>> Why not simply allow this?
>> alias (cond ? a : b) al;
>>
>> Or perhaps this:
>> alias al = cond ? a : b;
>
> Do equivalent expressions instantiate the same template?
>
> class Foo(alias E) {}
> int x, y;
> alias (x + y) A;
> alias (x + y) B;
> alias (y + x) C;
>
> Are Foo!A and Foo!B the same type? What about Foo!C?
>
> Either way, it will require name-mangling of arbitrary expressions, which is just plain nasty.

I think you've misunderstood the poster as "cond ? a : b" must
fold and Eval(alias arg) receives a compile time value. That
makes it no different from doing just enum al = cond ? a: b;
Which brings us to an interesting point that alias and enum
should be brought together:

    alias x = 1;
    alias y = int;

should replace current

    enum x = 1;
    alias int y;

respectively. This is makes it a consistent syntax and behavior
for alias declarations(no reverse order compared to normal
assignments which is a legacy of C's typedef) and also fixes enum
storage class which name is not relevant anymore.

On Monday, 23 April 2012 at 14:53:38 UTC, Eldar Insafutdinov wrote:
> Which brings us to an interesting point that alias and enum
> should be brought together:
>
>     alias x = 1;
>     alias y = int;
>
> should replace current
>
>     enum x = 1;
>     alias int y;
>
> respectively. This is makes it a consistent syntax and behavior
> for alias declarations(no reverse order compared to normal
> assignments which is a legacy of C's typedef) and also fixes enum
> storage class which name is not relevant anymore.

+1, but I know this has been brought up before. And there's zero chance it will happen if it doesn't also allow earlier (C/C++/D) usage.

IMHO, using "enum" as a keyword for declaring constants is confusing and is a wart on an otherwise elegant* language. I know that the reason it is used is because under the covers constant declarations and enums are the same thing. But this is a classic case of leaving the human interface up to the engineers. Not everyone (and, in this case, hardly anyone) has the background to see that.

*Elegance is, of course, highly subjective. And I know that there are other cases of problematic syntax. It just seems to me that replacing "enum" is almost painless. (Not replacing, exactly -- "enum" should still work. But there should be an alternative keyword. Way back when this was first brought up there were several keywords proposed but none were entirely satisfactory, so we kind of settled for "enum".)

It makes me want to use:

    alias enum constant;

Paul

A couple of examples of earlier discussions:

http://www.digitalmars.com/d/archives/digitalmars/D/Non-enum_manifest_constants_Pie_in_the_sky_102248.html

http://www.digitalmars.com/d/archives/digitalmars/D/Manifest_constants_why_enum_instead_of_invariant_70595.html

On 04/23/2012 05:17 AM, Xinok wrote:
> I know this has probably been asked for a hundred times before, but I
> don't understand why D doesn't support this. Template alias parameters
> can accept nearly anything as an argument that standard aliases don't. I
> think standard aliases should be equally as powerful as their template
> counterpart.
>

Note that standard aliases and template aliases have an overlapping set of features but both support some aliasees that the other one does not. (So no one is strictly more powerful than the other.) I really think this should be fixed, but Walter has never discussed the point when this issue was brought up in the past.