Started a new thread on this.

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.

I think restricting to user types makes sense because the type is how you'd actually do anything with it.

My figuring is you'd generally do something like this:


foreach(t; __traits(getAttributes, foo))
   static if(is(t == WhatICareAbout)) {
     // use it
   }



And if what you care about is something like string or int, how do you know it semantically means what you think it means?

On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright wrote:
> 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?

What if you are using two different libraries in X that require you to annotate something with a string?

On Wednesday, 7 November 2012 at 23:18:41 UTC, Walter Bright wrote:
> 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?

Wasn't the @every_body_writes_their_names_like_this in C earlier in this thread yours? The problem is that without resorting to some kind of »unique« prefix convention, there will inevitably be modules X and Y which use the same annotation string for different purposes, creating problems if both modules are used together in the same code base (think passing a symbol from X to a template in Y, or an user wanting to create a type which is passed to both X and Y).

I feel this is of particular significance here, as I think attributes are primarily going to be used in this kind of library context, where you allow the library user to mark their symbols up in a way that effects your library's behavior on said symbols.

David

On 2012-11-08, 00:18, Walter Bright wrote:

> Started a new thread on this.
>
> 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.

I'm not sure what the correct answer is here, but I think the solutions
are either to allow any old type as a UDA, or have @attribute structs or
something along those lines. Just user defined types is a weird restriction.

-- 
Simen

On 11/08/2012 12:18 AM, Walter Bright wrote:
> Started a new thread on this.
>
> 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.

This is a valid point, and I think it does not really make sense to only exclude built-in types. Any type not intended for use as an attribute and that is exported to sufficiently many places can have the same behaviour.
I'd vote no restrictions at all, or for requiring @attribute annotations on the user-defined type and ban user-defined types from being annotations that do not have that.

On 2012-11-08 00:18, Walter Bright wrote:

> 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.

I think we should only allow user defined types marked with @attribute, i.e.

@attribute struct foo {}
@attribute class foo {}
@attribute interface foo {}
@attribute enum foo {}

And so on.

-- 
/Jacob Carlborg

On Thursday, 8 November 2012 at 09:05:31 UTC, Jacob Carlborg wrote:
> I think we should only allow user defined types marked with @attribute, i.e.
>
> @attribute struct foo {}
> @attribute class foo {}
> @attribute interface foo {}
> @attribute enum foo {}
>
> And so on.

Or
struct @foo {}
interface @foo {}
enum @foo {0
etc

On 2012-11-08, 11:56, simendsjo wrote:

> On Thursday, 8 November 2012 at 09:05:31 UTC, Jacob Carlborg wrote:
>> I think we should only allow user defined types marked with @attribute, i.e.
>>
>> @attribute struct foo {}
>> @attribute class foo {}
>> @attribute interface foo {}
>> @attribute enum foo {}
>>
>> And so on.
>
> Or
> struct @foo {}
> interface @foo {}
> enum @foo {0
> etc
>

That's actually a very reasonable idea. votes++

-- 
Simen

On 2012-11-08 11:56, simendsjo wrote:

> Or
> struct @foo {}
> interface @foo {}
> enum @foo {0
> etc

That syntax looks a bit backwards to me. What if I want to annotate the attribute.

@serializable struct @foo {}

Looks a bit confusing which is the name of the attribute and the which is the attached annotation.

Vs

@serializable @attribute struct foo {}

No confusion here, "foo" is the name of the attribute, the rest is attached annotations.

-- 
/Jacob Carlborg