Initialization & destruction

[ntrel]

Hi,
I think initialization is an area where Neat could break away from D. D has no support for non-null references to avoid accidental segfaults. Part of that problem is that D requires every type to have an .init value. This also means any struct destructor has to handle the .init case (even if @disable this(); is used, calling move or destroy will write the init value). It also means the destructor can be called more than once unnecessarily.

Could Neat instead not default initialize but detect when an uninitialized variable is used? cppfront does this. It also moves/destroys a struct on last use in the current scope. So rather than copying a struct passed by value when it's not used after that, it moves and does not call the destructor in the current scope.

[FeepingCreature]

This should already be the case. mut Object obj;is a compiler error; you have to write mut nullable Object obj;, or provide an non-null initializer.

[ntrel]

Good to hear class references are not nullable by default. However other types are default initialized, including pointers and a struct with a constructor:

module ctor;

struct S
{
    int i;
    this(){i = 2;}
}

void f(int i)
{
    import std.stdio;
    auto c = cast(char)(i+'0');
    [c].print;
}

void main()
{
    S s;
    int i;
    int* p;
    s.i.f; // 0
    i.f; // 0
}

I think pointers should not be nullable by default.

Struct default values mean the destructor has to handle the default case even when there's a constructor that sets up some runtime invariant. Declaring a constructor disables creating the struct with S(4) but doesn't disable default construction.

I would also prefer even simple variables were not default initialized, to ensure the programmer gives them an intended value and doesn't accidentally use the default value. cppfront allows a variable declaration without initializer so long as the variable is initialized before actual use.

[ntrel]

By the way, good to see that Neat allows nullary struct constructors :-)

[FeepingCreature]

Pointers are the pariah of the language. They are pretty much in there only for C compatibility. I don't use them at all in my code, and they don't participate in refcounting.

[ntrel]

Just realized I could have used string interpolation instead of f: "$(s.i)".print; - this is nice!

[ntrel]

Here the destructor is called after "end" is printed:

module dtor;

import std.stdio;

struct S
{
    ~this(){print("hi");}
}

void f(S s)
{
    auto c = cast(char)(s.i+'0');
    [c].print;
}

void main()
{
    S s;
    s.f;
    "end".print;
}

Output:

end
hi

I expected the destructor to be also called at the end of f, seeing as s is a value parameter.

I would like the destructor to only be called at the end of f, i.e. implicitly move main.s to f and not call the destructor at the end of main. I think D is planning this, there's a DIP.

[FeepingCreature]

See my comment on the struct constructor bug for why this is nontrivial.

The constructor semantics for function calls are "a little funky". It is vital to understand that copy constructor and destructor calls are inseparable from Neat's reference counting. In short, here the call to s.f"borrows the calling scope's lifetime" - ie. because the parameter is not declared mutable, we don't need to take a separate reference (copy constructor) for the call.

If you write fas void f(mut S s), you will see two destructor calls.

For a lot of examples for how this works, see the Lifetime testcase.

(Note that the refcounting has a lot of bugs! If something looks fishy, err on the side of reporting it.)

[FeepingCreature]

For future reference: this was actually a bug; fixed here.