Le 07/04/2012 09:10, Johannes Pfau a écrit :
But as long as you mark attribute structs in some special way (@attribute struct Author), this can also be guaranteed for structs. Afaik ignoring unused functions is currently done by the linker, but I think functions/structs only used for attributes should probably never make it to the linker. I think we already had cases were linkers didn't strip unused functions for some reason?Regarding code bloat: If struct initializers could be used with attributes, a constructor isn't necessary and the minimal code is: ------ @attribute struct Author { string name; } @Author("Johannes Pfau") int test; or @Author{name: "Johannes Pfau"} int test; ------ That's exactly as much code as using functions: ------ @attribute string Author(string name) { return name; } @Author("Johannes Pfau") int test; ------ I don't have a strong opinion whether storable types should be limited to structs, but I think classes add little benefit and complicate things because of inheritance (at least if you query attributes by type). What we want to do here is store _data_ and the D style is to use structs for pure data. Basic types could be useful too but when querying by type, those can't work well.
For basic type : alias int foobar; @foobar(2) someDeclaration; No benefit in introducing a new syntax.
BTW: I think there's one thing both your and my proposals are missing: The function/constructor returning the data must be pure: We can't guarantee this function will be executed only once, but the value of the attribute should always be the same. Consider this scenario: a.d ---- @RandomNumber() int test; ---- b.d --- auto value1 = __traits(getAttribute, a.test, RandomNumber); --- c.d --- auto value2 = __traits(getAttribute, a.test, RandomNumber); --- All files are compiled individually. Now the compiler has to call RandomNumber() 2 times: one time for b.d and one time for c.d, but value1 should be the same as value2.
RandomNumber is something that shouldn't be CTFEable, if it does what the name says.
