On Tuesday, 9 November 2021 at 19:00:38 UTC, Stanislav Blinov wrote:

.init field itself has lots of edge cases that are not well thought, and you might just be hitting one of them. Per my understanding (which is not necessarily right, please correct if it), the .init of a nested struct should have the context pointer of the method it is called in setup. I.e. .init for such structs would be possible to use only in the scope of parent,
be it class, or function body.

Wasn't aware that they were there already, hence recommended to be filed.

I was referring to nested structs. Inner or nested structs are the same thing, they are inside or nested into something.

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. If so, most probably it is a copy constructor, and hence you can return true. I.e. check the signature of constructor, instead of actually trying to instantiate the nested struct inside is expression or __traits compiles expression. That should work even with @disabled copy constructors, per my knowledge.

I know, that sometimes D meta-programming is pain in some ... place due to bugs, and not well rounded edge cases, but the solution you proposed to fix that (have context pointer null), is a thing which is not better than the current language spec, in my opinion.

So for now best is to try to convince people working on compiler that the issue is quite serious and needs working on (guess this thread itself), while in meantime, you may try use the solution I've proposed to do the checks.

Best regards,
Alexandru.

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

You may also try iterate over all constructor overloads, and check for function signature with is expression. This should not force the compiler to instantiate the struct (and hence complain for missing context pointer), and achieve what you need in case for copy constructor.

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

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.

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.

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.