Era:
broken_b.foo(); //i_a is accessible invisibly because
overridden or transformed assuming it would be converted or
copied/moved as appropriate.
return b; //if a is a local variable then b becomes invalid
even though it's a struct.
return i_b; //same as return b
return broken_b; //same as above two cases.
I see. I didn't know one could create an A.B 'outside'. I saw
inner types as Voldemort types, but that is true only for inner
structs in functions.
Now a current way to make it safe while still leaving it
structs could be passing a reference to either the outer struct
or the variable in question. For simplicity it would probably
be the struct.
(...)
Or less safe is to use a pointer and assign it when b
instantiates to point back to A.. But if you pass B around
without A and A goes out of scope... same problem...
Maybe i'm over-thinking it.
I already tried to propagate a ref through A's methods, but that
made a mess: I have lots of methods, which have all to transmit
this ref, only for *one* of them being able to update it.
Thanks for you explanations :)
I'm now using classes and inner classes. I'm not fond of classes,
but that's working correctly.
