Hi,
The intention of my P0327R0 proposal is to define
an Product-type access interface (that is a clone of the
tuple-like access interface) *independently* of whether it is
provided by some intrinsic or by reflection (I left this as an
implementation detail as I don't know if it is possible or not).
There was a request from the Kona C++ meeting to
see if and how we can implement the product type access
(P0327R0) using the reflection interface. I believe that the
structure binding wording is quite complex and I have not taken
too much time (in reality no time at all) to see how to
implement it using reflection.
So here it is the challenge I propose to all of
you: Can we implement the
P0327R0 product type access interface (or something similar)
with the reflection interface? If yes, how? If not,
what could be missing? or what could help to make it easier?
Any help would be really appreciated :)
--
You received this message because you are subscribed to the Google Groups "SG 7 - Reflection" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reflection+unsubscribe@isocpp.org.
To post to this group, send email to refle...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/reflection/.
For more options, visit https://groups.google.com/a/isocpp.org/d/optout.
First of all, I think this is a very important consideration since static reflection essentially turns all structs and classes into product types that could be accessible with your proposed interface.My question about the implementation of product-type access is how product types indicate which of their members are "type" fields which are accessible by the interface, and which members are just boilerplate/internal storage.
With static reflection we can very easily implement product type access for structs/classes.However, for other "container" product types, they would need to provide a way of mapping from their internal storage to a unified interface that can be understood by the generic product type functions, either providing a specialization of the product type functions or a unified interface that the generic product type functions could access (think of a "ProductType concept"). For std::tuple this is already implemented, but for future product types (compile-time maps?) this is an important consideration. Reflection might make this easier because you could reflect on the internal storage, but reflecting on the member fields of the tuple class without indicating which ones are relevant to the product type interface would not work.Under the assumption that all structs/classes are product types under this interface you could say something like "product type access only provides access for the public members of a struct". But you would still need some kind of interface for "container" types since their internal storage is probably private, or even contained in a separate implementation struct--regardless, it's an implementation detail.
I'm not sure how to deal with bitfields as I haven't thought much about it, and I don't even know off the top of my head how they fit into the current reflection proposals.
Hope you found this helpful,
Vicente,I made a prototype of this a few days ago with Matus' "reflexpr" fork of Clang. It's quite concise. Does this look like a correct implementation of your interface?https://gist.github.com/jacquelinekay/6bcacee7a3bce7d82b9d6387b6afee96