UDAs on enum members

[Jacob Carlborg via Digitalmars-d]

On 2016-07-17 19:01, Jonathan M Davis via Digitalmars-d wrote:

> Mabye some of them are actually tortoises? ;)
>
> D's features rarely seem to be implemented as "turtles all the way down" to
> begin with. That's usually something that comes later after folks complain
> about something that they think is inconsistent. And it's sometimes
> disputable as to whether something counts as being "turtles all the way
> down" or whether it would actually be a good idea to _not_ do "turtles all
> the way down" (for instance, some of the way that attributes are applied
> such that you're allowed to put them on all kinds of things where they don't
> apply but don't get an error is arguably a case of "turtles all the way
> down," but it's also quite problematic at least some of the time).
>
> In this particular case, I have no idea whether it would be a good idea or
> not, but it is a bit similar to applying UDAs to variables, which would be
> rather odd (though per the OP, it sounds like it's legal to put them on
> member variables;

I'm using UDA's on instance variables in my serialization library:

class Foo
{
     int a;
     @nonSerialized int b;
}

I could also imagine more use cases for a serialization library:

class Foo
{
     @name("a") int _a;
     @verison_(2) int b;
}

Other use cases would be to communicate to other applications. In 
Objective-C #defines are used in the code to indicate which instance 
variables and functions/actions can be connected in Interface Builder. 
In D, UDA's would be a perfect fit for that:

class Foo
{
     @IBOutlet NSButton button;
     @IBAction void onClick(NSButton sender) {}
}

> I don't have any experience with UDAs though, so I'm not
> sure what their restrictions are exactly). And if you can put UDAs on enum
> members the way that the OP is looking to do, that immediately poses the
> question of whether something like
>
> enum @MyUDA foo = "hello world";

I don't see why this shouldn't be possible.

> should be legal, and if we do that, we're pretty much at the point that any
> variable should be allowed to have a UDA, which seems pointless and
> overcomplicated to me - particularly with regards to local variables.

I don't see a reason not allowing UDA's on local variables either. You 
might say that it's not possible to access local variables, true, but 
the compiler might not be the only tool that analyzes the source code. I 
just suggested in another thread [1] that a UDA could be used on a local 
variable and then be interpreted by an external tool, I didn't even 
think that UDA's could not be used on local variables.

Going back to the Objective-C example with IBOutlet/IBAction. IBOutlet 
is a #define which expands to nothing and IBAction expands to "void". 
Clang recognizes these #defines [2], not because the compiler needs to 
but because Clang is used to build other tools that analyzes source 
code, in this case Xcode/Interface Builder.

> I expect that if there's a good enough, practical argument to be made, then we
> could end up with UDAs on enum members, but that argument is going to have
> to be made such that Walter and Andrei are convinced, which may or may not
> be easy. But anyone who feels strongly about this should consider putting
> together a DIP.

A naive implementation could allow to put attributes on all 
declarations, but that would then allow meaningless code like adding 
"private" to a locale variable. But when it comes to UDA's, a single UDA 
doesn't have a semantic meaning itself, like "private" does.

For a programming language to be useful it needs to be designed in a way 
that allows the users to implement things that the designers have not 
thought of. Adding artificial restrictions because the designers can not 
come up with a use case goes very much against this.

[1] http://forum.dlang.org/post/nmg142$2ji1$1@digitalmars.com

[2] 
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013

-- 
/Jacob Carlborg