On Tuesday, 24 October 2023 at 15:30:33 UTC, Guillaume Piolat wrote:

Nope, default initialization is the best thing that could have been created. After people created typescript because not having types was a mistake, the second think we got was default initialization.

The only problem I ever had with D was float being initialized to nan instead of 0. This has been talked a lot of times now. If you read the post from Sonke, you can see that D is not being how simple it was from before from the addition of lot of keywords: pure, nothrow, @nogc, scope, return. I don't want any more verbosity than that, so all hail default initialization :D

On Tuesday, 24 October 2023 at 15:39:09 UTC, Hipreme wrote:

The nice thing about that clutter is that you can (for now, at least) avoid uglifying your own code with it. I don't use any of them and don't even know what most of them do.

On Tuesday, 24 October 2023 at 15:39:09 UTC, Hipreme wrote:

I don't like using so many attributes either. Fortunately, your code usually works even when you don't use it :)

On Tuesday, 24 October 2023 at 01:35:16 UTC, deadalnix wrote:

The default constructor doesn't always work the way I want. Let's talk some code. Test1 and test2 are ok but the third one is something I came across recently:

void main()
{
    string data;
    assert(data is null);

    /** TEST 1 **/
    struct String
    {
        string data;
    }

    String s;
    assert(s.data is null);

    auto s2 = String();
    assert(s2.data is null);

    /** TEST 2 **/
    struct Ztring
    {
        string data;

        this(string data)
        {
            this.data = data;
        }
    }

    Ztring z;
    assert(z.data is null);

    auto z2 = Ztring("D");
    assert(!(z2.data is null));

    /** TEST 3 **/
    struct Foo
    {
        int[] data;

        this(int[] data)
        {
            this.data = data;
            if(this.data.capacity < 4)
            {
                this.data.length = 20;
            }
        }
    }
    auto l = Foo([1, 2, 3]);
    assert(l.data.capacity > 4);
}

I don't want my code to run with the default feature, but it shouldn't take any constructor parameters either. What I want is to increase the capacity of one of the members at compile time while it is initialized.

SDB@79

On Tuesday, 24 October 2023 at 15:39:09 UTC, Hipreme wrote:

There are really different ideas that are getting conflated because the
implementation of those ideas is so similar. The justification of NaN is that
it makes errors more obvious - because failing to initialize variables is an
error - which has strange implications for people deliberately not initializing
variables in the presence of the feature. In cases other than NaN, the default
value at least results in consistent behavior when not initializing them was a
logical error.

But,

1. people very naturally rely on this behavior, and deliberately not initialize
   variables.
2. default initialization prevents tooling like valgrind or libsanitizer from
   complaining about code relying on uninitialized data. And because of #1, these
   also can't be adapted to D now.

So I think this error-focused idea is a bad one. Of D's hits and misses, it's
really a miss. Maybe that's why Swift and co. are leaving it. Nobody's talked
about about their reasons yet.

Fortunately, apart from NaN, it is functionally identical to a good idea:
zeroing everything and having the zero value be useful and not an error. Zero
Is Initialization (ZII, imitating RAII). The zero list is the empty list and
you can push new values onto it. The zero vector is the empty vector and you
can do likewise. This isn't automatic, of course - it's very easy to write code
that segfaults on zero values. And although Go popularized zero values it's
still an error to work with the zero value of a Go hash table.

So I think this idea also hasn't really arrived yet. It's just a trick that
some people like to do, and there are some languages that sort of do it.

On Tuesday, 24 October 2023 at 20:38:08 UTC, Julian Fondren wrote:

I see I've forgotten how to post here.

Simpler: error-oriented default initialization fails to account for programmer risk homeostasis. People are too aware of it for it to fulfill its function.

But it's also a 'hit' like it's a hit to buy a toy for your cat, take the toy out of the box, and find that the cat ignores the toy and plays with the box.