> In my particular case I need RAII initializing a C library object. Some of the C constructor functions don't have arguments. So the only way to do it is my silly hack with Dummy object. I would probably vote for a change in D spec.

I see. Yeah, I remember I encountered with the need to have a default struct constructor myself earlier, but I couldn't remember the reason. Some of the current D "features" are very inconvenient. Especially the inability to pass an rvalue by a const reference and the forbidden default constructors for structs.

On Friday, 8 February 2019 at 19:24:00 UTC, Victor Porton wrote:
> On Friday, 8 February 2019 at 19:20:59 UTC, psycha0s wrote:
>> What kind of problems a default struct constructor could solve? If you want to use RAII, you need to pass the resource as an argument. If you want to set some initial state, you can do it by assigning values to the struct members directly.
>
> In my particular case I need RAII initializing a C library object. Some of the C constructor functions don't have arguments. So the only way to do it is my silly hack with Dummy object. I would probably vote for a change in D spec.

You might like this article https://w0rp.com/blog/post/an-raii-constructor-by-another-name-is-just-as-sweet/

On Friday, 8 February 2019 at 08:25:18 UTC, Jonathan M Davis wrote:
> It's true that there are use cases where the lack of a default constructor for structs is annoying, but in general, all you have to do is use a factory method instead and then make sure that the type still works if its init value is used (e.g. make sure that the destructor is aware that the factory method can be bypassed). And if you absolutely must have default construction, you can always use a class instead.
>
> - Jonathan M Davis

Just found if you need a type that can be parameterized by an alias to a function that accesses some local frame data, and you want the factory to be static on the type, you can't do it.

Seems like a bug maybe? as I'm not sure what the difference is between the static construct function below or a global one that is parameterized on "alias fun" ?

struct S(alias fun) {
    static auto construct() {
        auto a = S!fun();
        return a;
    }
    void call() { fun(); }
}

void main() {
    int count;
    auto s = S!(() => count++).construct;
}

onlineapp.d(5): Error: cannot access frame pointer of onlineapp.main.S!(delegate () => count++).S

On 08.02.19 20:53, psycha0s wrote:
> Some of the current D "features" are very inconvenient.
> [...] inability to pass an rvalue by a const reference

Missing by-reference passing of rvalues is a nuisance, but it has nothing to do with const.

On Friday, 8 February 2019 at 19:24:00 UTC, Victor Porton wrote:
> On Friday, 8 February 2019 at 19:20:59 UTC, psycha0s wrote:
>> What kind of problems a default struct constructor could solve? If you want to use RAII, you need to pass the resource as an argument. If you want to set some initial state, you can do it by assigning values to the struct members directly.
>
> In my particular case I need RAII initializing a C library object. Some of the C constructor functions don't have arguments. So the only way to do it is my silly hack with Dummy object. I would probably vote for a change in D spec.

I've boiled my requirement down to structs having a "lifetime starting" method of some kind. I don't mind if T.init is blitted over my object before it's called, as long as I can initialize any struct fields that couldn't be initialized inline due to their value not being CTFE'able.

I suppose that for this to be worth doing though, it would need to work extern(D) as well. So creating the object in D would blit T.init to the struct first, while creating the same object in C would not. So I'm wondering if this difference would be a deal breaker (I don't believe it should be), or if what I'm suggesting creates other technical problems (I can't think of any).

> pass an rvalue by a const reference and the forbidden default constructors for structs.

Yes please

On Friday, 8 February 2019 at 19:53:16 UTC, psycha0s wrote:
>> In my particular case I need RAII initializing a C library object. Some of the C constructor functions don't have arguments. So the only way to do it is my silly hack with Dummy object. I would probably vote for a change in D spec.
>
> I see. Yeah, I remember I encountered with the need to have a default struct constructor myself earlier, but I couldn't remember the reason. Some of the current D "features" are very inconvenient. Especially the inability to pass an rvalue by a const reference and the forbidden default constructors for structs.

I'd also like to see the possibility for overriding the default struct constructor.
I wouldn't say it's absolutely necessary in my case, as I _could_ use a class instead, however I believe a struct is more proper in my scenario.

On 1/27/21 7:00 AM, Paul wrote:

> I'd also like to see the possibility for overriding the default struct
> constructor.

I don't have that feeling anymore. :)

> I wouldn't say it's absolutely necessary in my case

Same here: Everytime I thought I needed a struct destructor I solved in one way or another and never thought about it anymore.

> I _could_ use a class instead

Classes are so costly though: At least 2 pointers added; 16 bytes on a 64 bit system. And class variables are references. I would use something like the following and be very happy with it:

struct S {
  int i;

  static S opCall() {
    S s;

    import std.random : uniform;
    s.i = uniform(1, 42);

    return s;
  }

  static S defaulted() {
    return S();
  }
}

void main() {
  auto a = S();
  assert(a.i != 0);

  auto b = S.defaulted;
  assert(b.i != 0);
}

Although, I've heard static opCall may have its own set of problems, which I haven't encountered yet; other than making the mistake of writing 'auto s = S();' as its first line, which causes a segmentation fault due to infinite recursion. ;)

> however I believe a struct is more proper in my scenario.

structs boulder! :)

Ali

On Wednesday, 27 January 2021 at 18:00:02 UTC, Ali Çehreli wrote:
>
> struct S {
>   int i;
>
>   static S opCall() {
>     S s;
>
>     import std.random : uniform;
>     s.i = uniform(1, 42);
>
>     return s;
>   }
>
>   static S defaulted() {
>     return S();
>   }
> }

Does this mean opCall takes priority over default constructors (or struct literals, I have no clue what the difference is, semanthically or implementation wise), whilst it does not when arguments are included?
(As https://dlang.org/spec/operatoroverloading.html states selfdefined constructors take priority)

Thanks for the suggestion by the way, it seems Jonathan M Davis although I hadn't noticed. This seems like a simple solution

By the way, doesnt this mean a this(){} syntax could be implemented by treating it as syntactic sugar for opCall? I noticed C++ also has non-argument struct constructors, so its a bit curious to me.

On 1/27/21 2:05 PM, Paul wrote:

> Does this mean opCall takes priority over default constructors (or
> struct literals

Assuming static opCall is defined, there are two syntaxes:

S a;        // Equals S.init; no constuctor run
S b = S();  // static opCall; no constuctor run

foo(S());     // static opCall
foo(S.init);  // S.init

> I have no clue what the difference is, semanthically or
> implementation wise), whilst it does not when arguments are included?

I don't know; let's try. :)

import std.stdio;

struct S {
  this(int) {
    writeln("ctor");
  }

  static opCall(int) {
    writeln("opCall");
    S s;
    return s;
  }
}

void foo(S) {
}

void main() {
  auto a = S(1);
  foo(S(2));
}

Both of the calls in main go to this(int); opCall is ignored.

> By the way, doesnt this mean a this(){} syntax could be implemented by
> treating it as syntactic sugar for opCall?

Being able to define a default constructor and then saying we don't have default constructors would be confusing I think.

> I noticed C++ also has
> non-argument struct constructors, so its a bit curious to me.

Those are called default constructors. D thinks it differently: there are no default constructors for strtucts. opCall is a strange thing where the name of the type is callable and it looks like a default constructor in usage.

Ali