Andrei's list of barriers to D adoption

[Observer via Digitalmars-d]

On Monday, 6 June 2016 at 18:55:22 UTC, Ola Fosheim Grøstad wrote:
> On Monday, 6 June 2016 at 18:36:37 UTC, Observer wrote:
>> It's more complicated than that.  Part of what you need is to
>> be able to declare a variable as (say) having two significant
>> fractional digits, and have the rounding rules be implicitly
>> applied when saving to that variable, producing an exact
>> representation of the rounded result in storage.
>
> Yes, but if you want accurate representation of two fractional 
> digits on storage only, then it makes most sense to do all 
> calculations on cents (scale everything by 100) and store as 
> integers.

That's only a workaround.  It's probably best to think of decimal
arithmetic as an accountant would, not as a computer geek would.
Intermediate arithmetic results should perhaps also be rounded/
truncated, though it depends on the particular calculation.  For
instance, I might have an interest percentage that gets carried
to 4 sig figs (fractional digits), but when applied to a currency
amount with only 2 sig figs, the result should end up with 2 sig
figs, not 6.  And then that result should continue to be used in
later arithmetic in the same larger expression, even without an
explicit save operation to invoke the rounding/truncation.  If
you tried this using float for the percentage and integer for
the amount, once the conversion to float happened it would not
revert in the middle of the expression.

Also, keeping values as only integers complicates input/output
formatting.  I want 123456 pennies to show up as either 1234.56
or perhaps 1,234.56 (at least, I want that punctuation in a U.S.
locale), and this should happen without my needing to manually
rescale during i/o operations.