Contextualizing keywords

[Oliver Hoog]

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.