custom attribute proposal (yeah, another one)

deadalnix deadalnix at gmail.com
Sat Apr 7 04:24:25 PDT 2012


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.


More information about the Digitalmars-d mailing list