C++ Logo


Advanced search

Re: Scalable reflection - questions / comments

From: Matus Chochlik <chochlik_at_[hidden]>
Date: Tue, 1 Feb 2022 17:53:42 +0100
Just to clarity what my concerns about the proposed API are:

I think we should not ship reflection in a state where end-user code would
be required to do something like this
whenever splicing is required (and usage shows that it is required very
template <meta::info mo>
auto my_algo() {
    return do_something([: mo :]);
because compositions of such functions look really bad as shown in my
original message.

If we add consteval function arguments (or something) where this will be
consteval auto my_algo(meta::info mo) requires(reflects_type(mo)) {
    return type_identity<[: mo :]>{} // different return type for different
values of `mo`
then the whole reflection API would be much more "nice". Note that the
above would effectively be equivalent to a template function.

If we plan to deliver consteval function parameters later than reflection,
then I'd suggest not to specify the actual type of the metaobject, but
rather as:

template <typename T>
concept metaobject = __unspecified__

consteval bool some_predicate(metaobject auto mo);
consteval auto some_operation(metaobject auto mo);

and later when the consteval arguments are available just say:

template <typename T>
concept metaobject = is_same_v<T, meta::info>;

I started writing a paper with details, but it won't be ready for
tomorrow's SG7 telco.


Received on 2022-02-01 16:53:54