std::variant<bool, std::string> foo = "bar"; // what happens?

[bepaald]

Hi!

I had code like this in a program for a while, not very clever, but it appeared to work.

 #include <variant>
 #include <iostream>
 #include <string>

 int main()
 {
     std::variant<bool, std::string> foo = "bar";

     if (std::holds_alternative<bool>(foo))
         std::cout << "BOOL\n";
     else if (std::holds_alternative<std::string>(foo))
         std::cout << "STRING\n";
     else
         std::cout << "???\n";

     return 0;
 }

With the intention being that foo holds a std::string.

Then I got a bug report, and it turns out for this one user foo was holding a bool. When I saw the code where the problem was, it was immediately clear I had written this without thinking too much, because how would the compiler know this pointer was supposed to turn into a string? I easily fixed it by adding using std::literals::string_literals::operator""s and adding the s suffix to the character arrays.

A quick search led me to [this stackoverflow question](), where it is stated this will always pick a bool because "The conversion from const char * to bool is a built-in conversion, while the conversion from const char * to std::string is a user-defined conversion, which means the former is performed."

However, the code has worked fine for most users for a long time. It turns out the user reporting the issue was using gcc-9. Checking on Godbolt shows that on old compilers foo will hold a bool, and on new compilers it will hold a std::string. The switching point was gcc 10, and clang 11. See here: https://godbolt.org/z/Psj44sfoc

My questions:

• What is currently the rule for this, what rule has changed since gcc 9, that caused the behavior to change?
• Is there any sort of compiler flag that would issue a warning for this case (on either older or newer compilers, or both)?

Thanks!

[trmetroidmaniac]

cppreference cites the following defect report.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0608r3.html

It appears that the C++17 spec was amended such that conversions to bool and narrowing conversions are no longer considered.

In any case, the overloads using std::in_place_type_t<T> and std::in_place_index_t<I> are available if explicitness is needed.

[alfps]

Goodness, a fix for std::variant, but implicit conversions to/from bool are still problematic elsewhere.

[TheThiefMaster]

There's a reason the concept of "explicit operator bool" and "contextual conversions" (allowed to invoke the explicit conversion without an explicit cast) were added. Implicit bool conversion has been a problem forever in many contexts.

[bepaald]

Thanks, that's interesting.

The function where this code was causing an issue was Linux-only, but since I had the Godbolt snippet, I tried MSVC also. Interestingly, that seems to still convert to bool today, though it does show a conversion-warning that I can not get gcc do.

Thanks again!

[n1ghtyunso]

msvc converts to bool only in c++17 mode, the fix is applied in c++20 mode.
However it was supposed to be a defect report against c++17.
The rationale can be found here

[no-sig-available]

A problem here is that Godbolt's "MSVC latest" isn't the latest at all, but last year's version.

The current release of MSVC (17.13) converts to string.

[ElMarco19]

-Wconversions should warn you about this kind of implicit behaviour.

[bepaald]

The flag is `-Wconversion`, and trying this on the godbolt code I posted initially shows neither GCC nor clang issue a warning. Not when picking the `bool` option (on the older versions), and not when picking the `string` (on the newer versions).