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?

-- 
/Jacob Carlborg

On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
> Thoughts?

I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
> On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
>> Thoughts?
>
> I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

Wise words. +1

On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
> On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
>> Thoughts?
>
> I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

Though I might not agree with this suggested meta-attribute thing I really think that serialization screams for using attributes to mark fields/classes as serializable. Would be sad not to have them.

Jacob: Would it be doable to refactor the attribute magic in std.serialization into a separate module that could be provided as 3rd party extension to std.serialization until phobos itself is ready for attributes?

/Jonas

On 2013-06-11 11:07, Jonas Drewsen wrote:

> Jacob: Would it be doable to refactor the attribute magic in
> std.serialization into a separate module that could be provided as 3rd
> party extension to std.serialization until phobos itself is ready for
> attributes?

The generic code for attributes is located in orange.core.Attribute, this can be inlined or removed. The actual attributes them self are located in orange.serialization.Serializable.

The library is perfectly usable without UDA's. The old template mixins are still available.

If __traits(getAttributes) is not allowed in Phobos then I have to remove the code that checks for UDA's.

-- 
/Jacob Carlborg

On 2013-06-11 11:58, Jacob Carlborg wrote:

> The library is perfectly usable without UDA's. The old template mixins
> are still available.

The template mixins basically emulates UDA's.

-- 
/Jacob Carlborg

On Tuesday, 11 June 2013 at 07:00:29 UTC, Jacob Carlborg wrote:
> 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

Camel case has two versions - and I suggest to use the one that starts with capital - that is, `@attribute struct FooBar` and not `@attribute struct fooBar`. This will save a lot of trouble when we want to add new keyword attributes.

The exception is the `attribute` attribute itself - in the future we might want to make it a keyword attribute(so we can, for example, enforce it's usage for attributes), and it that case it would be helpful if all UDAs already use it.

On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
> On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
>> Thoughts?
>
> I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.

I disagree - if you wait for UDAs to appear more in user-code, you'll end up with multiple conventions for using them. If they are used in Phobos/druntime first, users will conform to the Phobos/druntime convention.

On Tuesday, 11 June 2013 at 14:59:44 UTC, Idan Arye wrote:
> On Tuesday, 11 June 2013 at 07:36:44 UTC, Walter Bright wrote:
>> On 6/11/2013 12:00 AM, Jacob Carlborg wrote:
>>> Thoughts?
>>
>> I'd like to see more use of UDAs in non-Phobos code so we can figure out best practices from experience before putting it into Phobos, where we'll be stuck with any bad decisions.
>
> I disagree - if you wait for UDAs to appear more in user-code, you'll end up with multiple conventions for using them.

That's what we want, surely: Multiple conventions appear, then with the benefit of hindsight the best can be selected for phobos.

On Tue, 11 Jun 2013 05:58:50 -0400, Jacob Carlborg <doob@me.com> wrote:

> On 2013-06-11 11:07, Jonas Drewsen wrote:
>
>> Jacob: Would it be doable to refactor the attribute magic in
>> std.serialization into a separate module that could be provided as 3rd
>> party extension to std.serialization until phobos itself is ready for
>> attributes?
>
> The generic code for attributes is located in orange.core.Attribute, this can be inlined or removed. The actual attributes them self are located in orange.serialization.Serializable.
>
> The library is perfectly usable without UDA's. The old template mixins are still available.
>
> If __traits(getAttributes) is not allowed in Phobos then I have to remove the code that checks for UDA's.
>

I think we can have and use UDAs in Phobos without yet having to create a guideline.  Note that there is lots of experience with attributes in other languages that we can draw from.  Most people here have written in at least one other language that uses them.

I have no problem with std.serialization using attributes, even if there is no "official" guide.

-Steve