Re: [boost] [MPL][vector] Is there interest in mpl::vector using variadic templates?

On Thu, Mar 2, 2017 at 9:55 PM, paul via Boost wrote:

On Wed, 2017-03-01 at 21:56 +0300, Antony Polukhin via Boost wrote:

...

2017-02-21 13:52 GMT+03:00 Михаил Максимов via Boost :

...

Dear community,

I've recently started contributing to boost::variant. To speed up variant's compilation I'm implementing mpl::vector on variadic templates. For now status of new vector implementation is:

<...>

...

made me wonder, is there interest in variadic templates implementation? Are there limitations for it's usefulness, which I did not see?

I'm very interested in patching MPL to be able to use variadic templates.

There are many C++ libraries and code that use MPL. Those libraries can not switch from MPL to Metal or Hana because: * they have to be usable in C++98/C++03 and C++11 * they have a huge code base that can not be simply migrated to new library * they depend on third party libraries that use MPL and need the ability to interact with those libraries

Moreover, making MPL variadic will not just speed up compilation, but also will: * reduce executable size and improve startup times if MPL structure is part of an exported entity * improve runtime speed if MPL structure is part of an entity that is used in operations involving typeid()

So please, continue the work and make a pull request.

I wonder if instead an MPL implementation could be written with a Metal backend for newer compilers and use the legacy MPL for C++03 compiler. I thought Bruno was developing something like that at one point. So building off of that could be useful. Although, Metal is not in boost yet, hopefully it will be soon.

Indeed I proposed this idea on the mailing list about a year ago, when Metal was very similar to MPL in terms of design, such that I wasn't sure whether it made sense to propose Metal as a separate library, but even back then some expressed concerns about reworking MPL internally and argued Metal should be proposed as an independent library instead. The truth is, it is very hard to achieve consensus in this community regarding big and potentially breaking changes to MPL, since it is one of the cornerstones of the Boost libraries, so I decided to take a step back and tackle the problem at a different angle. My idea is to provide an independent implementation of MPL based on Metal on a separate repository, such that users could seamlessly replace MPL on legacy code [1]. Should it prove successful, would it probably be easier to gather support in the community for its integration in MPL proper. Now, implementing MPL from the ground up while making sure it can be used to compile all other Boost libraries and pass all MPL unit tests is a huge undertaking no matter what and I warmly welcome any help. [1]: https://github.com/brunocodutra/metal/projects