Performance issue in struct initialization

[Johannes Pfau via Digitalmars-d]

Am Sat, 28 May 2016 07:08:52 +0000
schrieb Era Scarecrow <rtcvb32 at yahoo.com>:

> On Friday, 27 May 2016 at 09:02:17 UTC, Johan Engelen wrote:
> > That language guarantee prevents optimization of the 
> > initialization (in this case, the optimized result would be no 
> > initialization at all). So a breaking language spec change 
> > would be needed. Is this pursued by anyone? Perhaps only relax 
> > the spec when the struct S overrides opEquals ?
> >
> > (Once the optimization is allowed, I think it will be a fun 
> > project for me to implement it in LDC. But please keep the 
> > discussion clean by not discussing how a compiler should make 
> > use of this language change, how to implement it, etc. Thanks!)  
> 
>   If opEquals and opCmp are overridden then I don't see why voids 
> in initialization can't work since how you are comparing it would 
> determine equality and not a bitwise compare...
> 

I don't think this is a good solution. A '=void' field will always
break 'a is b', even with a user defined opEquals. And of course a
custom opEquals could do bit comparisons as well.

I think a better way to frame this for the spec is:

* A struct containing a =void field (directly or nested) cannot be
  compared bitwise. The compiler is allowed to fill the =void parts
  with arbitrary data. a == b will only compile if a user provided
  opEquals is available. a is b will never compile for such structs.