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