Oliver Hoog schrieb:
Robert Fraser schrieb:
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?
Of the keywords mentioned, I only needed "body" in the past. And (maybe
except for "in" and "out") I don't think I would ever need the others.
Freeing them is generally good though. But if it slows down compilation
time, I would rather have it as it is. And requiring try/catch to have
braces introduces inconsistency.
Besides, I find it easier to read source code when keywords are only
used as keywords. Not only because of possible syntax-highlighting errors.
