Explicit template argument barrier for algorithms that are function templates

[frederick-vs-ja]

At least since C++20, the C++ standard (via WG21-P0896R4 and following-up LWG-3419) allows implementations to reject code that explicitly specifies template arguments for most algorithms.

The well-formedness and behavior of a call to an algorithm with an explicitly-specified template argument list is unspecified, except where explicitly stated otherwise.

The only exceptions are std::min, std::max, and std::minmax, and implementations are still allowed to reject explicitly specifying Compare. (Probably saturating_cast needs to be another exception as the return type needs to be explicitly specified.)

Note that construct_at, gcd, midpoint, saturating_add etc. are also algorithms as they're specified in [algorithms].

It seems that at least since C++20, we can implement such prohibition with something like the following. With the changes, it should be impossible for users to explicit specify template arguments without typing the internal _Ugly name.

struct _Template_argument_barrier {
    explicit _Template_argument_barrier() = default;
};

// E.g. for modifying midpoint
_EXPORT_STD template <_Template_argument_barrier = _Template_argument_barrier{}, class _Ty>
    requires is_arithmetic_v<_Ty> && (!is_same_v<remove_cv_t<_Ty>, bool>)
_NODISCARD constexpr _Ty midpoint(const _Ty _Val1, const _Ty _Val2) noexcept {
    // ...
}

Do we want to introduce such a barrier?

[StephanTLavavej]

Thanks for bringing this up! In an ideal world, I would love to reject such violations of the Don't Help The Compiler principle. In practice, this would probably break a lot of code and I'm not sure it'd be worth it.

The costs are user discontent leading to slower migrations, and maintainer discontent at having to fix affected projects in the Real World Code (RWC) test suite. I'm willing to pay such costs for things that reduce our maintenance burden like dropping deprecated non-Standard features, but redundantly specifying template arguments that would have been deduced imposes no real costs on us and isn't directly harmful to users (the harm is more abstract, and "what if the Standard changes", etc.). Also, having to identify whether an explicit template argument is different from what would have been deduced, i.e. performing conversions from the function arguments, is an extra twist for cleaning up code.

I am inclined to resolve this as "meh" but I'll leave it open.