shared and getParameterStorageClasses bug?

[Petar]

On Saturday, 22 August 2020 at 18:34:21 UTC, Jean-Louis Leroy 
wrote:
> 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 
entities:
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.

Semantically:

    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).

[0]: https://dlang.org/spec/grammar.html#TypeCtor
[1]: https://dlang.org/spec/grammar.html#StorageClass
[2]: https://dlang.org/spec/grammar.html#Parameters
[3]: https://dlang.org/spec/grammar.html#MemberFunctionAttributes