Use associated constants where applicable

[milibopp]

Since rust-lang/rust#23606 has been merged now on the unstable branch, we can start experimenting with associated constants in this crate. This should most likely not be merged into the master branch right away, as it will only work on the nightlies. Also it will be a breaking change naturally.

Of course, this raises the question, how we want to deal with unstable features in general. Thoughts?

[sebcrozet]

Will associated constant be part of the 1.0 release? For the time being, I'd prefer to wait until the stable compiler is shipped (next week IIRC) so that we have a clear view of what could end up on the master branch or not.

In the future, I believe we could maintain a second major development branch (the first one being "master") called, say, "nightly" or "unstable" that compiles using the nightly version of the rust compiler.
Though I wonder if we might not end up with too many divergences between the two branches that would make them unmergeable at the time of the next compiler release (e.g. if the 1.0 compiler still ICEs with associated types while the nightly doesn't, we would have a hard time adding new features that would comply to both traits using and not using associated types) .

[milibopp]

They will definitely not be on the 1.0 release. btw, I also realized that associated constants don't quite work yet, as I tried to make the Dim trait use them. (Too many ICEs.)

Anyway, it might be sensible to try this two-branch approach. But I'd be hesitant to do this, unless we actually use many unstable features at once. For isolated issues such as this it might make sense to just maintain feature branches and keep them up-to-date as the master branch evolves, until the underlying features get stabilized and they can finally be merged.

[milibopp]

Two years later, given that associated constants are still in the process of being stabilized, I am closing this for now. Anyway, with the advent of associated_consts and maybe later const_generics it might probably make sense to redesign the entire library from scratch, as at least the latter would make typenum pretty obsolete. However, this is probably not going to be stable for a long time.