Date: Tue, 7 Dec 2021 09:54:54 +0100
Hi SG7,
Here are some examples of a new experimental API that is written on top of
the compiler builtins from the TS implementation:
https://compiler-explorer.com/z/zePhMf9hc
https://godbolt.org/z/Ka54ETjcs
Because of current limitations of consteval, some things cannot be
implemented without using some TMP, but TMP is not required (almost at all)
to use the API by the end-users.
In this API the metaobjects are represented as *values* but they don't have
a single named type and the operations are implemented as template
functions. Otherwise it is similar to the meta::info proposal and currently
it is more useful and powerful because it is not limited by pure consteval.
If/when the issues with consteval are fixed (for example the ability to
change function return type based on the value of a non-template consteval
argument) we could turn the now anonymous metaobject types to a single type
like `meta::info`, add the sequence filtering predicates, code splicing,
and add support for storing meta-objects in consteval containers, etc. IMO
without breaking the existing API.
So I have a couple of questions:
1) Do we see this as a viable stepping stone toward getting a first usable
version reflection into the standard that can be extended later or would
this be OMDB for someone? (if so I'd be interested in some reasoning why,
except for TMP-bad)
2) Should I try to write a paper?
3) Would someone be interested in helping with the paper?
BR,
--Matus
Here are some examples of a new experimental API that is written on top of
the compiler builtins from the TS implementation:
https://compiler-explorer.com/z/zePhMf9hc
https://godbolt.org/z/Ka54ETjcs
Because of current limitations of consteval, some things cannot be
implemented without using some TMP, but TMP is not required (almost at all)
to use the API by the end-users.
In this API the metaobjects are represented as *values* but they don't have
a single named type and the operations are implemented as template
functions. Otherwise it is similar to the meta::info proposal and currently
it is more useful and powerful because it is not limited by pure consteval.
If/when the issues with consteval are fixed (for example the ability to
change function return type based on the value of a non-template consteval
argument) we could turn the now anonymous metaobject types to a single type
like `meta::info`, add the sequence filtering predicates, code splicing,
and add support for storing meta-objects in consteval containers, etc. IMO
without breaking the existing API.
So I have a couple of questions:
1) Do we see this as a viable stepping stone toward getting a first usable
version reflection into the standard that can be extended later or would
this be OMDB for someone? (if so I'd be interested in some reasoning why,
except for TMP-bad)
2) Should I try to write a paper?
3) Would someone be interested in helping with the paper?
BR,
--Matus
Received on 2021-12-07 02:55:12