Re: [boost] About all these metaprogramming libraries

Subject: Re: [boost] About all these metaprogramming libraries
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-03-19 19:31:44

On Sun, Mar 19, 2017 at 7:43 PM, Oswin Krause <
Oswin.Krause_at_[hidden]> wrote:

> On 2017-03-19 17:13, Bruno Dutra via Boost wrote:
>
>> On Sun, Mar 19, 2017 at 4:22 PM, degski via Boost <boost_at_[hidden]>
>> wrote:
>>
>> I must say, I like Peters' 'simple' mp11 though,
>>> providing building blocks to more advanced stuff (I would say (generally)
>>> the STL-spirit).
>>>
>>>
>> I agree being simple is a plus, but IMO there is nothing exceptionally
>> simple about mp11.
>>
>
> Hi,
>
> I would disagree. Conceptionally it is a lot easier to grasp as everything
> is defined either in language primitives or logical constraints.
>
> Here are the concepts:
>
> A list is any type of the form L<T...>.
> A set is a list where all elements are unique
> A map is a set of keys zipped with an arbitrary list of same size.
> A metafunction is a template alias with unspecified template parameters.
>
> The definition of the concepts do not need to reference any primitive
> inside the library and thus it can work well with many other of the
> proposed libraries and libraries outside of boost, without having to jump
> through additional hoops (e.g. renaming/"copying" arguments).
>

You've pretty much described Metal, except that Metal requires lists to be
specializations of metal::list, but that is far from a shortcoming, in fact
there is a very good reason behind that design choice.

What do you expect to happen if you try to erase a value from a template,
such as std::unique_ptr, that has a default parameter using mp11? What
about inserting an element? Templates with default parameters are valid
lists if the template that represents a List is not specified, so
algorithms must be well defined for all these cases, which is very
cumbersome to handle on the library side for very little gain, not to
mention that it often leads to surprising and unexpected behavior.

For me the biggest question is: will it work natively with mpl::vector?
> This would make it a clear winner in my book.
>

Working natively with mpl::vector is only possible through adaptors, either
implicit in the library, or explicit to the user, because the type of the
concept behind mpl::vector is unspecified by design. Personally I think
there is very little gain in embedding such adaptors implicitly in any
library, because they bring along a lot of legacy and make the life of
maintainers miserable for basically no gain, since a explicit adaptor, such
as from_mpl<>, has zero cost to the user.

My choice for Metal was to provide metal::from_mpl, a metafunction that
converts any MPL concept to its equivalent in Metal parlance.

Bruno