reflection: generalize registration, rename it register_classes

`use_classes_in<^^ns, Registry>` took one namespace and one registry.
`register_classes<...>` takes four groups of non-type arguments, each
optional, in enforced order - namespaces to scan, classes to register,
one `register_classes_opts` value, registries (as reflections now,
since the pack is `auto...`) - and registers in every listed registry.

Listed classes are dispatch roots: registered whether a method
dispatches on them or not, along with the scanned classes deriving
from them. Classes with no namespace disable the scan - exactly the
listed classes are registered, their inheritance lattice read from
reflection and flattened over unlisted intermediates. Scans now skip
`boost` as well as `std` - worth ~0.2s per TU on a scan of `^^::` in a
Boost.Test TU, and reversible with `scan_boost`/`scan_std`;
`no_recurse` keeps a scan out of nested namespaces. The options live
in a namespace rather than an enum class so a using-directive can make
the terse spellings available.

With no namespace and no class at all, the enclosing namespace is
scanned. Three routes lead there, all resting on P2996's call-site
evaluation of `access_context::current()`: the default template
argument covers `register_classes<>`; a `detail::scope_marker` that
`BOOST_OPENMETHOD_REGISTER_CLASSES` always prepends covers every macro
form, registry-only and options-only included; and the public
`current_namespace()` helper covers bare-template argument lists,
which the template itself cannot capture - a static_assert points
there. The macro no longer pastes `^^`; the caller writes it.

The two new compile-fail tests produce the expected diagnostic via
`#error` when reflection is off, so they pass under every
configuration with no build-file changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UDTJyUvPbFj23o8zVcuvHt

Author: jll63

doc/modules/ROOT/pages/basics.adoc

@@ -86,7 +86,7 @@ inheritance lattice.
 [NOTE]
 ====
 With a compiler that supports C++26 reflection, the class list is unnecessary.
-xref:reference:BOOST_OPENMETHOD_CLASSES_IN.adoc[BOOST_OPENMETHOD_CLASSES_IN]
+xref:reference:BOOST_OPENMETHOD_REGISTER_CLASSES.adoc[BOOST_OPENMETHOD_REGISTER_CLASSES]
 finds the classes on its own - see <<registering_classes_by_reflection>>.
 ====
 
@@ -121,7 +121,7 @@ include::{examplesdir}/ast.cpp[tag=content]
 
 When the compiler supports C++26 reflection (P2996), the library can work out
 the class list for itself. One call to
-xref:reference:BOOST_OPENMETHOD_CLASSES_IN.adoc[BOOST_OPENMETHOD_CLASSES_IN]
+xref:reference:BOOST_OPENMETHOD_REGISTER_CLASSES.adoc[BOOST_OPENMETHOD_REGISTER_CLASSES]
 replaces every
 xref:reference:BOOST_OPENMETHOD_CLASSES.adoc[BOOST_OPENMETHOD_CLASSES] in the
 file:
@@ -139,24 +139,38 @@ BOOST_OPENMETHOD_OVERRIDE(poke, (std::ostream& os, Dog&), void) {
     os << "bark";
 }
 
-BOOST_OPENMETHOD_CLASSES_IN(::); // registers all four classes
+BOOST_OPENMETHOD_REGISTER_CLASSES(^^::); // registers all four classes
 ----
 
-The macro scans the namespace it is given - and the namespaces nested in it -
-for the methods of the registry. It collects the classes those methods dispatch
-on, then registers them, along with every class in the scanned namespaces that
-derives from one of them. `Bulldog` above has no overrider of its own and is
-named nowhere, and is registered all the same.
-
-A base class that no method dispatches on is *not* registered - it could never
-be selected on, and registering it would cost a lattice node, a hash slot and
-dispatch table space for nothing. So a hierarchy rooted in some general-purpose
-base contributes only the part of itself that takes part in dispatch. As soon as
-another method does dispatch on that base, it is registered, and the inheritance
-edges through it with it.
-
-Classes declared in the standard library's or the compiler's own headers are not
-scanned, so `::` costs little more than the narrower namespace would.
+The macro scans the namespaces it is given - and the namespaces nested in them
+- for the methods of the registry. It collects the classes those methods
+dispatch on, then registers them, along with every class in the scanned
+namespaces that derives from one of them. `Bulldog` above has no overrider of
+its own and is named nowhere, and is registered all the same.
+
+The arguments come in four groups, each optional, in this order: reflections of
+namespaces to scan; reflections of classes to register; one value combining
+`register_classes_opts` options with `|`; and reflections of registries to register
+the classes in - `boost::openmethod::default_registry` when none is named. A
+listed class is registered whether a method dispatches on it or not, along with
+the classes the scan finds derive from it. With classes but no namespace,
+nothing is scanned: exactly the listed classes are registered, with the
+inheritance relations between them read from reflection. With neither -
+`BOOST_OPENMETHOD_REGISTER_CLASSES()` - the enclosing namespace is scanned.
+
+A base class that no method dispatches on, and that is not listed, is *not*
+registered - it could never be selected on, and registering it would cost a
+lattice node, a hash slot and dispatch table space for nothing. So a hierarchy
+rooted in some general-purpose base contributes only the part of itself that
+takes part in dispatch. As soon as another method does dispatch on that base,
+it is registered, and the inheritance edges through it with it.
+
+A scan does not enter the `std` and `boost` namespaces, so `^^::` costs little
+more than a narrower namespace would - a method cannot dispatch on a class the
+program never heard of anyway. The `register_classes_opts::scan_std` and
+`register_classes_opts::scan_boost` options bring them back in; a namespace *listed*
+explicitly is always scanned. `register_classes_opts::no_recurse` restricts the scan
+to the members declared directly in the listed namespaces.
 
 Reflection sees only what precedes it, so the macro must come *after* the
 declarations it is meant to find. Putting it at the bottom of the file is the

doc/modules/ROOT/pages/core_api.adoc

@@ -78,13 +78,14 @@ We register the classes with `use_classes`:
 include::{example}/core_api.cpp[tag=use_classes]
 ----
 
-With a compiler that supports C++26 reflection, `use_classes_in` replaces that
-list. It scans a namespace for the registry's methods, and registers the classes
-they dispatch on along with everything in the namespace that derives from them:
+With a compiler that supports C++26 reflection, `register_classes` replaces that
+list. It scans one or more namespaces for the registry's methods, and registers
+the classes they dispatch on along with everything in those namespaces that
+derives from them:
 
 [source,c++]
 ----
-BOOST_OPENMETHOD_REGISTER(use_classes_in<^^::>);
+BOOST_OPENMETHOD_REGISTER(register_classes<^^::>);
 ----
 
 A method declared the way `postfix` is above - an alias for a `method`

doc/modules/ROOT/pages/ref_macros.adoc

@@ -14,7 +14,7 @@ uses of the library.
 | Adds an overrider to a method.
 | xref:reference:BOOST_OPENMETHOD_CLASSES.adoc[*BOOST_OPENMETHOD_CLASSES*]
 | Registers classes.
-| xref:reference:BOOST_OPENMETHOD_CLASSES_IN.adoc[*BOOST_OPENMETHOD_CLASSES_IN*]
+| xref:reference:BOOST_OPENMETHOD_REGISTER_CLASSES.adoc[*BOOST_OPENMETHOD_REGISTER_CLASSES*]
 | Registers the classes of a namespace, by reflection.
 | xref:reference:BOOST_OPENMETHOD_INLINE_OVERRIDE.adoc[BOOST_OPENMETHOD_INLINE_OVERRIDE]
 | Adds an overrider to a method as an inline function.