Functions with out parameters simply initialize the parameter with .init, instead of properly destroying it.

import std.stdio;

int count;

struct S {
    bool initialized;
    this(int) {
        writeln("S()");
        initialized = true;
        count++;
    }
    ~this() {
        if (initialized) {
            writeln("~S()");
            count--;
        }
    }
}

void foo(out S s) {
    s = S(42);
}

void bar() {
    S s;
    foo(s);
    foo(s);
}

void main() {
    bar();
    writeln(count);
}

Output:

S()
S()
~S()
1

Looks like a serious oversight.

On Friday, 14 March 2025 at 16:54:10 UTC, Ali Çehreli wrote:

I want to clarify if this is intentional or not, and what is the intention if it is. Currently, it turns out that the variable has to be destroyed before passing it as an “out” argument. It’s counter-intuitive, and it defeats the purpose of “out” parameters.

In this aspect, current implementation differs from spec, so it handles constructed objects correctly. The “out” parameter is not initialized with .init, it’s default-initialized:

void main() {
    import std.stdio;
    int x;
    struct S {
        void bumpX() { x++; }
    }
    void foo(out S s) {}
    S s = S.init;
    foo(s);
    s.bumpX();
    writeln(x);
}

If S would be initialized with .init, the hidden context pointer in the nested struct would be null, and calling to bumpX() would crash the program. But it doesn’t crash and prints: 1.

On Friday, 14 March 2025 at 07:30:14 UTC, Ogion wrote:
[...]

~this() {
    if (initialized) {
        writeln("~S()");

If one moves the line containing 'writeln´ one line up before the 'if´-condition, then one might be notified of all calls---and one might be able to recognize more than one call of the destructor.

[...]

s = S(42);

The docs at 15.20.2 look very similar to:

If there is no 'opAssign´ in 'S´ the compiler might insert a default. If a default is inserted, does it suffice?

On Saturday, 15 March 2025 at 20:21:41 UTC, Manfred Nowak wrote:

One who has eyes, let one see:

import std.stdio;
struct S {
    int x;
    this(int x) {
        this.x = x;
        writeln("S(", x, ")");
    }
    ~this() {
        writeln("~S(", x, ")");
    }
}

void foo(out S s) {}

void main() {
    S s = S(42);
    foo(s);
}

Output:

S(42)
~S(0)

Alas, the object instantiated with S(42) was not given the proper burial. The treacherous function replaced its body with an empty shell. Its restless spirit will wander the earth for all eternity.

On Saturday, 15 March 2025 at 23:39:36 UTC, Ogion wrote:
[...]

Clear proof that the 'opAsssign´, specified in the docs at 15.20, was not called---or the call of the '__dtor´ within that 'opAssign´ does not give any due respect to the specified '~this´.

-manfred

On Saturday, 15 March 2025 at 11:44:14 UTC, Ogi wrote:

Thanks, PR:
https://github.com/dlang/dlang.org/pull/4190

On Friday, 14 March 2025 at 07:30:14 UTC, Ogion wrote:

See https://github.com/dlang/dmd/issues/18348.

I think the solution is to always call the destructor before calling the function. However that was not implemented because it would break code that uses S s = void;, as s might not be a destructible value. The = void case could perhaps be supported if the compiler was smart enough to detect simple cases where s wasn't constructed. In those cases calling the destructor could be omitted (the spec might need updating to allow that). Given that all this could still break existing code with non-simple control flow, it would probably need to be done in the next edition rather than current edition of the language.

On Monday, 17 March 2025 at 11:40:59 UTC, Nick Treleaven wrote:

Understandable.

I should note that spec never said that the parameter is expected to be uninitialized. However, the fact that some some code relies on this behavior can’t be ignored.

I don’t think that “out” parameters worth fixing though. They only exist because we don’t have first-class tuples. Once we sort this out, we’ll just deprecate the “out” parameters with all their warts.