shared and getParameterStorageClasses bug?

Jean-Louis Leroy jl at leroy.nyc
Sun Aug 23 13:44:30 UTC 2020


On Sunday, 23 August 2020 at 06:42:02 UTC, Petar Kirov 
[ZombineDev] wrote:

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

Thanks. Then my follow-up question is: how do I retrieve the 
parameter type constructors? Without resorting on scanning the 
stringified parameter like here:

enum isSharedParameter(alias fun, uint param) =
   Parameters!fun[param..param+1].stringof.indexOf("shared") != -1;

(of course this is not robust: it would give false positives with 
types that contain the substring "shared").

My actual goal is to extract them in the same fashion as the 
storage classes, e.g.:

void foo(lazy const shared Object);
static assert(parameterTypeConstructors!foo == tuple("const", 
"shared"));

Do I really have to parse a string like "(lazy 
shared(const(Object)))"? And, how reliable would this solution be?







More information about the Digitalmars-d mailing list