Definitive list of storage classes

[Jakob Ovrum]

On Saturday, 14 April 2012 at 17:50:39 UTC, Jonathan M Davis 
wrote:
> That's clearly not the list, since it includes const, 
> immutable, and shared,
> which are type qualifiers rather than storage classes. It also 
> has stuff like
> init in it, which isn't even vaguely a storage class. All of 
> the storage
> classes may be in that list, but I don't know how you'd figure 
> out which ones
> they are from that list.

Obviously D has inherited the term "storage class" from C and 
C++, but then expanded use of the term to a point where it's not 
always meaningful any more. I agree that the term needs some work.

`const`, `immutable` and `shared` actually can affect the storage 
of variables in specific situations (e.g. an immutable module 
variable declaration), but we know they are also type qualifiers, 
beyond any doubt. I don't think it would be a stretch to say they 
are both storage classes and type qualifiers, and this is in fact 
how the specification presents it.

I personally think that it's meaningless to classify them as both 
and would prefer their storage class classification be dropped 
from the specification text.

>
>> If I had to guess I'd say 'storage class' meant something much 
>> more specific
>> in C than it does in D, where it seems to mean properties of a 
>> declaration
>> that do not affect the type.
>
> Except that both Walter and Andrei seem to talk about type
> qualifiers/constructors and storage classes as if they meant 
> essentially the
> same thing as in C/C++.

If Walter and/or Andrei have made an executive decision about 
what is and what isn't a storage class, I suggest they submit a 
pull request to dlang.org clarifying its new meaning.

I have a feeling not a lot of thought has gone into this issue 
though, and Walter denying that immutable is a storage class (in 
his Lang.NEXT talk) probably means one of two things, 1) 
immutable is not a storage class in the context he presented, or 
2) he was wrong and it is both a storage class and a type 
qualifier/constructor (per the specification).

> TDPL _does_ sort of try and define it, but not really. It 
> pretty much
> just lists certain modifiers as being storage classes without 
> giving a full
> list or explaining exactly what constitutes a storage class. 
> The closest thing
> that it gives to a definition
>
> "Each function parameter (base and exponent in the example 
> above) has, in
> addition to its type, an optional storage class that decides 
> the way that
> arguments are passed to the function when invoked."
>
> would seem indicate that static (which it later says is a 
> storage class) isn't
> a storage class at all, since storage classes would only apply 
> to function
> parameters (which would also disqualify synchronized as a 
> storage class, which
> would be at odds with the online docs).

He is referring to the *parameter storage classes*, and he's 
actually wrong on one point: a parameter can have multiple 
parameter storage classes as long as they are compatible.

List from the specification on functions:
"Parameter storage classes are in, out, ref, lazy, const, 
immutable, shared, inout or scope."

One point of interest is that you can define a function like:

     void foo(const scope int a);

With the `const` before the `scope` like that. This has to be 
taken into consideration if the definition of a storage class is 
to be revisited.

> So, I'd like an official definition of storage class with a 
> list of what qualifies
> as a one in D. But it wouldn't surprise me at all if Walter's 
> the only one who
> can do that.

Anyone making such a list would probably be making rather 
arbitrary on-the-spot decisions if we don't provide a solid 
definition of what a storage class is in D. As long as we have a 
good definition, anyone could fix the lists.