On 2012-11-07 21:41, Walter Bright wrote:

> Just functions? I thought one big use of UDAs was to mark classes as
> "serializable".

Exactly, the more we can annotated the better :)

-- 
/Jacob Carlborg

On 2012-11-07 21:38, deadalnix wrote:

>> Adding a whole new aggregate type is a pretty intrusive and major change.

Is it? Just have it behave as a struct or class. But I guess the suggestion below is just as good.

> So let's defined in object.d the following :
>
> @attribute struct attribute {}
>
> And then mark as @attribute anything that may used as attribute.
>
> @attribute struct foo {
>      string name;
> }
>
> @foo("asd") int a;
>
> If wasn't marked as @attribute, it wouldn't be an valid attribute.

I would be happy with this approach as well. But how much difference would it actually be to have:

attribute foo {
    string name;
}

-- 
/Jacob Carlborg

First of all: Awesome.

Secondly: Fastest-growing thread ever? ;)

On Wednesday, November 07, 2012 16:45:20 Nick Sabalausky wrote:
> First of all: Awesome.
> 
> Secondly: Fastest-growing thread ever? ;)

In Announce? Probably. In all of the D groups? Probably not. There have been some _very_ active threads in the main newsgroup. This thread is quite tame in comparison to a number of them. It _is_ very active though.

- Jonathan M Davis

On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
> OK, that's another thing. And maybe a reason for listening to people having
> more experience with UDAs than you.
>
> For me the analogy with Exceptions is pretty good. The issues an conveniences
> of throwing anything or annotating a symbol with anything instead of just
> type are pretty much the same. I only see functions making sense to be accepted
> as annotations too (that's what Python do with annotations, @annotation symbol
> is the same as symbol = annotation(symbol), but is quite a different language).

There's another aspect to this.

D's UDAs are a purely compile time system, attaching arbitrary metadata to specific symbols. The other UDA systems I'm aware of appear to be runtime systems.

This implies the use cases will be different - how, I don't really know. But I don't know of any other compile time UDA system. Experience with runtime systems may not be as applicable.

Another interesting data point is CTFE. C++11 has CTFE, but it was deliberately crippled and burdened with "constexpr". From what I read, this was out of fear that it would turn out to be an overused and overabused feature. Of course, this turned out to be a large error.

One last thing. Sure, string attributes can (and surely would be) used for different purposes in different libraries. The presumption is that this would cause a conflict. But would it? There are two aspects to a UDA - the attribute itself, and the symbol it is attached to. In order to get the UDA for a symbol, one has to look up the symbol. There isn't a global repository of symbols in D. You'd have to say "I want to look in module X for symbols." Why would you look in module X for an attribute that you have no reason to believe applies to symbols from X? How would an attribute for module X's symbols leak out of X on their own?

It's not quite analogous to exceptions, because arbitrary exceptions thrown from module X can flow through your code even though you have no idea module X even exists.

On 11/7/2012 1:45 PM, Nick Sabalausky wrote:
> First of all: Awesome.
>
> Secondly: Fastest-growing thread ever? ;)


The historical UDA threads have been large, too.

Le 07/11/2012 23:20, Walter Bright a écrit :
> On 11/7/2012 3:05 AM, Leandro Lucarella wrote:
>> OK, that's another thing. And maybe a reason for listening to people
>> having
>> more experience with UDAs than you.
>>
>> For me the analogy with Exceptions is pretty good. The issues an
>> conveniences
>> of throwing anything or annotating a symbol with anything instead of just
>> type are pretty much the same. I only see functions making sense to be
>> accepted
>> as annotations too (that's what Python do with annotations,
>> @annotation symbol
>> is the same as symbol = annotation(symbol), but is quite a different
>> language).
>
> There's another aspect to this.
>
> D's UDAs are a purely compile time system, attaching arbitrary metadata
> to specific symbols. The other UDA systems I'm aware of appear to be
> runtime systems.
>
> This implies the use cases will be different - how, I don't really know.
> But I don't know of any other compile time UDA system. Experience with
> runtime systems may not be as applicable.
>

Java is mostly compile time (and optionally runtime). See http://projectlombok.org/ for what can be done at compile time with attributes + compiler hooks.

> Another interesting data point is CTFE. C++11 has CTFE, but it was
> deliberately crippled and burdened with "constexpr". From what I read,
> this was out of fear that it would turn out to be an overused and
> overabused feature. Of course, this turned out to be a large error.
>
> One last thing. Sure, string attributes can (and surely would be) used
> for different purposes in different libraries. The presumption is that
> this would cause a conflict. But would it? There are two aspects to a
> UDA - the attribute itself, and the symbol it is attached to. In order
> to get the UDA for a symbol, one has to look up the symbol. There isn't
> a global repository of symbols in D. You'd have to say "I want to look
> in module X for symbols." Why would you look in module X for an
> attribute that you have no reason to believe applies to symbols from X?
> How would an attribute for module X's symbols leak out of X on their own?
>
> It's not quite analogous to exceptions, because arbitrary exceptions
> thrown from module X can flow through your code even though you have no
> idea module X even exists.
>

Awesome. Lack of UDA has really caused some very ugly workarounds in my code, and it's really nice to see that it's being solved now. Probably one of the most important missing features I've encountered.

I do agree however with preventing any built-in types / literals being used as an annotation. It's just not safe, completely goes around the module system, and is abused in the same way as it would be with C++ exceptions. In C# for example, all attributes are classes derived from Attribute. This makes things a bit more obvious, allows a common base type (probably not needed in D because it's done at compile-time), but is rather hackish in my opinion (plus, in D you may want structs as attributes?). I definitely would like to see something like the @attribute suggestion though. Using types not meant to be used as attributes as attributes is dangerous and leads to conflicts when people want it to mean different things. What does '@Vector3f(1, 1, 1) int a' even mean? What if people use it to mean different things? It's just as confusing as '@3 int a'.

On 11/7/2012 2:40 PM, deadalnix wrote:
> Java is mostly compile time (and optionally runtime). See
> http://projectlombok.org/ for what can be done at compile time with attributes +
> compiler hooks.

Doesn't putting compiler hooks in for them make them inherently global?

started a new thread on this over in digitalmars.D