Instantiation of nested structs should be allowed outside their parent scope

Alexandru Ermicioi alexandru.ermicioi at gmail.com
Tue Nov 9 22:22:20 UTC 2021


On Tuesday, 9 November 2021 at 19:00:38 UTC, Stanislav Blinov 
wrote:
> On Tuesday, 9 November 2021 at 18:35:44 UTC, Alexandru Ermicioi 
> wrote:
>
>> If compiler can help in preventing potential bugs...
>
> That's just the thing. That error message is, plain and simple, 
> handwaving. Unless, like I said already, I'm missing something. 
> The compiler is perfectly happy with me initializing a nested 
> struct to its .init value. But instantiating it elsewhere - 
> nuuuh, that's not allowed!

.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.

> Please, this is not helpful. There are already reports on this, 
> including ones filed by myself. Why do you think I created this 
> topic?

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

> That is not "inner" struct. That is nested struct. And the 
> whole point of this topic *is* nested structs. I don't need to 
> eliminate context pointer. I need generic code to work with 
> nested structs. Including the copy tests being discussed here. 
> Including, for gods sake, Phobos ranges.

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.




More information about the Digitalmars-d mailing list