[Review] Klemens Condition 4

[mborland]

Provide algorithms as free functions

[correaa]

Klemens said:

I don't like the algorithms (diagonal, slice`, etc.) being members.
I prefer them as free functions in old-school fashion like so:

auto slice(array_ref<T, N> &, size_t first, size_t last)

Or

array_ref<T, N-1> diagonal(array_ref<T, N>);

For those who fance daisy-chains a std::ranges compatible API could be
provided.

I wouldn't call them algorithms, since no data that is manipulated for this.

All other things being equal, yes, I would prefer free functions.
BUT, not all other things are equal.

These functions can't be pure free functions because they do manipulations of the internal layout, that otherwise I would need to expose. And since these functions would need to be friends anyway, I would say I preferred them to be members, not not add more indirection.

I decided to keep the member function because it daisy chains better.
(For example arr.strided(2).diagonal() jumps through the array like a knight in chess.)

The same logic applies to .sliced. Plus that there is the purely syntactic issue of "visual" unbalance.
Consider arr.sliced(3, 5); versus multi::slice(arr, 3, 5);. The first flows better because arr and 3, 5 are at a "different level".

Daisy chaining with operator| was not investigated to avoid early clashes with std::ranges, which can already have similar functionality, although with slight different semantics. In other words, the 1D views are already covered by std::ranges, nothing prevents us from doing arr | std::views::drop(2) | std::views::take(4);.

While it is not clear if this should apply to inherently to non-one dimensional interpretation (for example arr | multi::diagonal). Reasoning is that | is historically interpreted as a "pipe" in which something is operated sequentially. In the future, this can be allowed if the community interprets that this is a good use of what "pipe" means. Diagonal makes a lot of assumptions about the "range" arr.

I could provide this functions as members and as free functions (in which case I have to decide between hidden friend, free friend, or CPO (function objects).
I once provided both an early reviewer complained that there were too many ways to do the same thing, so I stick with members.