Search code examples
c++templatestype-conversionwrapper

Allow implicit type conversion during template evaluation

I'm writing a wrapper class for C++ types, which allows me to instrument when a wrapped object is constructed, accessed, modified, and destroyed. To make this transparent for the original code, I include implicit conversion functions back to the underlying type, but this fails when a wrapped object is passed directly to a template since implicit conversions aren't evaluated. Here's some code that demonstrates this problem:

#include <utility>

// simplified wrapper class
template <typename T>
class wrap {
    T t;
public:
    wrap() : t() {}
    wrap(const T& _t) : t(_t) {}
    wrap(T&& _t) : t(std::move(_t)) {}

    constexpr operator T&() { return t; }
    constexpr operator const T&() const { return t; }
};

// an example templated function
template <typename T>
bool is_same(const T& t1, const T& t2) { return t1 == t2;}

// second invocation fails due to template substitution failure
bool problem() {
    wrap<int> w(5);

    return is_same(static_cast<int>(w), 5) && is_same<>(w, 5);
}

I can resolve this manually by performing a static_cast on the wrapped variable at each template call site (as shown in the first invocation), but this doesn't scale well since I'm working with a large code base. Similar questions suggest inlining each template function as a friend function, but this also requires identifying and copying each template, which doesn't scale.

I'd appreciate any advice on how to (1) workaround this conversion problem with templated functions, or (2) otherwise instrument a variable at source-level without this problem.

Solution

  • The fault in this example lies with is_same. It declares that it requires two arguments of the same type, which is a requirement it does not need, and fails to require that type to have an ==, which it does need.

    Granted, it is common to find C++ that poorly constrains template functions because it is difficult and verbose to do otherwise. Authors take a practical shortcut. That said, isn't the approach to fix the interface of is_same?

    // C++17 version. Close to std::equal_to<>::operator().
template <typename T, typename U>
constexpr auto is_same(T&& t, U&& u)
    noexcept(noexcept(std::forward<T>(t) == std::forward<U>(u)))
    -> decltype(std::forward<T>(t) == std::forward<U>(u))
{
    return std::forward<T>(t) == std::forward<U>(u);
}

    With a corrected is_same, the code just works.

    There are other examples one can imagine which may require two arguments to have the same type. For example, if the return type depends on the argument type and the return value can come from either:

    template <typename T>
T& choose(bool choose_left, T& left, T& right) {
    return choose_left ? left : right;
}

    This is much rarer. But it might actually require thought to decide whether to use the underlying or wrapper type. If you have this enhanced behavior in the wrapper type, and conditionally use a wrapped value or an underlying value, should the underlying value be wrapped to continue to get the enhanced behavior, or do we drop the enhancement? Even if you could make this silently choose one of those two behaviors, would you want to?

    However, you can still make it easier to get the value than to say static_cast<T>(...), for example by providing an accessor:

    // given wrap<int> w and int i
is_same(w.value(), 5);
choose_left(true, w.value(), i);

    I have a few other important comments:

    wrap() : t() {}

    This requires T be default constructible. = default does the right thing.

    wrap(const T& _t) : t(_t) {}
wrap(T&& _t) : t(std::move(_t)) {}

    These are not explicit. A T is implicitly convertible to a wrap<T> and vice versa. This does not work well in C++. For example, true ? w : i is not well-formed. This causes std::equality_comparable_with<int, wrap<int>> to be false, which would be a reasonable requirement for is_same. Wrapper types should probably be explicitly constructed, and can be implicitly converted to the underlying type.

    constexpr operator T&() { return t; }
constexpr operator const T&() const { return t; }

    These are not ref-qualified, so they return lvalue references even if the wrapper is an rvalue. That seems ill-advised.

    Finally, construction and conversion only take into account the exact type T. But any place T is used, it might be implicitly converted from some other type. And two conversions are disallowed in C++. So for a wrapper type, one has a decision to make, and that often means allowing construction from anything a T is constructible from.