Don:
> The only value I can see at this point in making something an @attribute
> rather than a __keyword is that we could develop a standard syntax for
> compile-time (and runtime) querying of attributes.
I think you need:
1) To be able to import an user-defined attribute in just the current
scope/module, using a normal import:
import myattributes: @noallocs;
Or just:
import myattributes: noallocs; // the @ is not used when you import it
2) More compile-time introspection capabilities. To implement in D a
user-defined attribute like @noallocs you need some way to transitively inspect
the code inside a function, looking for heap memory allocations.
3) Some syntax to attach CTFE functions to user attributes. The simplest design
is to do nothing, and allow any function name to be used with a @ prefix. The
argument of such functions may be the AST of the function the attribute is put
on, its JSON or even its body as text.
Then when you add @noallocs to a function signature the compiler runs at
compile-time the code that performs those tests:
@noallocs int myLevenshteinDistance(T)(const T[] data) { ... // gives a
compile-time error because it contains one new statement.
The JSON DMD produces from modules may be used by some attributes, because it
contains lot of semantics about the functions in a easy machine-readable way.
Something like __traits(json, functionname), plus few Phobos functions to
transverse and query a Json tree structure, may be useful for some attributes.
Such attributes may be useful to create in simple ways pluggable type systems,
that is extensions to the type system (@noallocs is essentially a way to ensure
a transitive function tree doesn't do something you don't want it to do, so
it's a little extension to the type system). The Mozilla Dehydra/Treehydra does
the same things, but it uses JavaScript to write the attributes and the syntax
is worse. Recently I have shown something about a tool written to test the
source code of Linux, it's essentially a plugged-in type system added to the
normal C type system, and its purpose is to avoid some bugs in the kernel code.
My theory is that such little extensions to the type system, fit for specific
purposes, will become very useful in languages. D has a chance to do this in an
almost transparent way.
Bye,
bearophile
