Re: [boost] [Describe] Boost.Describe vs Boost.Fusion

Andrzej Krzemienski wrote:

Hi Everyone (but mainly Peter), Boost.Spirit needs to have an index-based access to user defined types, as explained in the tutorial: https://www.boost.org/doc/libs/1_75_0/libs/spirit/doc/x3/html/spirit_x3/tuto... Currently Boost.Spirit uses the interface of Boost.Fusion, and users are encouraged to use macros like BOOST_FUSION_ADAPT_STRUCT: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapted/ad...

The first question is, can Boost.Describe's interface be plugged into Boost.Spirit?

I'll need to take a closer look at Fusion to be able to tell; it _should_ be possible.

It is not that obvious to me for a couple of reasons. For instance, it would require an interface in Boost.Describe for answering the question, "has describe::members been specialized for type X"?

describe_members fails substitution when not specialized, which can be used as a check. The examples use this to implicitly disable their overloads. E.g. the overload ``` template, class Md = describe_members> std::ostream& operator<<( std::ostream & os, T const & t ) { ``` will not be considered when T hasn't been described, because both describe_bases and describe_members will fail substitution.

The second question is, can is Boost.Describe capable of replacing the adapter macros in Boost.Fusion? For instance, Boost.Fusion allows the users to define and adapt a user defined type with one macro: https://www.boost.org/doc/libs/1_75_0/libs/fusion/doc/html/fusion/adapte d/define_struct.html

This is similar in concept to what macro BOOST_DEFINE_ENUM does for enums. What is the motivation behind allowing the definition of enums in this way but not classes (at least the aggregate classes).

I suppose this can be added, if there's demand. Taking the BOOST_DEFINE_ENUM macro seemed acceptable as there's currently no Boost library targeting enums, but BOOST_DEFINE_STRUCT is quite the land grab, and BOOST_DESCRIBE_DEFINE_STRUCT is just awkward. Typically, repeating the member names of an aggregate is less annoying than repeating the enumerators, but, as I said, we can add a DEFINE_STRUCT macro in principle if this is considered necessary and acceptable.

My general observation is that we have a number of libraries with overlapping goals: Boost.Describe, Boost.PFR, Boost.Fusion (the part for adapting UDTs)

+ Boost.Hana The aspiration is to have a single library that only deals with describing types so that others don't need to provide this functionality over and over. Although of course there's that classic xkcd. https://xkcd.com/927/ (The other aspiration is to make the describe_* primitives standard and compiler built-ins, so that the macros wouldn't be necessary. But at this point, it's not clear how feasible that is.)