good reasons not to use D?

[rumbu via Digitalmars-d-learn]

On Saturday, 31 October 2015 at 20:55:33 UTC, David Nadlinger 
wrote:
> On Saturday, 31 October 2015 at 18:23:43 UTC, rumbu wrote:
>> My opinion is that a decimal data type must be builtin in any 
>> modern language, not implemented as a library.
>
> "must be builtin in any modern language" – which modern 
> languages actually have decimals as a built-in type, and what 
> is your rationale against having them as a solid library 
> implementation? It seems like it would only be interesting for 
> a very fringe sector of users (finance, and only the part of it 
> that actually deals with accounting).
>
>  — David

C# - built-in decimal data type 128 bit (96 bit significand + 32 
bit sign and scale) - 
https://msdn.microsoft.com/en-us/library/364x0z75.aspx
GNU C - 3 built-in decimal data types - 
https://gcc.gnu.org/onlinedocs/gcc/Decimal-Float.html

Besides that, according to the last IEEE-2008 standard, any 
language must implement decimal floating point support at the 
same level of binary float support. Once al language has float, 
double and real, must also define decimal counterparts - 
decimal32, decimal64 and decimal128.

Concerning the advantages of a built-in data type, it happens to 
work right now to a decimal BID floating point implementation, 
here is a list of problems I encountered during development:

- literals - right now the only way to define literals is a 
templated string, using float literals will result in precision 
loss, since binary floating point cannot be represented exactly.
- correct comparison operators - operator overloading doesn't 
allow unordered comparisons similar to binary data types. 
Comparing any NaN, must always return false, implementing 
opEquals is not enough is this case, since a != b is equivalent 
to !(a == b)
- implicit casting cannot be defined - a decimal32 must be 
implicitly convertible to decimal64 and a decimal64 must be 
implicitly convertible to decimal128.
- using a global DecimalContext (according to IEEE standard) - 
similar to std.math.FloatingPointControl, will make all your 
functions impure. Throwing exceptions according also to IEEE 
standard will make any calculation garbage collected. The 
compiler can override this behaviour as it's doing in the binary 
floating point case, they are also using a global context and 
throw exceptions.
- BigInt is unsuitable as backend for decimal128 data type since 
it allocates on overflow, therefore all your operations will be 
garbage collected. Also BigInt is using uint arrays as backend, 
there is no performance optimisation for 64 bit arithmetic, 
that's why is slow. Adding a scale to the BigInt is not enough, 
once you need to multiply values with high-precision percents, 
you must keep all your numbers scaled to many, many digits 
resulting in very poor performance.
- Efficient 128 bit arithmetic is missing since ucent is not 
implemented and the decimal128 data type is heavily built on it. 
Writing your own 128 bit data type will have the same 
disadvantages as exposed above. As a fun fact, through trial and 
error, I discovered that a FPU division is faster than the 
Newton–Raphson applied to wide integral data types. Probably, a 
fine tuned assembler implementation is faster than that. Since 
there are operations calculated using unlimited precision like 
fma(), there is also need for efficient >128 bit arithmetic.
- Impurity and garbage collection being involved, the CTFE is not 
always available.
- Heavily templating your code to cover all three decimal data 
types, will result in unintelligible compiler errors like "Out of 
memory" and will render features like code completion useless. 
Using mixins will break out syntax highlighting, code completion 
and documentation; to cope with that you will finally copy-paste 
code all over the place.
- you cannot interfere with compiler optimisations, eg comparing 
a decimal value to 0 in certain cases can be done with a simple 
bit test, instead of a fully featured function, even inlined.

Yes, I'm working in the "very fringe sector of users" - financial 
apps. So banks, insurance companies, investment funds and 
accounting firms are a very fringe sector. In most cases they are 
using Java for development, a very fringe language. Good to know 
that.