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