Two conversion operators implemented together in struct tuple from namespace oneapi::dpl::__internal

[SergeyKopienko]

Based on #2013 and comment #2013 (comment)
looks like we have problem in the code

oneDPL/include/oneapi/dpl/pstl/tuple_impl.h

Line 457 in 9a1dada

operator ::std::tuple<U1, U...>() const

:

• we may have the problem that implemented two conversion operators together:

    // conversion to ::std::tuple with the same template arguments
    operator ::std::tuple<T1, T...>() const
    {
        static constexpr ::std::size_t __tuple_size = sizeof...(T) + 1;
        return to_std_tuple(*this, ::std::make_index_sequence<__tuple_size>());
    }

    // conversion to ::std::tuple with the different template arguments
    template <typename U1, typename... U>
    operator ::std::tuple<U1, U...>() const
    {
        constexpr ::std::size_t __tuple_size = sizeof...(T) + 1;
        return to_std_tuple(static_cast<tuple<U1, U...>>(*this), ::std::make_index_sequence<__tuple_size>());
    }

[akukanov]

Do the two conversion operators cause a problem per se? Seems that the first one is in a sense "more specialized" than the second one. If there is no ambiguity when the conversion to the standard tuple of the same types (T1, T...) is needed, then the operators do not conflict.

We can consider whether the second, more generic definition is sufficient alone and the first one is really excessive. But it would still enable the same set of conversions.

Meanwhile, the error with the ternary operator in #2013 says about our internal tuple and the standard tuple being mutually convertible:

/include/oneapi/dpl/pstl/hetero/dpcpp/parallel_backend_sycl_merge.h:162:17: error: conditional expression is ambiguous; '__return_t' (aka 'const oneapi::dpl::__internal::tuple<unsigned long, unsigned long>') can be converted to 'decltype(this->make_reference(::std::declval<_tuple_ranges_t>(), __i, ::std::make_index_sequence<__num_ranges>()))' (aka 'tuple<const unsigned long &, const unsigned long &>') and vice versa

And this is of course deliberate, we do want conversions to/from the standard tuple.