On Thursday, 22 March 2018 at 02:16:56 UTC, SimonN wrote:
Does the compiler infer nogc-ness of `emplace` at instantiation?
Yes, it does with all templates, actually. Since their nogcness (and other attributes like nothrow, pure, etc) frequently depend on what arguments they are passed, the compiler will infer it at instantiation.
Putting the explicit attribute on a template forces it to be such - then it will reject non-matching arguments (e.g. @nogc emplace would be a compile error if passed a gc constructor, regardless of if it is used in a gc or nogc context. without the explicit attribute, the compiler infers it and thus only throws the error if used in an actual nogc context).
My first hunch was that B's yes-gc-destructor should be illegal when A's descructor is `@nogc`, but it can be legal because destructors in a hierarchy are chained, not overridden. Seems like there is no way to ensure at child-class-compile-time that all child classes of A must be designed `@nogc`.
Right. That's the key problem to @nogc destroy and why we can't fix it in the library - it would require a language chance to force subclass dtors to have the same attribute set as the base class, as if they were overridden virtual inherited members.
