boostorg/fusion — pull request #3 by daminetreg (2014-03-05 00:22:58+00:00)
Title: Version of ADAPT_STRUCT that does not require specifying the types of the fields

Hi @djowel,

I finally got a first version of the __BOOST\_FUSION\_AUTO\_ADAPT\*__ macros which deduce the types of the attributes fields. The idea I have is avoiding where this makes sense to repeat the type, as it is an important source for mistakes when changing the type of one of the fields, this is especially problematic with types that can be auto converted between each other as it lead to loss of precision and other kinds of issue.

It's also nice to type less. :)

This pull-request follow the discussion on the boost devel mailing list : [DRYing BOOST\_FUSION\_ADAPT\_STRUCT with decltype/Boost.TypeOf](http://lists.boost.org/Archives/boost/2013/12/209912.php) and the related ticket [\#9516](https://svn.boost.org/trac/boost/ticket/9516).

To sum it up, this patch allows one to adapt a given struct to a random access sequence, by only providing the list of members to adapt :

```cpp
namespace demo
{
struct employee
{
std::string name;
int age;
};
}

// demo::employee is now a Fusion sequence
BOOST_FUSION_AUTO_ADAPT_STRUCT(
demo::employee,
(name)
(age))
```

The changes are relatively small and are only macros, I added new headers bringing the auto versions of the macros :

* `include/boost/fusion/adapted/struct/auto_adapt_struct.hpp`
* `include/boost/fusion/adapted/struct/auto_adapt_struct_named.hpp`
* `include/boost/fusion/adapted/struct/auto_adapt_assoc_struct.hpp`
* `include/boost/fusion/adapted/struct/auto_adapt_assoc_struct_named.hpp`

I duplicated the related units-test of the non auto version and adapted them, as we now have :

* `test/sequence/auto_adapt_struct.cpp`
* `test/sequence/auto_adapt_struct_named.cpp`
* `test/sequence/auto_adapt_assoc_struct.cpp`
* `test/sequence/auto_adapt_assoc_struct_named.cpp`

I also added the related documentation in `doc/adapted.qbk`, a generated version can be found [here](http://lecbna.org/sys_lecbna/boost_fusion_type_deduction_for_adapt_struct_doc/) for reference. The additions are in the _Adapted_ section under :

* BOOST\_FUSION\_ [AUTO\_] ADAPT\_STRUCT
* BOOST\_FUSION\_ [AUTO\_] ADAPT\_STRUCT\_NAMED
* BOOST\_FUSION\_ [AUTO\_] ADAPT\_ASSOC\_STRUCT
* BOOST\_FUSION\_ [AUTO\_] ADAPT\_ASSOC\_STRUCT\_NAMED

As this is a first version, I'm the meaning that this isn't good enough to integrate it in fusion. That's why I opened this pull-request, so that we can discuss about the signatures and the implementation of the AUTO macros. Indeed different questions appeared to me, while writing these new type deducing ADAPT macros.

I would be really thankful to you if you could give me some pointer or hints to clear them up, these questions are mainly design choices, because I'm afraid that with these AUTO macros I could have broken the coherence of the Boost.Fusion API.

## Why is there two places for the Boost.Fusion headers ?

For example BOOST\_FUSION\_ADAPT\_STRUCT is available from both :
* `boost/fusion/adapted/struct/adapt_struct.hpp`
* `boost/fusion/include/adapt_struct.hpp`

Is that because of backward compatibility ? Or are the boost/fusion/adapted... ones private and others public ?

In this patch only the boost/fusion/adapted/struct/ are provided as I wasn't sure.

## What about mixing together the AUTO version and normal ADAPT macros ?
Currently I choosed to make always another version of the macro for the type deducing one, with an AUTO prefix in front of it, to provide the meaning of the auto keyword as in C++11.

I'm not sure that this is a good idea it would perhaps be better if the existing BOOST\_FUSION\_ADAPT\_STRUCT macros and others would be usable as well with pairs of *(member_typeN, member_nameN)* and only *(member_nameN)*, or is it pointless to be able to specify the type, and it would be even better to provide a breaking change for the ADAPT api ?

This would allow something like optional type parameters :

```cpp
namespace demo
{
struct employee
{
std::string name;
int age;
std::string postal_address;
int salary;
};
}

// demo::employee is now a Fusion sequence
BOOST_FUSION_ADAPT_STRUCT(
demo::employee,
(std::string, name)
(age)
(postal_address)
(int, salary))
```

Would this be a good idea ? And what are the coherence issue with the *\_TPL* version of the macro ?

### Sub questions if we don't mix AUTO and normal ADAPT macros

#### Is it better to put the auto macro in the same headers files than the non-auto one ?
Currently I made new header files for the auto version, but I'm not so sure if it makes sense, should I put them together ?

#### Should we have the units-test for both be in one units test file and share at most code ?
In this patch I simply duplicated and adapted the units tests for the auto version. This is naturally not fun to manage changes to the units test.

## Doing the same for the \_TPL version ?
I'm not sure if this would be possible, but I would be happy to also be able to deduce template parameter name or read them from the template decl to avoid repeating them there too. Do you see some practicable way to achieve this ?

## Type deducing doesn't makes sense for BOOST\_FUSION\_ADAPT\_ADT and BOOST\_FUSION\_ADAPT\_ASSOC\_ADT
If I understood well, it's even the point of BOOST\_FUSION\_ADAPT\_ADT and BOOST\_FUSION\_ADAPT\_ASSOC\_ADT to be able to specify the type of the fields, and that there is no point in deducing them there ? Perhaps mistaken on this point.

Thank you for taking the time to review this pull-request :)
Looking forward to read from you.

Cheers,