On 2/28/26 6:54 PM, Nathaniel Shead wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, OK for trunk?

I'm slightly concerned about ordering based on DECL_UID for imported
namespace-scope names as that will depend on when lazy loading occurs
for the entity in question, which will not generally be predictable at
all.  Maybe we should check for DECL_MODULE_ENTITY_P, and always order
them at the end based on their index in entity_ary or something?  Not
sure if that is actually much better though.

But it should still be at least deterministic as far as I'm aware, so I
think this could be improved upon incrementally.

One question I had is how we should determine the visibility of names
for members_of; does this get affected by instantiation context, e.g.
for
export module M;
   import std;
   constexpr auto ctx = std::meta::access_context::unchecked();

   export template <std::meta::info scope>
   consteval std::size_t num_members() {
     constexpr auto result = num_members(scope, ctx).size(); // #1
     return result;
   }

   namespace ns {
     void foo() {}
     export void bar() {}
   }

does doing 'num_members<^^ns>()' from an unrelated importing module
return '1' or '2' (that is, does it include 'foo')?  This patch
implements so that it always returns 1, evaluation is done from the
lookup context of the current module, but I wonder if evaluation here
should be done from the context of the constant expression at #1.

https://eel.is/c++draft/meta#reflection.member.queries-4.1 says we want to include things that 'precede' the evaluation context, which I initially assumed was something accumulative like instantiation context.

But since https://github.com/cplusplus/CWG/issues/848 the evaluation context is limited to specifically where the core constant expression appears.

I think this must assume that "core constant expression" refers to the outermost evaluation, and not an sub-evaluation. But even then the outermost evaluation here is the full initializer of 'result', suggesting that the evaluation context is #1.

But surely this needs to take the instantiation context into account, or templates like this would become useless since they couldn't reflect on user code defined later.

Marek, has this been discussed at all?

Jason

Reply via email to