https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120775
Boris Staletic <boris.staletic at protonmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |boris.staletic at protonmail
dot c
| |om
--- Comment #36 from Boris Staletic <boris.staletic at protonmail dot com> ---
I've gone through all of the examples in P2996 and found five errors preventing
Marek's fork from compiling all of them.
See: https://godbolt.org/z/chYM1zPbh
To elaborate:
- The first error is not related to reflections, but has to do with constexpr
reference to local.
- The second error, I'm not sure, but could also be outside of the scope of
reflections and more to do with expansion statements.
- The third error is finicky. Changing the formatting can make it go away. It
prevents, sometimes, expressions like `obj.[:members[Is]:]...`, where `Is` is a
pack from an index sequence.
- The fourth says `obj.[:member_refl:]` is ambiguous when `obj` has multiple
members named `_`. According to P2996, name lookup shouldn't be performed.
- Finally, there's an ICE when trying to call `access_context::unchecked()`
from inside a template.
Regarding "no name lookup", P2996 says this:
> Note that a “member access splice” like s.[:member_number(1):] is a more
> direct
> member access mechanism than the traditional syntax. It doesn’t involve member
> name lookup, access checking, or — if the spliced reflection value represents
> a
> member function — overload resolution.
I also have a library that relies on C++26 reflections, but I have not yet
tried to compile it with Marek's fork, as patterns like those that trigger the
second and third error above do show up in my library.
Either way, the library is available at:
https://codeberg.org/bstaletic/pymetabind
