Explicit template argument barrier for algorithms that are function templates

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?

Start by reading the referenced WG21-P0896R4 and LWG-3419 material, then inspect the affected standard-library algorithms mentioned in the issue, including midpoint, construct_at, gcd, and saturating_add. Done requires a maintainer decision on whether to introduce the barrier and a defined scope for the affected declarations; no implementation files or tests are named.