Instantiation of nested structs should be allowed outside their parent scope

[Stanislav Blinov]

On Tuesday, 9 November 2021 at 22:22:20 UTC, Alexandru Ermicioi 
wrote:

> if it), the .init of a nested struct should have the context 
> pointer of the method it is called in setup.

No. .init of a nested struct just contains a null pointer in the 
.tupleof[$-1]. Context does not exist until you instantiate a 
nested struct within the parent scope. That's when an actual 
stack frame gets allocated. Consequently, doing things like T a = 
T.init; when T is a nested struct is exactly the kind of "bug" 
you're referring to. And the compiler is perfectly happy with 
that. Because, actually, that is not a bug at all. Just like 
leaving raw pointers null-initialized.

> The only current solution I'd see to avoid this issue, would be 
> to first static check if the type is nested type, and just use 
> hasMember trait to check that a `__ctor` with one argument of 
> same type as the structure itself is present.

There is a dedicated trait that shows presence of copy 
constructor. BTW, hasMember is the WORST method of checking for 
functions. Because of overloads, and because of templates. IMHO, 
it's only good for checking for the presence of a destructor, and 
that's about it.

Please understand, I am not asking "how to work around this" 
here. I know how, I've already shown how. That is not what I want 
to be doing. I want the opposite - to not have to be doing that.

> If so, most probably it is a copy constructor, and hence you 
> can return true.

No, you can't. The ctor might be templated, so won't even exist 
unless you try to instantiate it. Or there might not be any copy 
constructor at all. Nor postblit. But the thing may simply not be 
copyable (i.e. const pointer into a pointer), hence the trait 
must return false.