Am Sat, 28 May 2016 07:08:52 +0000 schrieb Era Scarecrow <rtcv...@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.