Bug 6186 – Struct destructor is not called on out parameter

An object typed T through out parameter is initialized by T.init (like memcpy), but its destructor is not called before initializing. ---- int dtor_cnt; struct S { int n; ~this(){ dtor_cnt++; } } void test1() { void f1(out S s){} S s = S(1); dtor_cnt = 0; f1(s); assert(dtor_cnt == 1); // NG } void test2() { void f2(out S[2] sa){} S[2] sa = [S(1), S(2)]; dtor_cnt = 0; f2(sa); assert(dtor_cnt == 2); // NG } void main() { test1(); test2(); } ----

I'm unsure what the right fix is for this. Out variables are supposed to be initialized by the function, not assigned. Hence, I think uninitialized variables should be passed to them, and it should be an error to pass a non-default-initialized variable.

See also: https://github.com/D-Programming-Language/dmd/pull/155

Why is the github merge request closed? This issue is not fixed yet and the current behaviour leads to really strange bugs...

I just hit this. This is my use case, and it's causing a leak: //---- struct S { this(int) {writeln("constructor");} ~this() {writeln("destructor");} } alias RefCounted!S RCS; void foo(out RCS){} void main() { auto rcs = RCS(5); //Use my variable. foo(rcs); //Re-use my variable } //---- Output: constructor EG: It leaked. Walter says: > Out variables are supposed to be initialized by the function, not assigned. > Hence, I think uninitialized variables should be passed to them, and it should be an error to pass a non-default-initialized variable. It was my understanding that the entire *point* of "out" was that the *language* initialized the parameter, both for the function (no need to test the variable is in an initial state), and the caller (no need to (re)-set to initial state). Overwriting a variable without first destroying it is always wrong behavior, and unsafe. It should not be out's default behavior. If you insist that the correct behavior is that an out parameter must not be initialized beofre use, then "out"'s correct behavior should instead be to verify the passed argument already has the T.init value, and assert otherwise. In his pull: https://github.com/D-Programming-Language/dmd/pull/155 Kenji says: > Sure. It was out of consideration about void-initialized variable. > But, calling dtor before passing to out parameter is still 'right semantic' for initialized variable. To separate cases, we should detect statically that the variable is initialized or not. D specs says that "uninitialized" has the value of T.init, and T.init must *always* be destroyable, so that is not an issue, IMO. void-initialization is a user-explicit unsafe state we should not have to bother supporting. Also, how hard is it to detect the two scenarios? //---- void foo(out T); void main() { T t; foo(t); //t was *just* decalred, No need to re-initialize } //---- Or //---- void bar(out T t) { foo(t); //t is already out, so no need to re-initialize } //---- IMO, the first case represents the majority of "out" usage, and the second an interesting optimization. In every other case, we can re-initialize.

Wow. This is a nasty one. I agree that out parameters should be destructed if they're already initialized. Isn't it good enough for the compiler to just issue the equivalent of `x = typeof(x).init` at the beginning of the function when x is an out parameter? AFAIK, if you were to actually write this out in code it'd call the dtor before making the assignment (right?). At least, that's what I *thought* the compiler did based on what TDPL describes.

NG thread: http://forum.dlang.org/thread/[email protected] As Kenji wrote in the thread: > If an out parameter typed T exists, and > 1. T has elaborate destructor > 2. T.init represents logically invalid object (T is nested struct, and/or > T has @disable this();) > Automatic blit initializing for the out parameter would be unsafe. > So semantic analysis would reject such a out parameter declaration. Also `out` parameters recently become rejected for `@disable this()` structs.

I'm beginning to think that there's no good way to make this work. In essence, make it an error to use 'out' for objects with a destructor. Use 'ref' for such objects, which has well-defined semantics.

What are the scenarios that would make this hard to fix according to the original proposal?

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18348 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB