Proposal: user defined attributes

[James Miller]

Sorry for not quoting, but I'm not sure who to quote...

I think people are over-thinking this issue. Adam's initial proposal
was simply to be able to add compile-time checkable data to data
structures and functions. I think this works well at this level. As he
demonstrated, string mixins and ctfe only get you so far in this
instance.

The idea that in order to replicate this functionality, you need to
actually parse the D code to get what you want, is horrific. Relying
on naming conventions for functionality is horrendous, especially when
a simple @note(data1,data2=val) can solve all of the issues. And if
they're only compile time, then it can all be discarded when you get
to code-gen, and if you deliberately limit the scope of them, then you
aren't fostering the "new language features will solve all my
problems".

Looking at other languages is a good start for ideas, but ultimately
we need a D-flavoured solution, and using simple `__trait`-inspectable
annotations is a good way of doing it. As Teoh said, think of it as a
hook into Typeinfo, allowing the programmer to alter it at compile
time.

I don't care about Aspect-Oriented programming, or anything like that,
I just want to be able write:

@note(GET,POST)
auto myClassFunction(arg1, arg2, arg3) { ... }

without having to use templates that break inheritance, or doing
checks in the function for the request type, that could be handled in
a library. There's already a mechanism for seeing what attributes that
function has, so why can't I have some code that does this:

template hasAnnotation(alias data, string an) {
    enum hasAnnotation = __traits(hasAnnotation, data, an);
}

(Or something, my template-fu leave something to be desired, not the
point though). It already looks like idiomatic D code.

Its not some big change that massively overhauls the way code is
written, the same way annotations in Java haven't meant that people
suddenly write Java completely differently. They do what they look
like they do, they add some extra information to the "thing" in
question that allow for some more advanced decision making.

Going back to the Web-based example, if I use an opDispatch system to
forward requests to the appropriate controller, I can use compile-time
reflection to generate checking code for the handlers, based , this
means that a simple annotation makes reading the function code much
simpler, since boiler-plate checking code has been removed, I can
implement a white-list based policy for request-type access, rather
than a blacklist that using isPost or isGet methods to check
in-handler. This is more secure, since if I forget to add /any/
annotations, then it wont receive /any/ requests. Lo and behold, I can
now have secure inter-controller communication without needing 1. a
naming convention, 2. an access control list or 3. boilerplate code.

I could go on a similar rant about serialization, but I think my point is made.

deadalnix is talking about being able to re-write language features in
terms of this system, but that's taking it too far, like a lot of
people, he wants D to be all thing to all people. The original idea
was to just to be able to add simple attributes to functions. Other
people sought to extend this unnecessarily, but everything else is
just templates, mixins and CTFE, nothing else.

The real discussion that need to be going on is: How far do notes
extend? (can you have arbitrary expressions annotated?) What data can
be packed into annotations? (Can i put any data into annotations, or
only internal types?) Syntax details, obviously using the @-syntax,
but specific naming, so @note, or @annotation? for example.
Scoping/Collision, I don't think this will be an issue, but if two
libraries are looking for the same annotation name, then there could
be some issues.

I think there is merit in having a Java/C# @<myannotation>, but I
don't think it is needed for D, everything that those annotations
cover can be done using CTFE and mixins, with the minor addition
above.

--
James Miller