Const template

[Frits van Bommel]

Andrei Alexandrescu (See Website For Email) wrote:
> Walter Bright wrote:
>> My objections to the C++ const are:
>>
>> 1) there are *legal* ways to subvert it, meaning it is useless as a 
>> semantic aid and useless to the optimizer/code generator
>> 2) it confuses a type modifier with a storage class (exhibiting 
>> muddled special case behaviors)
> 
> Let me point out that D's current handling of the storage classes is 
> broken. D defines the 'inout' and 'out' storage classes which are 
> undetectable for templates and break any template code that needs to 
> deal with them. (Why in the world was 'out' ever needed? Probably the 
> "working with IDL" assumption should be revisited.) Then, to add insult 
> to injury, D defines the 'lazy' storage class that changes the access 
> syntax (something that a storage class is not supposed to do), does not 
> allow assignment from the same type (although it should), and again 
> can't work with any template code.

"in", "out", "inout" and "lazy" aren't storage classes.
http://www.digitalmars.com/d/declaration.html (in the big syntax block 
at the top):
-----
StorageClass:
         abstract
         auto
         const
         deprecated
         extern
         final
         override
         scope
         static
         synchronized
-----
and later:
-----
InOut:
         in
         out
         inout
         lazy
-----

They're more like parameter passing conventions:
* You can only use one per parameter
* You can't declare a global variable to be 'lazy' ;).
* You can't declare a parameter to be 'abstract', 'auto', 'const', ...

They're pretty distinct concepts. They just look similar because they're 
used in such similar positions (typically before a type + name), but in 
two different contexts.

I do agree that it's weird the access syntax is changed by a parameter 
passing convention.




By the way, looking at that part of the spec I noticed something weird. 
I can't find the path that would allow "(int x)" to be a valid parameter 
list. /Parameter/ has 4 cases. In this case "Declarator" would be the 
obvious clause (no '=', no in/out). But /Declarator/ doesn't seem to 
allow 'int' at the start (or any basic type for that matter). It just 
allows:
* type suffixes (*, [], [ /Expression/ ], delegate /Parameters/, 
function /Parameters),
* /Identifier/ (which doesn't include basic types as they're keywords),
* parenthesized /Declarator/
* /Identifier/ /DeclaratorSuffixes/ (see /Identifier/ case)
* parenthesized /Declarator/ followed by /DeclaratorSuffixes/ (see case 
before previous)

This seems to be an oversight; in /Decl/ the type (/BasicType/) is put 
before every instance of /Declarators/. Perhaps they were lifted out 
when auto declarations were added but the /Declarator/ in the parameter 
list syntax was overlooked?