Closed GorNishanov closed 3 years ago
There are comments in <ipr/impl>
that suggest to remove membership()
so I suppose at some point, I realized that it was redundant information as I believe the thinking behind membership()
meaning is that it is morally
return home_region().owner();
which does not even need to be a virtual
function. How often is that information needed?
Any other declaration is just trying to refine the return type based on the specific declaration class node.
Thoughts?
Sounds great!
I think it will even work for current instantiations (in the new and upcoming model where there will be a "micro-region" which will host the current instatiations for Option 2), the owner of that region could point at what is the proper owner of that decl).
This removes the necessity to maintain a redundant field storing information that can be inferred via home_region().owner()
.
Great resolution!
And of course, interestingly, <ipr/interface>
defines some of home_region()
in terms of membership().region()
:-)
Clearly, we are dealing with redundancy
Fantastic! This demonstrates the equivalence :-)
membership() = home_region().owner() home_region() = membership().region()
Most of the declaration has a membership() accessor returning the UDT they are member of. I noticed a comment in impl/ udt::declare_alias
Which made me audit all declarations for the presence of member_of / membership field.
There also three unorthodox declarations that do not have membership, but, since they are special, I am not worried about them much:
Asm
,Base_type
andUsing_declaration
.I cannot find justification for why
Var
andAlias
do not have member_of, whereasTypedecl
has. I am wondering if membership() should be a property of all declarations and could be pulled into interface Decl (common base for all declarations).