I'm almost finishing the AST nodes "à la JDT" for the Descent plugin, and I run into the following:

A typical alias declaration is:

# alias int Foo;

But this is also allowed:

# alias const x = 1;

Now, the AST nodes must record enough information to fully reflect what is written in the source code. Currently in DMD the last sentence is turned into a VarDeclaration that saves the storage class (const), the variable name (x) and the initializer (1, which is mandatory for this class of declarations). So the "alias" keyword is lost, and if you modify the AST and rewrite, it will definitely be lost.

So it seems the "alias" keyword isn't changing anything, so rewriting it as "const x = 1;" it's the same. Should I care about keeping the "alias" keyword or not? It's pretty much easier for me not to keep it.

Any suggestion?

(the same happens if "typedef" is used instead of "alias")

BTW, while building the AST I found out that any declaration can be preceded with modifiers. Sometimes it's pretty funny but luckily makes no harm, so I'm not complaining for this anymore. For example:

# abstract static if (true) { }
> Will it evaluate? It's abstract :-P

# final static assert("D rules");
> Now that's a final assert!

# override debug = 1;
> If I defined it previously, now I can make it clear that I'm overriding it

Etc.

Thanks,
Ary

Ary Manzana wrote:
> I'm almost finishing the AST nodes "à la JDT" for the Descent plugin, and I run into the following:
> 
> A typical alias declaration is:
> 
> # alias int Foo;
> 
> But this is also allowed:
> 
> # alias const x = 1;
> 
> Now, the AST nodes must record enough information to fully reflect what is written in the source code. Currently in DMD the last sentence is turned into a VarDeclaration that saves the storage class (const), the variable name (x) and the initializer (1, which is mandatory for this class of declarations). So the "alias" keyword is lost, and if you modify the AST and rewrite, it will definitely be lost.
> 
> So it seems the "alias" keyword isn't changing anything, so rewriting it as "const x = 1;" it's the same. Should I care about keeping the "alias" keyword or not? It's pretty much easier for me not to keep it.
> 
> Any suggestion?
> 
> (the same happens if "typedef" is used instead of "alias")
> 
> BTW, while building the AST I found out that any declaration can be preceded with modifiers. Sometimes it's pretty funny but luckily makes no harm, so I'm not complaining for this anymore. For example:
> 
> # abstract static if (true) { }
>  > Will it evaluate? It's abstract :-P
> 
> # final static assert("D rules");
>  > Now that's a final assert!
> 
> # override debug = 1;
>  > If I defined it previously, now I can make it clear that I'm overriding it
> 
> Etc.
> 
> Thanks,
> Ary

Yes, unfortunately it really is that DMD allows modifiers in many declarations where it does not make any sense (and that's according to spec grammar). I would suggest Walter should fix this eventually, in the meanwhile (which I suspect may be long), we can either try to be fully DMD compliant, or start creating our own view of what modifiers are allowed or not. I personally favor this later one, since the first is IMO broken, and may lead to extra unnecessary work in the (AST) implementation.

-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Bruno Medeiros escribió:
> Ary Manzana wrote:
>> I'm almost finishing the AST nodes "à la JDT" for the Descent plugin, and I run into the following:
>>
>> A typical alias declaration is:
>>
>> # alias int Foo;
>>
>> But this is also allowed:
>>
>> # alias const x = 1;
>>
>> Now, the AST nodes must record enough information to fully reflect what is written in the source code. Currently in DMD the last sentence is turned into a VarDeclaration that saves the storage class (const), the variable name (x) and the initializer (1, which is mandatory for this class of declarations). So the "alias" keyword is lost, and if you modify the AST and rewrite, it will definitely be lost.
>>
>> So it seems the "alias" keyword isn't changing anything, so rewriting it as "const x = 1;" it's the same. Should I care about keeping the "alias" keyword or not? It's pretty much easier for me not to keep it.
>>
>> Any suggestion?
>>
>> (the same happens if "typedef" is used instead of "alias")
>>
>> BTW, while building the AST I found out that any declaration can be preceded with modifiers. Sometimes it's pretty funny but luckily makes no harm, so I'm not complaining for this anymore. For example:
>>
>> # abstract static if (true) { }
>>  > Will it evaluate? It's abstract :-P
>>
>> # final static assert("D rules");
>>  > Now that's a final assert!
>>
>> # override debug = 1;
>>  > If I defined it previously, now I can make it clear that I'm overriding it
>>
>> Etc.
>>
>> Thanks,
>> Ary
> 
> Yes, unfortunately it really is that DMD allows modifiers in many declarations where it does not make any sense (and that's according to spec grammar). I would suggest Walter should fix this eventually, in the meanwhile (which I suspect may be long), we can either try to be fully DMD compliant, or start creating our own view of what modifiers are allowed or not. I personally favor this later one, since the first is IMO broken, and may lead to extra unnecessary work in the (AST) implementation.
> 

I will do that in the Descent plugin. It will show you, only as warning, something like "This token has no effect, remove it". It'll still be DMD compliant, since they are only warnings, not errors, and one would be abe to turn them off. :-)