Re: [eigen] On a flexible API for submatrices, slicing, indexing, maskin

Still I'd say that changing the case to avoid a name collision is against most sane coding conventions, especially when the particular coding convention uses case to differentiate between the type of the name.

To tell you the truth, I don't feel comfortable in introducing a "Size" function.... it's just that the respective size/length/count/etc. property should be accessible through a 'size' function for consistency, and thus it feels odd not to call the respective argument 'size/Size'. I would thus rather try to make the option (A) below works out...

Some more ideas for option (A). Suppose we define xxx(first, last, incr). Suffix it with "n" or "N" for the version that takes in (first, len, incr). Examples:

seq(3, 3+n-1, 2) <-> seqn(3, n, 2) or seqN(3, n, 2) or seq_n(3, n, 2) (more STL like)

Likewise:

aseq(3, 3+n-1, 2) <-> aseqn(3, n, 2) or aseqN(3, n, 2)

aprog(3, 3+n-1, 2) <-> aprogn(3, n, 2) or aprogN(a, n, 2)

ap(3, 3+n-1, 2) <-> apn(3, n, 2) or apN(a, n, 2)

The letter "n" serves as a mnemonic for length. This way, we don't have to remember which is the bounded version and which is sized version. The C++ standard library sets the precedents with its "_n" suffixed algorithms, e.g., copy vs copy_n, find vs find_n. A single undercase "n" as a suffix doesn't work too well for longer word like "span" or "range" though.

Btw, I found more examples of arithmetic sequence in other languages:

- R: seq(start, stop, incr).

- Julia: range(start, [incr,] length), colon(start, [incr,] stop)

- Swift: stride(start, stop, incr)

So at this stage of the discutions, if we could find a good name for a generic Zzzz<N>, then I would lean for option (A).

Just to throw around some:

Static<V>,
CompileTime<V>

this makes me thought about a simple:

Fixed<V>

This and the shorter "Fix" are both nice. I still prefer the all lower case version though, since it's a function and there's no name collision.

I also want to revisit the ordering of first, last, and the (optional) incr parameters. We have these existing conventions:

- Matlab/Julia: (first, [incr,] last)

- Numpy: (first, end [, incr]), and also indices can be negative numbers

Our current choice is (first, last [,step]).

As you can see, it matches neither. I fail to see a good reason why we shouldn't just adopt Matlab's convention of (first, incr, last), similar to libigl's colon(), so that there's one few set of convention to remember. Of course, to do that we need to explicitly overload a seq(first, last) and a seq(first, incr, last), instead of relying on C++'s default parameter, but that's a small implementation detail.

Our current convention actually corresponds to the Fortran convention, so it's not without merit. But subjectively, I feel there's a much higher chance for people to prototype in Matlab or Numpy and then port to Eigen, as opposed to going from Fortran to Eigen. Of course, people with more experiences on the matter may want to chime in and disagree.