Performance issue in struct initialization

[Johannes Pfau via Digitalmars-d]

Am Sun, 19 Jun 2016 20:52:52 +0000
schrieb deadalnix <deadalnix at gmail.com>:

> 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.

Can somebody explain how exactly are constructors related to the
problem?

If I've got this:
struct Foo
{
    int a = 42;
    int b = void;

    @disable this();
    this(int b)
    {this.b = b;}
}
auto foo = Foo(41);

I'd still expect a to be initialized to 42. Note that this does _not_
require a initializer symbol or memcpy. I'll post a more detailed follow
up post to issue 15951.