I suggest to remove the real type from D2 because: - It's the only native type that has not specified length. I'm sold on the usefulness of having defined length types. Unspecified length types causes some of the troubles caused by C types that D has tried to avoid defining the size of its integral types. - Its length is variable across operating systems, it can be 10, 12, 16 bytes, or even just 8 if they get implemented with doubles. The 12 and 16 bytes long waste space. - Results that you can find with programs written in other languages are usually computed with just floats or doubles. If I want to test if a D program gives the same results I can't use reals in D. - I don't see reals (long doubles in C) used much in other languages. - If I compile a program with LDC that performs computations on FP values, and I take a look at the asm it produces, I can see onl SSE-related instructions. And SSE registers allow for 32 and 64 bit FP only. I think future AVX extensions too don't support 79/80 bit floats. GPUs are increasingly used to perform computations, and they don't support 80 bit floats. So I think they are going to be obsolete. Five or ten years from now most numerical programs will probably not use 80 bit FP. - Removing a built-in type makes the language and its manual a little simpler. - I have used D1 for some time, but so far I have had hard time to find a purpose for 80 bit FP numbers. The slight increase in precision is not so useful. - D implementations are free to use doubles to implement the real type. So in a D program I can't rely on their little extra precision, making them not so useful. - While I think the 80 bit FP are not so useful, I think Quadrupe precision FP (128 bit, currently usually software-implemented) can be useful for some situations, (http://en.wikipedia.org/wiki/Quadruple_precision ). They might be useful for High dynamic range imaging too. LLVM SPARC V9 will support its quad-precision registers. - The D2 specs say real is the "largest hardware implemented floating point size", this means that they can be 128 bit too in future. A numerical simulation that is designed to work with 80 bit FP numbers (or 64 bit FP numbers) can give strange results with 128 bit precision.
So I suggest to remove the real type; or eventually replace it with fixed-sized 128 bit floating-point type with the same name (implemented using a software emulation where the hardware doesn't have them, like the __float128 of GCC: http://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html ). In far future, if the hardware of CPUs will support FP numbers larger than 128 bits, a larger type can be added if necessary. Bye, bearophile
