Vision for the D language - stabilizing complexity?

[Andrew Godfrey via Digitalmars-d]

> Generally it's not a feasible strategy to assign (or assume as 
> reader) a single context-independent meaning to a keyword.


That may be overstating it, yes. But I am looking here for a 
positive statement about what kind of addition is "beyond the 
pale". For example, in C++, "enum class" uses two existing 
keywords in a new way, but it is acceptable (although ugly as 
heck), because the resulting thing is 'like' an enum. OTOH, C++'s 
use of "static" is unacceptable, because it mixes very distinct 
ideas (file scope, linkage, and instancing in a class) and the 
context you have to look at to distinguish them is sometimes far 
away from the line you are looking at. I haven't really noticed 
this problem much with D, but I worry about the future, because I 
see a refusal to introduce new keywords, combined with an 
eagerness to introduce new language concepts. Surely a compelling 
enough new language concept, would justify needing to provide a 
migration tool to help codebases migrate to the new compiler?


Another example is "return" used for monads in eg Haskell - even 
if it only has one meaning in Haskell, it is too mixed up with a 
different meaning in other common languages. D's "static if" - 
which is a killer feature if I ignore the keyword - gives me a 
similar feeling (though it's much less egregious than "return" in 
monads). "static" is a terribly non-descriptive name because 
there are so many senses in which a thing could be "dynamic". 
What we mean in this case is "compile-time". I think!