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