August 29

On Thursday, 29 August 2024 at 13:57:05 UTC, ryuukk_ wrote:

>

Are you seriously telling people to write a library to be able to do what C already provides for decades?

Since when did C99 have struct constructors? You can have a factory function in both languages, and they are the preferred method for ‘default construction’. However, in C you can’t @disable this(), so you have to trust the user to get it right by calling your factory function instead of just creating an uninitialised struct variable.

August 30

On Thursday, 29 August 2024 at 20:29:22 UTC, IchorDev wrote:

>

On Thursday, 29 August 2024 at 13:57:05 UTC, ryuukk_ wrote:

>

Are you seriously telling people to write a library to be able to do what C already provides for decades?

Since when did C99 have struct constructors? You can have a factory function in both languages, and they are the preferred method for ‘default construction’. However, in C you can’t @disable this(), so you have to trust the user to get it right by calling your factory function instead of just creating an uninitialised struct variable.

i didn't say a constructor, this whole thread is the result of D not having the foundation right

Allow this:


my_fun( Data { c: 1 } );

And you don't need all of that extra shit

>

However, in C you can’t @disable this(), so you have to trust the user to get it right by calling your factory function instead of just creating an uninitialised struct variable.

lol, no, reject bloat, and stick to simplicity

September 05

On Tuesday, 27 August 2024 at 08:48:19 UTC, Ogi wrote:

>
struct S {
    this(int x = 0, int y = 0) {
         writeln(i"S($(x), $(y))");
    }
}
auto s1 = S(y: 42); // S(0, 42)
auto s2 = S(); // default initialization

I don’t know if I like it or hate it. In contrast to the other ones, the nullary overload is visually present, whereas here, it’s not. Not being able to use the constructor with one or both arguments explicitly because you just aren’t allowed to define it is annoying, 100%. Working around that is possible, though:

@safe:
import std.stdio;
struct S
{
    private enum Y { _ }
    this(int x, int y = 0) { writeln(i"S($(x), $(y))"); }
    this(Y = Y.init, int y) { this(0, y); }
}

void main()
{
    auto s = [ S(42), S(x: 42), S(y: 42), S(1, 2), S() ];
    // prints: S(42, 0), S(42, 0), S(0, 42), S(1, 2)
    // absent: S(0, 0)
}

The Y = Y.init makes the overload viable only through named arguments, so that S(y: 42) is possible.

I’d be definitely in favor of it if the proposal included defining and defaulting the nullary constructor, which would be required in this case. Something like that:

struct S {
    default this(); // new
    this(int x = 0, int y = 0) {
         writeln(i"S($(x), $(y))");
    }
}

The nullary constructor can be @disabled, so making it also special in it being able to be defaulted doesn’t really make difference.

1 2
Next ›   Last »