Subject: Re: [boost] [metal] Feature Complete - Request for Feedback
From: Bruno Dutra (brunocodutra_at_[hidden])
Date: 2017-02-21 23:07:54
On Tue, Feb 21, 2017 at 11:32 PM, Peter Dimov via Boost <
boost_at_[hidden]> wrote:
> Bruno Dutra wrote:
>
>> That alone however opens a whole trunk of worms, because one has to deal
>> with stuff like this:
>>
>> join<std::tuple<>, std::map<X, Y>, std::unique_ptr<Z>>
>>
>> Should this be valid and if so what should be the result?
>>
>
> Let me check...
>
> Should it then be std::tuple<X, Y, std::less<X>,
>> std::allocator<std::pair<X const, Y>>, Z, std::default_delete<Z>>?
>>
>
> Yes. :-)
>
> But why should the result List "type" be std::tuple?
>>
>
> The type of the first list is used by convention.
>
> Conundrums like these made it very tricky to implement even the simplest
>> of the algorithms and had a inevitable impact on performance.
>>
>
> Well... it does make things a bit more convoluted here or there, but it's
> not that big of a burden.
>
Good, so let us raise the bar a further notch ;)
What about insert<std::map<X, Y>, number<2>, F>, should it yield
std::map<X, Y, F>? Should it SFINAE away because std::map can't fit 5
elements?
And how about erase<std::map<X, Y, F>, number<2>>, should it yield
std::map<X, Y>? Should it SFINAE away because std::map can't fit less than
4 elements?
Metal suffers of none of these issues, at the extra instantiation of
metal::as_list, which BTW also serves as a clear indication of intent that
helps other programmers understand the code and debug if necessary.
Regards,
Bruno