On Sunday, 14 June 2015 at 11:43:46 UTC, Ilya Yaroshenko wrote:
I am really don't understand what you mean with "generic"
keyword.
Do you want one matrix type that includes all cases???
I hope you does not.
Yes, that is what generic programming is about. The type should
signify the semantics, not exact representation.
Then you alias common types "float4x4" etc.
It does take a lot of abstraction design work. I've done some of
it in C++ for sliced views over memory and arrays and I'd say you
need many iterations to get it right.
If not, yes it should be generic like all other Phobos. But we
will have one module for 3D/4D geometric and 3D/4D
matrix/vector multiplications, another module for general
matrix (std.container.matrix) and another module with generic
BLAS (std.numeric.blas) for general purpose matrixes. After all
of that we can think about scripting like "m0 = m1*v*m2"
features.
All I can say is that I have a strong incentive to avoid using
Phobos features if D does not automatically utilize the best
OS/CPU vendor provided libraries in a portable manner and with
easy-to-read high level abstractions.
D's strength compared to C++/Rust is that D can evolve to be
easier to use than those languages. C++/Rust are hard to use by
nature. But usability takes a lot of API design effort, so it
won't come easy.
D's strength compared to Go is that it can better take advantage
of hardware and provide better library abstractions, Go appears
to deliberately avoid it. They probably want to stay nimble with
very limited hardware-interfacing so that you can easily move it
around in the cloud.
