View mode: basic / threaded / horizontal-split · Log in · Help
November 07, 2012
UDAs - Restrict to User Defined Types?
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.
November 07, 2012
Re: UDAs - Restrict to User Defined Types?
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?
November 07, 2012
Re: UDAs - Restrict to User Defined Types?
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?
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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.
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
November 08, 2012
Re: UDAs - Restrict to User Defined Types?
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
« First   ‹ Prev
1 2 3 4 5
Top | Discussion index | About this forum | D home