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 <
> 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
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
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.