On Wednesday, 21 March 2012 at 17:26:19 UTC, Adam D. Ruppe wrote:
The compiler keeping a list of notes attached to the
declaration remains the only *right* way to do it.
Another note on correctness btw, this thing is wrong
if in other modules.
mixin Note!(a, q{ NotSerialized() });
that string loses the exact type. But, let's
say we solved that, and uses the module name
or something.
But then, what if:
module cool;
import serialization.attributes;
struct cool {
int a;
mixin Note!(a, serialization.attributes.amazing);
}
==
// another module
import cool;
void main() {
getNotes!(cool.cool.a);
}
That won't compile. When it tries to mixin the note,
it will say undefinied identifier "amazing" because
the mixin is evaluated in another scope than the original
declaration.
So while module cool imported serilization.attributes,
module main or module notes (I'm not sure exactly where this
is mixed in by the time we're all said and done tbh but it
doesn't matter) has not.
Thus the mixin will fail.
I had this same problem when trying to do default arguments
in web.d by parsing stringof and mixing it in.
It works for built-in types like string and int, but
it doesn't work for user defined types, which are perfectly
valid function params (they work fine in the rest of web.d).
But the mixin scope is wrong so those types become undefined.
Again, we can get kinda close with these D tricks, but it
just cannot go all the way - and much of the interesting stuff
is behind that barrier.
The compiler can do it easily though, and get it right, enabling
us to do a lot more in the library down the line.
