On Sunday 26 September 2010 12:34:43 lurker wrote: > I can't even possibly imagine > why would anyone (except you) want to use their own keywords. It sounds > like a new treacherous way to invite dangerous macros to the language. The > reservation of the word macro without giving an implementation is a > conscious decision to disable all kinds of over-expressive macros in > forthcoming versions of the language. Providing customized @! keywords for > 3rd party tools seems like mocking the damn good state of the art > meta-programming system D has. If I could design D, I'd use @ in front of > every keyword to avoid namespace collisions with user symbols.
Other languages - like Java - allow user-defined attributes. Certainly in Java, @ is not at all intended to be a space for creating new keywords. It's intended to be a space for putting attributes of functions and classes and the like. Those attributes are sometimes defined by the compiler (@override for instance) and sometimes created by 3rd party library or you on your own project. For instance, there's a 3rd party library (I forget what it is at the moment - it's been a while since I used it) which allows you to serialize your classes to and from xml using reflection. For that to work correctly, you need to use markup on your classes. So, they have attributes along the lines of @xml and @xml_transient to indicate things which should or shouldn't be put into xml or how it should be translated into xml. It's _extremely_ useful. A number of libraries in Java use that sort of thing. There are those among us who'd love to have that sort of thing in D. At present, D's attributes are all fixed, and the choice of what is an attribute and what is a keyword is pretty arbitrary such that @ does come across as another namespace for keywords, but it doesn't have to be that way. Assuming that the grammar is such that @ indicates that the identifier that follows is an attribute (as opposed to the whole @identifier being a keyword), then making it parse 3rd party attributes would be easy. They wouldn't do anything, but they'd be available through reflection (which at the moment, would only be compile-time reflection, but perhaps someday we'll get runtime reflection too), and so you could use __traits and traits to get at them and your libraries could then generate code based on them. It really isn't crazy to want user-defined attributes, and it's not necessarily hard (though if you want user-defined attributes as good as Java's, you'll need more since they allow attributes with parametrs and the like). At some point, Walter may add such a feature. It's obviously not high on his priority list right now (which is fine with me), but it _is_ a feature which many of us think should be in the language. - Jonathan M Davis