soa_vector maybe shouldn't use get set members.

[DenisYaroshevskiy]

Why?

Because of confusion with non-member get.
Also we have the same confusion with wide...

We can have get_at or set_at for example? Or smth.

Explanation:

Assume:

point2D - product over <int, int>
line2D - product ove <point2D, point2D>.

decltype(auto) start(eve::same_value<line2D> auto&& self) { return get<0>(EVE_FWD(self));
decltype(auto) end  (eve::same_value<line2D> auto&& self) { return get<1>(EVE_FWD(self));

On one hand, would be nice to be able:

std::ptrdiff_t count_starting_at_zero(soa_vector<line2D> const& v)
{
   return eve::algo::count(start(v), point2D{0, 0});
}

However, providing get<0> get<1>` on soa_vector is problemating.
Consider structure bindings:

NOT DOABLE:

foo(soa_vector<line2D> const& lines)
auto& [starts, ends] = lines;

We can't do that. Because structured bindings needs real references, and inside soa_vector we won't store anything reminding us of point.
Ideally, at some point, we would just store a pointer to one allocated chunk of memory that's it.

So non-member get on soa_vector won't fly,

BUT:

I think we should have an soa_view<T> (or smth).

And there I think we should store the extra wrappers that'd allow us to reference directly some parts.

I think this should be OK:

 foo(eve::soa_vector<line2D> const& lines)
 {
    eve::soa_view view{lines};
    auto& [starts, ends] = view;
    // decltype(starts) is soa_view<point>

So this kind of soa_view needs to have a get<0>(soa_view) and also needs to have the same interface as soa_vector => view.get(3) -> line.

[DenisYaroshevskiy]

Decided that it's fine