TL:DR Have a tuple equivalent of the | for std ranges

Hello, it would be great if kumi would support the CUDA __host__ __device__`` specifiers as an opt-in feature under the KUMI_ENABLE_CUDA_SUPPORT` CMake option.
Won't mind if I propose a PR with this feature?

Thanks in advance.

Roughly

template<product_type S1, sized_product_type<S1::size()> S2, typename T>
  constexpr auto inner_product(S1 const& s1, S2 const& s2, T init) noexcept
  {
    if constexpr(sized_product_type<S1,0>) return init;
    else
    {
      return [&]<std::size_t... I>(std::index_sequence<I...>)
      {
        return (init + ... + (get<I>(s1) * get<I>(s2)));
      }(std::make_index_sequence<size<S1>::value>());
    }
  }

See: https://godbolt.org/z/qxbEj3nzs
From: https://discord.com/channels/400588936151433218/400588936151433220/969803423438475304

Helpers for kumi tuple.

This should replace max_scalar_size_v in eve

Those are trivial to implements and can be better than using cat when just wanting to insert one value

Consider instead of, always/for all cases, going through all the foldable machinery create predefined functions for the standard/language-builtin fold ops, so that e.g. numel could be:

template <typename Tuple>
auto kumi::fold_mul( Tuple && T, auto const initValue )
{
      return [&]<std::size_t... I>(std::index_sequence<I...>)
      {
        return (initValue * ... * get<I>(KUMI_FWD(t));
      }(std::make_index_sequence<size<Tuple>::value>());
}

(of course put the above in a macro which only accepts the op as a parameter and such define the fold for all the ops:
KUMI_FOLD_IMPL_FOR( *, mul )
KUMI_FOLD_IMPL_FOR( +, add )
...

then

    constexpr std::int32_t numel() const noexcept
    {
      if constexpr(static_order == 0) return 0;
      else return kumi::fold_mul(*this, std::int32_t{1});
    }

Working prototype:

https://godbolt.org/z/nPGWEPa4E

Describe the bug
kumi::cat's resulting tuple type contains elements which have their cv-ref qualifiers removed. This differs from the STL where cv-ref qualifiers are preserved

To Reproduce
See the following godbolt example. Example contains comparison with the STL behavior.

Expected behavior
The elements of the resulting tuple from kumi::cat should match that of std::tuple_cat

Additional context
In my implementation, I compute the resulting tuple type in a similar way to fetching the elements themselves, except using nesting std::tuple_element_t instead of std::get. Should be relatively straight forward as you can reuse the same pre-computed indices.

Example: https://godbolt.org/z/6zKxGGe4j

Describe the bug

/home/higepi/stage/kiwaku/test/algorithms/find.cpp:58:22: note: in instantiation of function template specialization 'kumi::iota<4UL, int>' requested here
  auto vdata = kumi::iota<4>(1);
                     ^
In file included from /home/higepi/stage/kiwaku/test/algorithms/find.cpp:9:
In file included from /home/higepi/stage/kiwaku/include/kwk/algorithm/find.hpp:10:
In file included from /home/higepi/stage/kiwaku/include/kwk/concepts/container.hpp:13:
In file included from /home/higepi/stage/kiwaku/include/kwk/settings/size.hpp:10:
In file included from /home/higepi/stage/kiwaku/include/kwk/utility/container/shape.hpp:12:
/home/higepi/stage/kiwaku/include/kwk/detail/kumi.hpp:1098:28: error: implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion]
      return kumi::tuple{T(v+I)...};
                           ^~
/home/higepi/stage/kiwaku/include/kwk/detail/kumi.hpp:1098:28: error: implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion]
      return kumi::tuple{T(v+I)...};
                           ^~
/home/higepi/stage/kiwaku/include/kwk/detail/kumi.hpp:1098:28: error: implicit conversion changes signedness: 'int' to 'unsigned long' [-Werror,-Wsign-conversion]
      return kumi::tuple{T(v+I)...};

To Reproduce
auto vdata = kumi::iota<4>(1);

Expected behavior
Iota must compile without warning

Got hit by this, was annoying.

eve fails with:

/home/falcou/infra/tindalos-2/_work/eve/eve/test/unit/api/udt/comparison.cpp:60:55: error: C++20 says that these are ambiguous, even though the second is reversed: [-Werror]
   60 |   lp_t checks = [&](auto i, auto) { return lhs.get(i) != rhs.get(i); };
      |                                            ~~~~~~~~~~~^~~~~~~~~~~~~
/home/falcou/infra/tindalos-2/_work/eve/eve/include/eve/detail/kumi.hpp:344:27: note: candidate 1: ‘constexpr auto kumi::operator!=(const tuple<Ts>&, const Other&) requires  sizeof ... (Ts ...) != 0 && (equality_comparable<kumi::tuple<Ts ...>, Other>) [with Other = udt::label_position; Ts = {float, unsigned char}]’
  344 |     friend constexpr auto operator!=(tuple const &self, Other const &other) noexcept
      |                           ^~~~~~~~
/home/falcou/infra/tindalos-2/_work/eve/eve/include/eve/detail/kumi.hpp:327:27: note: candidate 2: ‘constexpr auto kumi::operator==(const tuple<Ts>&, const Other&) requires  sizeof ... (Ts ...) != 0 && (equality_comparable<kumi::tuple<Ts ...>, Other>) [with Other = udt::label_position; Ts = {float, unsigned char}]’ (reversed)
  327 |     friend constexpr auto operator==(tuple const &self, Other const &other) noexcept
      |                           ^~~~~~~~
cc1plus: all warnings being treated as errors

  template<product_type Tuple>
  [[nodiscard]] constexpr decltype(auto) back(Tuple&& t) noexcept
  {
    return get<std::tuple_size<std::remove_cvref_t<Tuple>>::value - 1>(KUMI_FWD(t));
  }

os something

reserse will be a good idea or reverse_apply

Describe the bug

depending on how cat is meant to work, i think there might be two problems at: https://github.com/jfalcou/kumi/blob/main/include/kumi/algorithm/cat.hpp#L63-L68

need to forward tuples into the inner get to ensure rvalue-refs elements of rvalue tuples are rvalue-ref elements of catted tuple, and then also need to make element-type computation of catted tuple a bit more refined:

if the source-element-type is not a reference, can use: std::tuple_element_t
else: decltype(get<pos.e[N]>(get<pos.t[N]>(KUMI_FWD(tuples))))

As per: https://godbolt.org/z/MP3P3qhYc

A bunch of the std library language around tuple has changed, I think specifically to support std::tuple proxy value/reference types for std::views::zip. Many of these changes are in p2321.

I ran into this in this example of using a kumi::tie as a reference tuple type for an SoA iterator, and trying to use std::ranges::sort on the range. https://godbolt.org/z/9bYb1oM8z.

Currently the first compiler error I run into is the following common_reference failure, which I guess requires specializing basic_common_reference, however there could be more problems hidden behind this one.

/opt/compiler-explorer/clang-16.0.0/bin/../include/c++/v1/__type_traits/common_reference.h:113:1: note: because substituted constraint expression is ill-formed: no type named 'type' in 'std::common_reference<kumi::tuple<unsigned int &, unsigned char &, unsigned int &> &&, kumi::tuple<unsigned int, unsigned char, unsigned int> &>'
using common_reference_t = typename common_reference<_Types...>::type;
^
1 error generated.

edit: punctuation

Is your feature request related to a problem? Please describe.

I think now that Kumi is its own repository, it might make some sense to change the structure from include/kumi.hpp to include/kumi/tuple.hpp. This would allow users to #include <kumi/tuple.hpp> which is a lot easier to understand for new programmers that aren't familiar with what kumi.hpp might mean.

Is your feature request related to a problem? Please describe.
When I have tuples of references it makes sense to map them without returning anything. Currently providing an invocable that returns void results in a compilation error.

Describe the solution you'd like
Specialize on the return type of the function object, if void then don't try and produce a tuple.

Describe alternatives you've considered
The current workaround is to return something trivial, like 0.

Additional context
https://godbolt.org/z/b56T3ebjd

based on the work done on EVE, make kumi cmake a bit more modern & correct.

There are cases when you need an index of the element.
Can we have a version of map and others, that also pass an index of the current element to the lambda?

1. Was looking for kumi::reduce. There was none. Took some time to figure it's fold_left/fold_right.
2. They require init. I don't have one. You don't need init if you tuple is not empty - let's have no init overloads.

Also balanced reduction can be awfully nice! (fold_balanced?)
Smth like: https://github.com/jfalcou/eve/blob/d75ab0f23e472bfe04f406aeb5b7e0e90671a574/include/eve/module/algo/algo/array_utils.hpp#L54-L58