non-constant-expression cannot be narrowed from type 'int' to 'unsigned long long' in initializer list

Question

int main(int argc, char const *argv[])
{
   int x =  4;
   int y = 2;
   const int cell = x/y;
   auto a = std::bitset<20>{cell}; //fails
   auto b = std::bitset<20>(cell); //works
}

Why does std::bitset not allow me to construct with curly braces here, but works with parenthesis construction? If cell was instead a constexpr, both would compile.

The compile error:

test.cpp:21:29: error: non-constant-expression cannot be narrowed from type 'int' to 'unsigned long long' in initializer list [-Wc++11-narrowing]
   auto a = std::bitset<20>{x*y}; //fails
                            ^~~
test.cpp:21:29: note: insert an explicit cast to silence this issue
   auto a = std::bitset<20>{x*y}; //fails
                            ^~~
                            static_cast<unsigned long long>( )
1 error generated.

Solution

The failing line uses list-initializing syntax:

auto a = std::bitset<20>{cell}; //fails

This syntax is defined in Section 11.6.4 of the C++17 standard. The relevant part:

List-initialization of an object or reference of type T is defined as follows:

...

(3.7) Otherwise, if T is a class type, constructors are considered. The applicable constructors are enumerated and the best one is chosen through overload resolution (16.3, 16.3.1.7). If a narrowing conversion (see below) is required to convert any of the arguments, the program is ill-formed.

...

A narrowing conversion is an implicit conversion

...

(7.4) from an integer type or unscoped enumeration type to an integer type that cannot represent all the values of the original type, except where the source is a constant expression whose value after integral promotions will fit into the target type.

This gives us a better understanding of what is going on:

// Works, no narrowing check, implicit conversion.
std::bitset<20> a(2);
std::bitset<20> b(-1);
std::bitset<20> c(cell); 

// Works, 2 can be converted without narrowing
std::bitset<20> d{2};

// Fails, -1 cannot be converted without narrowing
std::bitset<20> e{-1};

// Fails, compiler does not understand cell can be converted without narrowing
std::bitset<20> f{cell};

In your program, the compiler does not understand that cell is a constant expression. It checks the available constructors for std::bitset and sees it has to convert from int to unsigned long long. It thinks that int could be potentially be negative, therefore we have a narrowing conversion.

We can fix this by making cell a constexpr, which is stronger than const. Whereas const only means that the value should not be changed, constexpr means the value is available at compile time:

  constexpr int x = 4;
  constexpr int y = 2;
  constexpr int cell = x / y;

  auto a = std::bitset<20>{cell}; // works

You could now ask why list-initialization does not allow for narrowing conversion. I cannot fully answer this. My understanding is that implicit narrowing is generally seen as undesirable because it can have unintended consequences, and that it was excluded for this reason.

Comments

[24n8]

Ah I didn't know that an int to an unsigned long long is a narrowing conversion. Is this because int can be negative? If it had been an unsigned int instead of plain int, it seems that the conversion would be widening rather than narrowing.

[f9c69e9781fa194211448473495534]

Right, it's narrowing because the negative values cannot be represented. Your original program compiles fine when using unsigned int.

[Shayna]

@f9c69e9781fa194211448473495534 What? No, it's a narrowing conversion because on 99% of compilers, int is a 32-bit integer and long long is a 64-bit integer. Going from signed to unsigned isn't a narrowing conversion; the amount of bits required to represent a signed or unsigned version of any size integer is the same, the only difference is how those bits are interpreted. A signed 32-bit integer's last bit indicates whether or not the remaining 31 bits are negative, this is why the signed integer limit is 2147483648 rather than 4294967296 (2^31 vs 2^32), that's the only difference.

[f9c69e9781fa194211448473495534]

@Shayna I don't understand your point. My understanding of the C++ standard is that a narrowing conversion is about the representable range of values, not the number of bits required: "A narrowing conversion is an implicit conversion from an integer type or unscoped enumeration type to an integer type that cannot represent all the values of the original type" (open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3035.pdf#page‌​=218). An unsigned type cannot represent a signed value.

[Shayna]

@f9c69e9781fa194211448473495534 I was under the impression that a narrowing conversion means trying to fit the data from one type into a narrower type: a type that cannot logically contain the original data because it's simply too short, e.g. 32>16, 16>8, etc, causing the overflowing bits to be cut off - which is not the case when going from signed>unsigned. What I did not know is that the standard extends that definition to loss of sign conversions. When I try to compile it, the compiler complains of two narrowing conversions, the long long>int and the signed>unsigned. My bad! You're right.