Am Sun, 19 Jun 2016 20:52:52 +0000 schrieb deadalnix <deadal...@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.