1. If a user is not familiar with the library to such an extend that he doesn't
know that auto should be avoided, how can we expect him to be aware of plain?
Therefore the advantage I see is to provide a way to avoid verbose syntax for
users that are aware of the auto problem.
yes, of course. I was just thinking that maybe it could be easier to teach than .eval() as this make the code cleaner.
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:
As a side note, yes we should add deduction guides for Array,Matrix,SparseMatrix
from expressions, but that's another topic.
There are a lot of awesome things possible if we enable C++17 (or even C++14)
functionality and I'm sure we should allow some of them some day. However, using
a deduction guide for this case could be problematic since there could be existing code
around that uses auto knowing that the result will be an _expression_.
I was thinking about:
Matrix M = ...;
SparseMatrix S = ...;
Array A = ...;
with "..." any compatible expressions. Those would also be welcome alternatives to "auto" when you know that you are dealing with dense matrices only or sparse matrices only, whereas "plain" is more general and could even wrap scalars for generic array/scalar functions.
cheers,
Gaël.
Cheers,
DT