Marco Leise:

I don't know much about the development process, but as you
said some bugs may be features or vice versa. Sometimes real
bugs are fixed and peoples' code breaks. But keeping the bug
around isn't an option.

Fixing issues like this is right, despite they will cause some breakage in user code.

In DMD 2.063alpha this code gives a warning (http://d.puremagic.com/issues/show_bug.cgi?id=7444 ):

void main() {
    int[10] a;
    a = 1;
}


temp.d(3): Warning: explicit element-wise assignment (a)[] = 1 is better than a = 1


My suggestion for D users is to update their DMD compiler often, to avoid cumulating many breakages at the same time, that is quite bad. It's better to fix one thing at a time.

All bug fixes are potential code breakages, but not all breakages have the same magnitude an importance. My suggestion for D developers is to focus their efforts first on the D/DMD changes that will cause most breaking because the more time passes, the more D2 code is around, and the more breakage will happen.

This also means implementing things like in/scope sooner than later, that probably are sometimes used wrongly, and that will cause some breakage once implemented. Another similar case is "final switch" on ints that is currently broken (http://d.puremagic.com/issues/show_bug.cgi?id=5713) and likely misused in some D program. So once it's fixed it will break some user code.


Time ago I have suggested to statically disallow code like this (starting first with a deprecation, a warning, and then an error), that currently compiles without errors or warnings:


string[4] colors = ["red",
                    "blue"
                    "green",
                    "yellow"];
void main() {}


If similar code will be statically disallowed, it will break some user code (Walter agreed to forbid half of that combo-pitfall).


I have a bit of statistical proof that code like this is a common source of bugs, and I'd like this to be statically disallowed (http://d.puremagic.com/issues/show_bug.cgi?id=5409 ):

(!x & y)

But disallowing this will break some user code (not much, because it's likely a bug in the first place).

Bye,
bearophile

Reply via email to