
Boost : 
Subject: Re: [boost] [review][mp11] Formal review of Mp11
From: berne_at_[hidden]
Date: 20170715 13:08:01
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<bool,T,E1,E2,Es...> 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<true, T, Eâ€¦> is an alias for T.
>>> mp_if_c<false, T, E> is an alias for E. Otherwise, the result is a
>>> substitution failure."
>>>
>>> Should that read "mp_if_c<false, T, E...>"? If not, why?
>>
>> No.
>>
>> The idea here is that mp_if_c can be used in two ways. One is
>> mp_if_c<Cond, T, E>, which gives either T or E depending on Cond. The
>> other is mp_if_c<Cond, T>, which is the same as std::enable_if_t<Cond,
>> T>  gives T when Cond, otherwise a substitution failure.
>>
>> So
>>
>> mp_if_c<true, T> is T
>> mp_if_c<true, T, E> is T
>> mp_if_c<false, T, E> 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<true, T, E...> is T
>> mp_if_c<false, T, E> 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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk