Re: [eigen] "plain": a new keyword for auto with implicit evaluation

[Patrik Huber <patrikhuber@xxxxxxxxx>]

Hello,

I must say that I am not convinced that something like

>> plain C = A * b;

is easier to understand for a beginner than

>> auto C = (A*B).eval();

. It introduces a new type and it also rather looks like a keyword in that context (particularly since all Eigen types start with upper-case letters), and it might add more complexity/confusion.. Maybe it's just the name "plain" that is bad, perhaps we could find something better, along the likes of "PlainObject" or something like that, but that's also not too obvious yet to a beginner, and I don't have a good idea for that name.

I do quite like the idea of the "deduction guides" of

Matrix M = ...;

SparseMatrix S = ...;

Array A = ...;

though, so perhaps that's what you're looking for to eliminate the need for .eval() for beginners. 

And then for generic code you could still have "PlainObject" or something like that, but just don't teach that to beginners in the documentation.

>> we could then decide if, e.g., Eigen 4 supports C++11 and someC++14/17/20 features.

Just my two cents, might be a bit off-topic here, but in my opinion it would be a real back-step if the "hypothetical" Eigen 4 was stuck on C++11. I would very strongly argue to at least make the step to full C++14 and potentially C++17 (I think there was some memory-alignment keywords in either C++14 or 17 which would make EIGEN_MAKE_ALIGNED_OPERATOR_NEW unnecessary and that would be a *really* big win imho).

I would actually love to see Eigen 3 moving to C++14... ;-)

Best wishes,

Patrik

On Mon, 18 Feb 2019 at 13:43, David Tellenbach <david.tellenbach@xxxxxxxxxxxxx> wrote:

Hello,

I was thinking about:

Matrix M = ...;

SparseMatrix S = ...;

Array A = ...;

Ah, I see! I think something like this would be really great. The STL follows a similar 

approach by providing deduction guides for standard containers such that something

like

std::array {1, 2, 3, 4);

works now.

2. Using plain (using the implementation you provided) can have performance

penalties in the case of object slicing: Object slicing prevents copy elision!

If the following paper gets into C++20, then we could define "plain" as an alias template:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1021r2.html

Regarding this C++20 approach or a C++17 approach, I think we should start discussing

how and to what extend Eigen wants to allow functionality provided by newer standards. 

Officially we support C++03 and to some limited extend C++11. If we add additional functionality

code and documentation get more and more complicated (this feature is available using C++11,

that one using C++14 and this one using C++20).

How about some sort of collection of features we would like to see in newer versions of Eigen?

Based on something like this we could then decide if, e.g., Eigen 4 supports C++11 and some

C++14/17/20 features.

Cheers,

DT