It makes no sense otherwise. This logically implies that manual memory management is required, yet there is a possibility that the parent of the class may use the garbage collection. Which in this case, it begs the question on why the GC is forbid in the first place.

Does anyone dispute this?

On Saturday, 17 March 2018 at 13:30:25 UTC, 12345swordy wrote:
> Does anyone dispute this?

I don't really see how this would help anything.

On Saturday, 17 March 2018 at 13:30:25 UTC, 12345swordy wrote:
> It makes no sense otherwise. This logically implies that manual memory management is required, yet there is a possibility that the parent of the class may use the garbage collection. Which in this case, it begs the question on why the GC is forbid in the first place.
>
> Does anyone dispute this?

No, it's even required. Mixing GC and non-GC is a known source of memory errors, but rather in the opposite way that the one you describe. Errors happen when non-GC instances has GC-managed members.

To be consistent on this point there are templates like in the Containers library (ShouldAddGcRange) or like in IZ (MustAddGcRange). The latter is inspired by the first and is enhanced with a system of UDA (@NoGc). Also compilation can be stopped if by error a GC-managed field is found.

After developing this in IZ, many memory problems i had in KHEOPS suddenly disappeared and a kind of animated 2D scene started to run for hours without disappearing elements (previously a GC collection was causing this).

Enriched by this experience i can confirm that there's nothing to dispute at all.
You're 100% correct.