The Wrong Stuff

[lurker]

retard Wrote:

> Sun, 26 Sep 2010 09:26:28 -0400, Michel Fortin wrote:
> 
> > On 2010-09-26 03:56:32 -0400, Don <nospam at nospam.com> said:
> > 
> >> I was just referring to the "without having to add new keywords" bit.
> >> And a fairly general comment to the whole thread (not just this post).
> >> I meant that __keywords are available, and the argument that @ provides
> >> a namespace for keywords is completely wrong, and utterly dreadful. I'm
> >> a bit disturbed that people are even thinking in that way.
> > 
> > People (including me) are thinking that way because there is no sane
> > semantic definition of what the @ syntax stands for. I'll grant you one
> > thing: @attributes are only used to affect declarations in one way or
> > another, so as long as this stands they're more limited in purpose than
> > keywords in general. But beyond that, what makes @ different from
> > another namespace for keywords?
> > 
> > 
> >> See also the August 28 post by Herb Sutter: http://herbsutter.com/
> >> 
> >> "My biggest (but not only) beef with C++0x [[attributes]] is that the
> >> standard itself was abusing attributes as disguised [[keywords]].
> >> Attributes are acceptable as pure annotations, but they should have no
> >> semantic effect on the program.
> >> [snip]
> >> it’s a clear example of adding language keywords dressed in attributes’
> >> clothing, and not something I want to be responsible for forcing three
> >> million C++ developers to live with until the end of time."
> > 
> > Unfortunately, one attribute with the @ syntax in D -- and I'd say the
> > flagship one as it was the first and most discussed -- is not a pure
> > annotation as it has a noticeable effect on semantics. I'm talking about
> > @property which, if it ever get implemented, changes your function so it
> > simulates a field. In Herb's terms, @property is clearly a keyword in
> > disguise.
> > 
> > And then you realize many keywords fit that same definition of an
> > attribute (deprecated, pure, nothrow...) and you're left with a very
> > fuzzy concept of what the @ syntax is for. We have an important keyword
> > disguised as an @attribute (@property) and attributes disguised as
> > keywords for historical reason (deprecated, pure, nothrow...). Whatever
> > the @ syntax was supposed to stand for, it's pretty messed up right now.
> > 
> > There's also confusion about the term "attribute" itself. Try reading
> > that page and come with a sane definition of what is an attribute in D.
> > <http://digitalmars.com/d/2.0/attribute.html>
> 
> This just makes me wonder, why is it so *** hard to get things right? I 
> remember when D didn't have the @stuff syntax at all. I wished it worked 
> like annotations in Java or in C#. If I made my own 3rd party lint/
> document_generator/unit_test_tool/whatever, and I'd just want a way to 
> decorate some syntax tree nodes. How can it be so hard to do this? Can 
> you use your own @annotations now? Probably not. There's only the 
> @property syntax, nothing else. The __traits keyword was also supposed to 
> change to 'traits' or something a bit more sane. Nothing really happened. 
> Why am I using this language?

There is absolutely no need to use D. In fact some (most?) of us wish that you wouldn't.

This answer isn't for you because you implicitly seem to disagree with everything, but here it goes: Designing new keywords is a complicated task. Walter follows a so called parser oriented thinking - what's easy to implement in the parser (the low hanging fruit), seems to be the best solution. If you need other kind of changes to the language, you need to carefully take into consideration (Herb Sutter like C++ thinking) all kinds of aspects such as legacy concerns (C compatibility), namespace issues (__keywords and @keywords nicely create new namespaces and don't conflict with user symbols like variables). 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.