Is user-defined conversion to fundamental-type deletable?

Question

template<typename Integral>
struct IntegralWrapper {
    Integral _value;

    IntegralWrapper() = default;

    IntegralWrapper(Integral value)
        : _value(value) {}
    
    operator Integral() const {
        return _value;
    }

    operator bool() const = delete;
};

int main() {
    IntegralWrapper<int> i1, i2;
    i1 * i2;
}

It's compiled successfully by gcc, but failed by MSVC and clang, with error overloaded operator '*' is ambiguous. The problem comes from the explicit deleted operator bool.

https://godbolt.org/z/nh6M11d98

---

Which side (gcc or clang/MSVC) is right? And why?

Answer 1

First of all: Deleting a function does not prevent it from being considered in overload resolution (with some minor exceptions not relevant here). The only effect of = delete is that the program will be ill-formed if the conversion function is chosen by overload resolution.

---

For the overload resolution:

There are candidate built-in overloads for the * operator for all pairs of promoted arithmetic types.

So, instead of using * we could also consider

auto mul(int a, int b) { return a*b; } // (1)
auto mul(long a, long b) { return a*b; } // (2)
// further overloads, also with non-matching parameter types

mul(i1, i2);

Notably there are no overloads including bool, since bool is promoted to int.

For (1) the chosen conversion function for both arguments is operator int() const instantiated from operator Integral() const since conversion from int to int is better than bool to int. (Or at least that seems to be the intent, see e.g. https://github.com/cplusplus/draft/issues/2288 and In overload resolution, does selection of a function that uses the ambiguous conversion sequence necessarily result in the call being ill-formed?).

For (2) however, neither conversion from int or bool to long is better than the other. As a result the implicit conversion sequences will for the purpose of overload resolution be the ambiguous conversion sequence. This conversion sequence is considered distinct from all other user-defined conversion sequences.

When then comparing which of the overloads is the better one, neither can be considered better than the other, because both use user-defined conversion sequences for both parameters, but the used conversion sequences are not comparable.

As a result overload resolution should fail. If I completed the list of built-in operator overloads I started above, nothing would change. The same logic applies to all of them.

So MSVC and Clang are correct to reject and GCC is wrong to accept. Interestingly with the explicit example of functions I gave above GCC does reject as expected.

---

To disallow implicit conversions to bool you could use a constrained conversion function template, which will not allow for another standard conversion sequence after the user-defined conversion:

template<std::same_as<int> T>
operator T() const { return _value; } 

This will allow only conversions to int. If you can't use C++20, you will need to replace the concept with SFINAE via std::enable_if.