The Wrong Stuff

[bearophile]

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