Deprecate implicit conversion
from bool to character types

Contents

1. Introduction

Semantically (assuming ASCII-compatible encoding), in bool → char conversion, false is converted to U+0000 NULL, and true is converted to U+0001 START OF HEADING. It is hard to see how this conversion needs to be a built-in language feature; possibly, no C++ developer ever wanted a conversion to have these semantics.

Seeing that these implicit conversions also invite bugs like the one above, that makes them not just useless, but actively harmful to the language, qualifying them for removal. Similarly, [P1120R0] deprecated array-to-pointer conversion in equality comparison of two arrays, a bug-prone and virtually useless conversion.

2. Proposal

The goal of this proposal is to deprecate implicit conversion from bool to character types. That is, to char, wchar_t, char8_t, char16_t, and char32_t.

Conversions to signed char and unsigned char are not affected. That is because these types are used for numerics and not to represent characters, so e.g. bool → unsigned char represents a conversion from false to 0 and from true to 1, which is sometimes used in branchless programming:

Note that branchless programming is generally not affected by a bool → char deprecation. For example, in the expression '0' + (x % 2 != 0), both operands are converted to int due to the usual arithmetic conversions and integral promotion. bool → char conversion actually takes place when calling a function with char parameter with a bool argument, when storing a bool value in a char variable, and other such "direct" scenarios.

2.1. Explicit casts should be allowed

While an implicit bool → char conversion is likely a bug, we want users to have a way to suppress deprecation warnings and to retain the old behavior, in the unlikely event they wanted the conversion to happen. There are various other conversion, like std::nullptr_t → bool or void* → int* which follow this pattern of "explicit conversions only".

In summary, the intended semantics are as follows:

While most of these are obvious, some decisions require rationale:

• d2 should be deprecated because direct-initialization, unlike casts, does not generally opt into all possible conversions. For example, static_cast<int*>(void_ptr) is valid, while int* p(void_ptr), for some void* void_ptr.
• d5 should be deprecated because list-initialization is generally more restrictive. For instance, it does not permit narrowing conversions, and I{void_ptr} is ill-formed while I(void_ptr) is okay, where I is int*.
• k1 and k2 should be okay because they are defined in terms of static_cast.

3. Impact on existing code

During discussion of this proposal with various members of the C++ community, no one was able to produce an example of where this conversion is used in existing code. However, we did not yet perform an extensive survey of large code bases.

Furthermore, there are GCC targets that do not comply with the C99 standard, where int8_t is defined to be char (not signed char). The following snippet includes GCC definitions for Solaris 2 ([GccSolaris2]):

/* ??? This definition of int8_t follows the system header but does not conform to C99. Likewise int_fast8_t, int_least8_t. */ #define INT8_TYPE "char"

Since bool → int8_t conversion could plausibly happen in branchless programming, hypothetically, some code on such non-compliant platforms is affected.

In any case, deprecation warnings are easily resolved by performing an explicit conversion, or by prepending + to the bool operand, which would trigger integral promotion and result in int → char conversion instead.

4. Implementation experience

A [ClangWarning] has been implemented in a fork, which triggers in the deprecated cases.

5. Wording

The wording changes are relative to [N5008].

Change [conv.integral] paragraph 1 as follows:

Insert a new paragraph immediately following [conv.integral] paragraph 1:

Insert a new subclause in [depr] between [depr.local] and [depr.capture.this], containing a single paragraph:

6. References