On Tue, Feb 21, 2017 at 11:32 PM, Peter Dimov via Boost < boost@lists.boost.org> 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