Return types of logical_and and logical_or don't match ISO C++

[Pennycook]

SYCL defines these function objects as:

template <typename T = void> struct logical_and {
  T operator()(const T& x, const T& y) const;
};

template <typename T = void> struct logical_or {
  T operator()(const T& x, const T& y) const;
};

Whereas ISO C++ defines them both as returning bool. bool makes a lot more sense to me than T, because the operators are defined as returning x && y and x || y.

I suspect this is a bug that arose from copying and pasting other function object definitions, but before writing up the fix I wanted to check whether anybody knew of a reason that things should be defined this way.

[TApplencourt]

Agree.

Do we need to be carefull with vec / marry

Logical and comparison operators for marray class template return marray<bool, NumElements>.

or it will be cover by https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#sec:marray.type tranciantly?

[Pennycook]

Do we need to be carefull with vec / marry

I think the void specialization (i.e., sycl::logical_and) will do the right thing, because that returns auto, but that's not obvious from the specification as written.

Maybe the thing to do is convert the whole of Section 4.17.1 to the new style, and explicitly add the necessary specialization:

template <typename T = void>
struct logical_and {
  bool operator()(const T& x, const T& y) const;
};

template <>
struct logical_and<void> {
  template <class T, class U>
  constexpr auto operator()(T&& t, U&& u) const -> decltype(std::forward<T>(t) && std::forward<U>(u));
};

We could add explicit overloads for marray and vec, but I'm inclined not to. If we encourage people to just call logical_and<> instead, it will always do the right thing, and it will allow implementations to implement sycl::logical_and as a simple alias of std::logical_and.

[nliber]

I agree with @Pennycook that returning T was probably just a bug.

We also shouldn't add explicit overloads for marray and vec. Users already have to be careful when using logical_and (both in std:: and sycl::) because unlike the expression x && y, logical_and<...>()(x, y) always evaluates y. Doing what std::logical_and does is the least surprising thing we can do.