Re: [boost] [review][mp11] Formal review of Mp11

I think for people who don't use packs often the fact that the E... pack is being used essentially to make E optional is a source of confusion. The way it's implemented, you can also pass more than one type in the else to mp_if_c when the condition is true, but not if it's false. Maybe you couuld separate the detail::mp_if_c_impl into 2 specializations for the true case, one with a single else and one with no else type. Then passing multiple else types would always fail substituation whether or not the condition is true or false. Then I'd change the documentation to list out those two separate true cases and make no mention of the E..., or if you want you could say mp_if_c will always fail substituation explicitly in the documentation (but that again just seems like adding confusion.) - Josh On Sat, 15 Jul 2017, Andrey Semashev via Boost wrote:

On 07/15/17 15:47, Peter Dimov via Boost wrote:

...

Vinnie Falco wrote:

...

* The documentation states: "mp_if_c is an alias for T. mp_if_c is an alias for E. Otherwise, the result is a substitution failure."

Should that read "mp_if_c"? If not, why?

No.

The idea here is that mp_if_c can be used in two ways. One is mp_if_c, which gives either T or E depending on Cond. The other is mp_if_c, which is the same as std::enable_if_t - gives T when Cond, otherwise a substitution failure.

So

mp_if_c is T mp_if_c is T mp_if_c is E

Aliases can't be specialized, so it's not possible to implement just the above, which is why it takes a parameter pack for E... and does

mp_if_c is T mp_if_c is E

which for the three cases we're interested in gives the results we need.

Why not separate the two use case into two primitives? We usually want one or the other and different tools would make sense, at least for documenting purpose.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost