I think the discussion on the decimal went in the wrong direction and is it probably my own fault. Lets start it over in more general terms. My view on decimal types are that they can be based on 4 different base types 1. binary floating-point, explicit rounding 2. decimal floating-point, explicit rounding 3. decimal fixed-precision, global rounding 4. decimal fixed-precision, object rounding * Explicit rounding means that all operations store the full precision supported by the type. Rounding to a number of decimals is performed when needed by a (maybe implicit) call to a function like round(x, rounding_mode). Ofcourse there is a rounding mode used to fit the result of an operation into the type which might cause rounding errors (e.g. 0.499999 might first be rounded to 0.5000 to fit the type which is then explicitly rounded to 1). I think the cases where the double rounding is a problem are so rare that it is enough to point out the problem in the documentation. * global rounding means the same rounding is used for all objects. * object rounding means that the rounding is specified for each object. The decimal type I proposed was in category 4. The proposed TR decimal type is category 2 and it might also support type 3. Float, double is category 1. --- The discussion on decimal types, including the review of a decimal library two years ago, indicates that to be accepted in boost a solution should allow some (or all 4) types to be used as base in something like "basic_decimal<>". So lets discuss how a basic_decimal interface should look like. The main problem I see lies in the construction: Type 1 & 2: basic_decimal(value) Type 3: basic_decimal(value, precision) Type 4: basic_decimal(value, precision, rounding_mode) Rounding is not a big problem since a sensible default can be used but how to solve the precision? Creating a decimal type 3 or 4 without specifying a precision is bad since there is no good value to use as default. Precision also has a different meaning for a decimal type 1 & 2 (i.e. only affects extractions, not operations). I see three possible solutions: 1. basic_decimal include all variants of constructors and then generates compiler error if that type of constructor isn't suitable for the underlying type 2. basic_decimal only got the "full" constructor (value, precision, rounding_mode) but supplies default for precision (=0?) and rounding mode 3. basic_decimal only includes the minimal constructor (value) and then other members are needed to specify precision and rounding_mode for type 3 & 4 decimals. The other members of basic_decimal isn't very complicated: A full set of arithmetic operations (+,-,*,/,%) and assignment must be included. Operations should work on integers and maybe also string literals. For decimal type 1 & 2 it makes sense to also allow operations on doubles. Assignment should work on integers, string literals and double for all types. There needs to be a way to extract the decimal as a binary floating point value and probably also a decimal floating point value (when available). Functions like round, abs etc are also needed but they can be free functions (maybe friends for performace reasons). Note that the above only deals with the decimal type. Money and currency might need a slightly different interface. My view is that the types should built up like: typedef basic_decimal<value_type> decimal_type; typedef basic_money<decimal_type> money_type; typedef basic_currency<money_type> currency_type; Any comments?