D has plenty of semantic annotations, but sometimes they are not handled in a strict enough way, so their usefulness (in catching bugs) is reduced.

Microsoft catches plenty of troubles statically with SAL2:
http://msdn.microsoft.com/en-us/library/hh916382.aspx

In this program D gives an error:


class Foo {
    immutable int[] x;
    this() {}
}
void main() {}


test.d(3,5): Error: constructor test.Foo.this missing initializer for immutable field x


D could give a similar error here, an out argument that is not assigned inside the function "foo":

void foo(out int x) {}
void main() {}


A possible error message:

test.d(1,21): Error: uninitialised out argument of 'test3.foo' function


This analysis is basic, so this code does not raise that error, despite arr[1] is not initialized:

void foo(out int[2] arr) {
    arr[0] = 1;
}


Another case where the compiler will not give that 'uninitialised out argument' error, despite arr is not always initialized:

void foo(in bool b, out int[2] arr) {
    if (b)
        arr = [1, 2];
}


When and if D language and compiler adds some form of flow analysis, the analysis for out could become more strict, and refuse the precedent two examples.

This is a breaking change, so if you want you can reach this error with a warning-deprecation-error trajectory.

I think that most D code with functions with out arguments that are not initialized inside the function are already buggy so I think this code will not introduce lot of breakage in existing D code.

Bye,
bearophile

Reply via email to