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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk