Re: Performance issue in struct initialization

[Basile B. via Digitalmars-d]

On Sunday, 19 June 2016 at 20:52:52 UTC, deadalnix wrote:

On Sunday, 19 June 2016 at 11:11:18 UTC, Basile B. wrote:

On Saturday, 23 April 2016 at 13:37:31 UTC, Andrei Alexandrescu wrote:

https://issues.dlang.org/show_bug.cgi?id=15951. I showed a few obvious cases, but finding the best code in general is tricky. Ideas? -- Andrei

A new "@noinit" attribute could solve this issue and other cases where the initializer is a handicap:

The runtime would skip the copy of the initializer when
1- @noinit is an attribute of an aggregate.
2- a ctor that takes at least one parameter is present.

3- the default ctor is disabled (only a condition for the structs or the new free form unions)

// OK
@noinit struct Foo
{
   uint a;
   @disable this();
   this(uint a){}
}

// not accepted because a ctor with parameters misses
@noinit struct Foo
{
   @disable this();
}

// Ok but a warning will be emitted...
@noinit struct Foo
{
   uint a = 1; // ...because this value is ignored
   @disable this();
   this(uint a){}
}

// not accepted because there's a default ctor
@noinit struct Foo
{
   this(){}
}

The rationale is that when there's a constructor that takes parameters it's really suposed to initialize the aggregate. At least that would be the contract, the "postulate', put by the usage of @noinit.

No new attribute please. Just enable the damn thing where there is an argumentless constructor and be done with it.

we need hobo structs...