DMD can implicitly convert class pointer to the bool. Is it bug or terrible feature?
bearophile
bearophileHUGS at lycos.com
Tue Nov 26 01:22:21 PST 2013
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
More information about the Digitalmars-d
mailing list