Re: [boost] [GSoC, MPL11] Community probe

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?

Regards,
Louis