This discussion is also on github.

**Please**, share what you would like to see added to the next release of nalgebra (in particular for computer-graphics related features)!

After #187, the next release will be the next big step toward what will be a version 1.0 in the future. It will include many breaking changes (especially for generic programming) but this is the last time it will break that much!

This trait reform is also a good opportunity to reorganize the internals of nalgebra, get rid of some hidden aberrations (like the ability to change the `Rotation2`

diagonal to arbitrary values), and take in account negative feedbacks (I actually read IRC logs) regarding its ergonomy for computer graphics applications.

The main goals are to:

- allow generic programming through solid trait-based mathematical foundations. The current traits are too granular and not organized (with inheritance) in a coherent manner.
- use the approx crate for approximate equality testing (i.e. don’t redefine our own).
- add computer-graphics-related features to 3x3 and 4x4 raw matrices. The computer graphics community is used to work with 4x4 matrix to represent a general 3D transformation (or 3x3 matrices for 2D). Thus, people are usually frustrated when they can’t do anything CG-related with
`Matrix3`

and`Matrix4`

. This will change but they will still not be usable in a generic context (except for one case, see bellow).

# Generic programming

The new trait hierarchy will:

- mostly be implemented in a separate crate: alga. Note that this is based on the excellent work of @brendanzab and @WaDelma on algebra (I wanted to give a fresh reboot of this library with different design choices).
- follow more strict mathematical notions and names. If several names are possible for the same structure, the simpler one is chosen (e.g. trait for rotations will be called
`Rotation`

instead of`SpecialOrthogonalGroup`

). - provide the same (or more) features that already exist on
`nalgebra`

. You’ll just have to change the name of the traits you import, and sometimes the methods names as well. For example the`SquareMatrix`

,`Diagonal`

,`Column`

, and`Row`

will be merged into the traits`SquareMatrix`

and`SquareMatrixMut`

(the latter allows modifications).

Implementing your own instance of the traits of `alga`

will be a bit harder as you’ll have to

select the right stack of algebraic structures starting with the most basic one (the `Magma`

). On this other hand, this will force you to be sure that your type has the correct algebraic properties that generic code will rely on. Convenient macros might be added in future versions of `alga`

to make this easier.

Right after the release, a small guide will be provided to help you update your code without having to search too much what is moved under which trait.

# Computer Graphics features

It will be possible to:

- build a projection/look-at/rotation/translation/scaling
`Matrix3/4`

directy using dedicated

constructors like`Matrix3::new_translation`

. - append/prepend a rotation/translation/scaling to
`Matrix3/4`

. - transform a
`Point2/3`

or a`Vector2/3`

using a`Matrix3/4`

. The transformations will

implicitly follow the rules of projective geometry (i.e. homogeneous coordinates). A

`Transformation`

trait will be the only one implemented by those matrices. Transformation will

also work by simple multiplication. - convert a
`Rotation2/3`

,`Isometry2/3`

and`Similarity2/3`

using the`na::cast`

function (which will be renamed`na::convert`

). Users won’t have to use the`to_homogeneous`

and`from_homegenous`

if they are disturbed by the mathematical names. Under certain strict conditions checked at runtime, the inverse conversion (e.g. from`Matrix3`

to`Rotation2`

) will be possible (and will return`None`

if it fails). - multiply a
`Matrix3/4`

with a`Rotation/Isometry/Similarity`

.

Most free functions at the root of the crate will be unchanged (except for the trait bounds of their arguments).

# Fixed issues

The following issues will be fixed: #205 , #200, #160, #145, #137, #36, and #32.

I have been working on this during the past couple of months and think I am halfway.

Before the release, I’ll also update kiss3d, ncollide, and nphysics in order to have a taste (and fix flaws) of the new design in extremely generic code.