Contextualizing keywords

[Chad J]

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.