Fix Issue 15604 - std.array.array of structs with template opAssign and default initialised 'new'ed class member

[John-Colvin]

15604 is indicative of a larger problem, but this works around the issue here.

[dlang-bot]

Thanks for your pull request, @John-Colvin! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.

Some tips to help speed things up:

• smaller, focused PRs are easier to review than big ones

• try not to mix up refactoring or style changes with bug fixes or feature enhancements

• provide helpful commit messages explaining the rationale behind each change

Bear in mind that large or tricky changes may require multiple rounds of review and revision.

Please see CONTRIBUTING.md for more information.

Bugzilla references

Fix	Bugzilla	Description
✓	15604	[REG2.070] std.array.array of structs with template opAssign and default initialised 'new'ed class member

[JakobOvrum]

This fails for types T with @disable this();, which seems to be the cause of the auto-tester failure

[JakobOvrum]

Maybe use TypeInfo.init

[PetarKirov]

• TypeInfo.init is deprecated and should be replaced by TypeInfo.initializer in all code that try to use it.
• TypeInfo.... is not a good idea for such a core functuonality such as emplace, because it is not usable from version (FreeStanding) code.
• T init = T.init is better than static immutable, because:
  • static immutable keeps objects alive for ever.
  • stack allocated data is more cache friendly

[PetarKirov]

On the other hand, stack allocated structs are not allowed if they have @disable ~this();, so maybe we need to use static immutable at least for such types, probably under static if...

[dnadlinger]

Why would this even be supposed to work in the first place? Isn't it clearly an accepts-invalid compiler issue that you can have a mutable member initialized to point to a class instance? Each struct instance would need to be initialized to point to a different object! If it were a static member, we could discuss whether it would make sense to put the class instance into TLS to support that use case, but not for per-object data.

Am I missing something here? What does the original use case look like?

[JakobOvrum]

@klickverbot, member fields have compile-time initializers, and where but global/TLS would such data go? Putting them in global memory and TLS is consistent with every other compile-time initialized variable. When the programmer wants runtime initialization of fields, they can use a constructor.

When support for class types was initially added to compile-time initialized variables, it allowed all class types regardless of type qualifiers despite always allocating them in global memory. Since then, it has been made a compilation error to use compile-time initializers for mutable and unshared variables of class type at module-level and function scope. I assume the patch missed member fields.

[John-Colvin]

I'd be happy to see this fixed at a language level, preferably in some way that disallows the madness of the test-case I'm using in this pull request.

[CyberShadow]

Why would this even be supposed to work in the first place? Isn't it clearly an accepts-invalid compiler issue that you can have a mutable member initialized to point to a class instance?

Shall we close this and issue 15604 as invalid, then?

[John-Colvin]

happy to close this, but I think 15604 should stay open, some sort of fix is necessary, whether it's documentation or better error messages or something more fundamental.

[CyberShadow]

What do you think of refiling it as accepts-invalid (for mutable references to the data section it generates)?