Actually, I wrote and presented a reflection proposal once a long time ago,
so I do know how difficult it is to consolidate (and implement) these ideas
and also I do respect and appreciate the evidently competent work on C++
reflection. Also know why "EWG's satisfaction" is a necessary and prudent
counterweight to this process.

The interesting part is that I proposed a lot of things, the core was
really (raw and) different compared to P1240R1, but some main reflection
design points rougfully still stand in this modern proposals ( with a
completely different syntax ) :

Need an operator ( can´t be made only with type traits )
No generation of template instantiations/types ( meta::info in P1240 and
direct reification in my proposal )
Filtered queries ( not need separated functionality to "member fields"
apart from "member functions", plus huge classes / namespaces )
Namespaces reflection
List of const expressions as attributes

So far, we got 3/5, also attributes were re-proposed almost equally by
someone else (maybe 4/5), so I'm happy that even though I couldn´t work
with that and participate in last years 😞, some convergence emerged 😛!

Reflecting namespaces was always a problem, ODR violations ( in reflection
), reopenings, enormous sizes, different inclusion order in different
compilation units,etc. but many can be solved with meta::info and consteval
functions.

Back in the day I thought about a "is_first_redeclaration" predicate, I
don't know if somebody else considered something like this, compilers
probably maintain a pointer to previous declarations in redeclared AST
Nodes, so it is probably cheap acquire this info, and even if you get
out-of-order function declarations in different compilations units you
still can get the same function name and parameter types, even in cases
when parameter names are different;


Although sometimes it seems, I'm not trying to exhaust SG7 patience.....


buuuuuuuttttttt.........

What is written in the proposal p1240r1.pdf
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1240r1.pdf> page
36 puzzled me :

  "Of note here is that we are not proposing a function to retrieve members
of namespaces: Due to their”open scope” nature, we believe that capability
is somewhat meaningless. There is however no known technical reason
preventing us from doing so."

I interpreted "meaningless" in the sense of "not useful", by the previous
answers I presume that "yes it has good uses" and also there are
known technical issues.

BR
Cleiton


Em ter., 3 de nov. de 2020 às 14:13, Zach Laine via SG7 <
sg7_at_[hidden]> escreveu:

> @Cleiton The take-away is: resolve all these questions to EWG's
> satisfaction, and you might just get this. It is widely desired, but
> the issues are real, as Andrew noted.
>
> Zach
>
> On Tue, Nov 3, 2020 at 7:58 AM Andrew Sutton via SG7
> <sg7_at_[hidden]> wrote:
> >>
> >> "Of note here is that we are not proposing a function to retrieve
> members of namespaces..."
> >>
> >> I believe "Automatic Class Register" for load/storing frameworks, may
> be a good reason for members of namespace ( obviously filtered ):
> >>
> >> I need to get all classes derived from "Widget" (called T in this
> sample) in the namespace "MyFramework" and all of it´s inner namespaces,
> that has funcion "toStream(ostream&)" declared.
> >
> >
> > I also have good uses cases for getting namespace members. The reason we
> avoided doing it in P1240 is largely due to technical reasons. For example:
> >
> > namespace N {
> > void f();
> > void f();
> > }
> >
> > static_assert(members_of(reflexpr(N) == 2); // error or OK?
> >
> > In Clang, the answer is 2. In GCC, the answer is 1. Which is right?
> P2237 actually discusses this particular issue: the answer will be 1
> because you have two declarations of the same entity.
> >
> > Reopening namespaces also poses some interesting issues:
> >
> > namespane N { void f(); }
> > static_assert(members_of(reflexpr(N) == 1);
> > namespane N { void g(); }
> > static_assert(members_of(reflexpr(N) == 2); // huh
> >
> > Despite being a constexpr function, members_of returns non-equal values
> at different points in the program. Some people tend to be leery about
> constexpr functions returning different values depending on where they're
> called---they aren't really constant expressions anymore. This would break
> an implementation that tries to cache results.
> >
> > And then there are some sticky questions about how to reflect unnamed
> namespaces, using directives, using namespace directives, etc.
> >
> > --
> > SG7 mailing list
> > SG7_at_[hidden]
> > https://lists.isocpp.org/mailman/listinfo.cgi/sg7
> --
> SG7 mailing list
> SG7_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg7
>