shared and getParameterStorageClasses bug?

Petar Petar
Sun Aug 23 06:42:02 UTC 2020

On Saturday, 22 August 2020 at 18:34:21 UTC, Jean-Louis Leroy 
> void foo(lazy shared Object);
> pragma(msg, __traits(getParameterStorageClasses, foo, 0)); // 
> tuple("lazy")
> Shouldn't this return a tuple("lazy", "shared)? Given that 
> `shared` is documented as a parameter storage class?

 From a grammar point of view, type qualifiers (`const`, 
`immutable`, `inout` and `shared`) can appear as 4 different 
1. Type constructors [0]
2. Variable storage classes [1]
3. Parameter attributes [2]
4. Member function attributes [3]

Parameter attributes grammatically include both UDAs and 
parameter storage classes (confusingly named `InOut` in the 
spec), so we can actually collapse the grammatical entities
related to variables (which include parameters) to just 2 kinds: 
type constructors and storage classes.


    Q T x;  // A) storage class syntax
    Q(T) x; // B) type constructor syntax

A) and B) are equivalent (where `Q` is some type qualifier and 
`T` is some type).
During semantic processing the compiler erases the difference 
between two by converting qualifiers appearing as storage classes 
to type constructors (IIRC described via `mtype.d`).

Which leaves `lazy`, `in`, `out`, `ref`, `return` and `scope` as 
the only actual parameter storage classes that you can query. 
(`auto ref` is resolved to either `ref` or no storage class 
during IFTI semantic processing).


More information about the Digitalmars-d mailing list