This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of TS status.

2588. [fund.ts.v2] "Convertible to bool" requirement in conjunction and disjunction

Section: 3.3.3 [fund.ts.v2::meta.logical] Status: TS Submitter: Tim Song Opened: 2016-01-18 Last modified: 2017-07-30

Priority: 3

View all other issues in [fund.ts.v2::meta.logical].

View all issues with TS status.

Discussion:

Addresses: fund.ts.v2

The specification of conjunction and disjunction in 3.3.3 [fund.ts.v2::meta.logical] p2 and p5 requires Bi::value to be convertible to bool, but nothing in the specification of the actual behavior of the templates, which instead uses the expressions Bi::value == false and Bi::value != false instead, actually requires this conversion.

If the intention of this requirement is to allow implementations to pass Bi::value directly to std::conditional, like the sample implementation in P0013R1:

template<class B1, class B2>
struct and_<B1, B2> : conditional_t<B1::value, B2, B1> { };

then it's insufficient in at least two ways:

  1. Nothing in the specification requires the result of comparing Bi::value with false to be consistent with the result of the implicit conversion. This is similar to LWG 2114, though I don't think the BooleanTestable requirements in that issue's P/R covers Bi::value == false and Bi::value != false.

  2. More importantly, the above implementation is ill-formed for, e.g., std::conjunction<std::integral_constant<int, 2>, std::integral_constant<int, 4>>, because converting 2 to bool is a narrowing conversion that is not allowed for non-type template arguments (see 7.7 [expr.const]/4). (Note that GCC currently doesn't diagnose this error at all, and Clang doesn't diagnose it inside system headers.) It's not clear whether such constructs are intended to be supported, but if they are not, the current wording doesn't prohibit it.

[2016-11-08, Issaquah]

Adopted during NB comment resolution

Proposed resolution:

The resolution for this issue was combined with the resolution for LWG 2568, so 2568 resolves this issue here as well.