deadalnix:
Aren't supposed to go away at some point ?
I have never read an official statement of them going away, and I'd like the cent/ucent types. On the other hand Andrei has instead suggested to introduce a fixnum struct in Phobos, that is able to replace a "cent" in many cases (I don't know if he wants to replace ucent too): alias cent = Fixnum!128; Maybe such Fixnum risks being less efficient than a cent (unless its operations get fully inlined, and this is quite possible if it's a struct). If there isn't a perfect inlining, then there is some lost performance. A D compiler performs optimizations on built-in integral numbers based on the mathematical properties of such numbers. Maybe a way to remove or reduce that lost inefficiency with a user-defined integral struct value like Fixnum is to introduce in D annotations like @commutative and @associativity that applied to such struct definition allows the compiler to perform some integral-related optimizations. The compiler is not able to enforce that annotations like @commutative are actually correct for the user code. A more "big guns" approach is something like the Axioms that weren't added to C++11, this is a quite interesting article: http://akrzemi1.wordpress.com/2012/01/11/concept-axioms-what-for/ axioms allow you to write a concept for integers-like numbers, usable for a Fixnum, that later the compiler is able to use to perform those optimizations: concept IntegerLike<typename T> : CopyConstructible<T> { T::T( int ); T operator*( T, T ); axiom Commutativity( T x, T y ) { x * y <=> y * x; } axiom Associativity( T x, T y, T z ) { (x * y) * z <=> x * (y * z); } axiom ValuePropagation( int x, int y ) { T(x) * T(y) <=> T(x * y); } } The advantage of @commutative and @associativity is that they are probably simpler to implement. The disadvantage is that concept+axiom is much more flexible, allowing you to model other algebraic properties. Bye, bearophile
