User Defined Attributes (UDA) in Phobos/druntime

QAston qaston at gmail.com
Tue Jun 11 09:12:32 PDT 2013


On Tuesday, 11 June 2013 at 07:00:29 UTC, Jacob Carlborg wrote:
> This was brought up in the thread reviewing std.serialization:
>
> http://forum.dlang.org/thread/adyanbsdsxsfdpvoozne@forum.dlang.org
>
> Currently we haven't started to use UDA's in Phobos or druntime 
> yet (as far as I know). I would like to start a discussion 
> about putting out some guidelines for using UDA's in 
> Phobos/druntime.
>
> I've created a small module that handles UDA's:
>
> https://github.com/jacob-carlborg/orange/blob/master/orange/core/Attribute.d
>
> The idea is to have a kind of meta UDA called "attribute". This 
> attribute needs to be attached to all structs, enums and so on 
> that is to be used as an attribute.
>
> The module provides a template (getAttributes) to get, by 
> default, only those values attached to a given symbol that is 
> an attribute. That is, marked with the "attribute" attribute.
>
> So my suggestion for guidelines are:
>
> * Only types with the "attribute" UDA is to be used as 
> attributes
> * In general, don't use primitive values as a UDA
>
> Don't use this
>
> @(3) int a;
>
> Use this:
>
> @attribute struct foo { int b; }
>
> @foo(3) int a;
>
> * A user defined type marked with "attribute" should not be 
> used for something else than an UDA
>
> * All attributes use camel case names
>
> If we agree on this and that we need a module like the one 
> above I think it should be added to druntime. The reason for 
> that is that we most likely want to use UDA's in druntime and 
> not only in Phobos. Example, if we ever get std.serialization 
> into Phobos we would want to mark Thread and similar 
> structs/classes as "nonSerialized".
>
> Thoughts?

I agree that attributes should have types - that way it's easily 
recognizable what are they for in code. "Anonymous" attributes 
seem to me to be sort of like "you can throw ANYTHING in c++" 
feature - it's there, but probably without a sane use case.
Could you explain to me what's the benefit of the @attribute 
convention you introduce? It seems non-obvious to me.


More information about the Digitalmars-d mailing list