Chris Cain:
Sure. It'd have been nice if the language was designed to avoid
these types of problems from the beginning (though a language
feature/syntax rules to learn dedicated to a problem that is
easily solved with a naming convention would be debatable). But
it wasn't and it'd break too much code for a minuscule gain and
there exists a reasonable workaround (that also is commonly
used everywhere else for this same problem in most other
languages). Changing this now would be horrifically bad and the
benefit of such a change is effectively nothing.
This discussion is becoming more interesting, thank you :-)
If it's a convention "commonly used everywhere" then it sounds
like something important.
And replacing name conventions with compiler-enforced features is
one of the main purposes of any type system. Because it makes the
convention safer and tidier.
Regarding the code breaking, probably there are acceptable
deprecation paths, that make the such change gradual enough.
regarding the gain being minuscule, experiments should be used to
verify this.
Andrei has written elsewhere in this thread:
As I wrote in TDPL, it's a bad idea to add a global somewhere
and break a bunch of code that has nothing to do with it.<
Global (or module-level in D, often thread-local) variables are
sometimes useful, but a D programmer should minimize their
number. If you add a global variable, and the compiler gives you
several name shadowing errors elsewhere, you choose a different
name for the global variable, you don't break the code. If you
add a local variable that shadows a global variable and you
receive a shadowing error, you choose a different name for the
local variable. This avoid using the "g_" prefix.
Bye,
bearophile
