If D will want to introduce user-defined @attributes then I think it's better
to pre-adapt the language & compiler to them. To define many attributes you
first need a good amount of static introspection.
Example: how do you define a @pure (similar to the built-in "pure" keyword) in
user-code? Let's say there is no syntax yet to define @attributes. Then you use
just a static assert:
int foo(int x) { return x * x; }
static assert(isPure!foo);
isPure() is a compile-time function that later may become a @pure, when there
is syntax to define user attributes.
But before the syntax for user-defined attribute the language needs means to
create isPure(). To do this some more __traits are enough. Given the name of a
function a trait may list its variables, another trait may give a list of the
functions it calls, etc. With another trait to list the global variables and
some recursive code I think you become able to write isPure().
Once such static introspection is present, and later when there is syntax to
define user attributes, then in theory you are even able to remove "pure" from
D2/D3 and just keep @pure in the object module.
More power allows some DMD front-end code to be removed to become user code (or
almost user code if it's in object).
(There are @attributes that probably need to perform run-time computations, so
the kind of @attributes I have described in this post is not the whole picture).
Bye,
bearophile
