I'm reading your proposal right now. You have some very specific
ideas about how to change (evolve) the fundamental type system in
Boost.uBLAS. Do you have experience with an API that uses that
approach, and which can be used to validate it ?
There are many aspects of what I'm reading that I really like. I
have questions about some others. So before I dive into the details,
I wonder whether you can refer to any such project (ideally with
documentation :-) ) where I might find answers to these questions.
Note that I co-designed a library (http://openvsip.org/) with
somewhat similar goals (and the API to which is now standardized at
the OMG: https://www.omg.org/spec/VSIPL++/About-VSIPL++/), so it
would be interesting to compare the different design choices. (And
there of course other libraries with similar goals, such as Eigen
(http://eigen.tuxfamily.org) and many others.)
And on a more practical note: Do you have any path in mind for
migrating from the existing implementation to a future one that uses
your design ? I'm concerned that what you are really proposing is a
full-scale replacement of Boost.uBLAS by something new, which is not
only way too ambitious a task for a single GSoC project, but might
actually require a full Boost review as a new library addition.
All that being said, I'm actually very sympathetic to your proposal.
I don't want to discourage you, but need to understand how this may
work out for everyone involved. (Feel free to follow up in private
if you prefer.)