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/[email protected]
[2]
http://clang.llvm.org/doxygen/group__CINDEX.html#gaaccc432245b4cd9f2d470913f9ef0013
--
/Jacob Carlborg
