Performance issue in struct initialization

[Basile B. via Digitalmars-d]

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.

If RCStrings are always allocated with allocators then we can 
implement this at the library level...otherwise it's a DIP ;)