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

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-03-02 14:40:14

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/tutorials/employee.html
> 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/adapt_struct.html
> 
> 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<T, M> 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 T,
    class Bd = describe_bases<T, mod_any_access>,
    class Md = describe_members<T, mod_any_access>>
    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.)