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

Subject: Re: [boost] [MPL][vector] Is there interest in mpl::vector using variadic templates?
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-03-02 21:43:31

On Thu, Mar 2, 2017 at 9:55 PM, paul via Boost <boost_at_[hidden]>
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 <boost_at_lists.boo
> > st.org>:
> > >
> > > 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