Subject: Re: [boost] [GSoC, MPL11] Community probe
From: Louis Dionne (ldionne.2_at_[hidden])
Date: 2014-04-30 19:24:22
Gonzalo Brito Gadeschi <g.brito <at> aia.rwth-aachen.de> writes:
> This approach has advantages/disadvantages, the ones that come to mind are:
> - i think it only works if the types in the tuple have constexpr
> constructors (_huge drawback_ unless a workaround is found),
I think it won't work with incomplete types, with types that don't have
a default constructor and with function types too. There might be a good
workaround for this though.
> - performance (it might be slower to compile, but I haven't profiled so I
> don't know),
If it turns out to be an interesting avenue, I'll benchmark it properly.
> - it gives you a unified way of performing type-only and type-value
> manipulations at compile-time,
Definitely a plus.
> - you cannot use lambda functions inside relaxed-constexpr functions (so
> the restricted part of C++ that is allowed inside constexpr functions needs
> to be considered).
Another thing with constexpr functions is that you can't static_assert on
their arguments, but I don't think that would be a show stopper.
> If so, Boost.MPL and Boost.Fusion would have some overlap that might be
> worth studying.
I do think these libraries overlap. Actually, I think Fusion would be pretty
much a superset of the MPL if it was not for the fact that Fusion must work
with types that can be constructed. Could someone involved with Fusion
confirm or refute this?