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.

One , if not the one I like the best:

https://www.youtube.com/watch?v=xNRBajLM8_4