Robert Fraser wrote: > Hi, hope you're all enjoying the properties debate. > > I've been seeing the "too many keywords" argument a lot lately, and I > think it's definitely a valid argument. "shared" and "body" in > particular are rather annoying keywords since I frequently use them in > code. And if users are deciding not to use D because of the number of > keywords, that's even worse. > > The idea of "kewyord" as a parser construct is antiquated thinking. Look > at C#: "get", "set", "value", "event", "var", etc. are only keywords in > a particular context. C++/CLI takes it a step further (from > http://blogs.msdn.com/hsutter/archive/2003/11/23/53519.aspx ). There are > three new reserved words ("gcnew", "generic", "nullptr") and a few > multi-word keywords ("for each", "enum/interface/ref/value > class/struct") as well as some contextual keywords that can only appear > in certain positions. > > In D, without a significant change to the lexer/parser, any keywords > that cannot appear in the same place as an identifier could be made > legal identifiers easily. Off the top of my head, "in", "out", "body", > "module", "unittest", "import", "throw" and probably a few others could > be freed up. > > With some parser lookahead, you could add modifiers and storage classes > to the list and probably dozens of others. If braces were required in > try/catch statements, "try", "catch", and "finally" could be added. > > Further, this might be pretty easy to implement (i.e. Walter, if you're > interested, I'm willing to make a patch). It's all backwards-compatible > and would even work in D1. > > Thoughts?
This makes things more difficult for syntax highlighters. A number of them will just not work correctly because they don't actually parse the code. That's all I've got.