I just took a quick look at the repo, where the important code seems to be
https://github.com/BobSteagall/wg21/blob/master/linear_algebra/code/alt_test.cpp

I think it would be useful to write some tests that
(A) verify that expressions are not only well-formed but also have the
correct results (e.g.
https://github.com/BobSteagall/wg21/blob/cb69e22fd0/linear_algebra/code/alt_test.cpp#L31
should probably go on to static_assert(b001) or static_assert(not b001)
depending on your intent).
(B) verify that some compound expressions such as `M1 + (M2 * M3)` are
well-formed, and also that they have the correct results
(C) include benchmarks of speed, especially for interesting compound
expressions (I'm sure the authors of P1417R0 can give you some interesting
expressions which come up frequently in real applications)
(D) include benchmarks of memory usage, especially for interesting compound
expressions. This is particularly important IMHO because it'll force you to
"design for testability" in this area: if you can tell how much memory is
being used by materialized temporaries, then you can also tell me how to
use a std::pmr::memory_resource to supply memory to this library, and you
can tell me if some innocuous-looking expression is going to blow my stack
segment, and so on.

More pie-in-the-sky-ish, I would recommend writing test templates in terms
of WhateverMatrix<T> and then instantiating those test templates with
T=double, T=ThinWrapperAroundDouble, and so on. (Testing with
ThinWrapperAroundDouble is my attempt to test the optimizability of the
actual library code, independent of any special-case specializations it
might have for the concrete type `double`.)

HTH,
–Arthur


On Fri, Feb 8, 2019 at 5:25 AM Jayesh Badwaik <badwaik.jayesh_at_[hidden]>
wrote:

> Are we okay with just `auto` return types? These require definition to
> precede usage leading to intractable cycles.
>
> I suggest that we start putting return types (at least trailing ones)
> everywhere. Keeping a track of return types at very stage would make
> other things like keeping track of copies easier. It will also point
> out issues with things like perfect forwarding that might require
> change in signatures otherwise.
>
>
> --
> Best
> Jayesh
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> http://lists.isocpp.org/mailman/listinfo.cgi/sg14
>