#dbugfix 17592

[Adam D. Ruppe]

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.