Complex number functions for std.math

[Norbert Nemec]

Anders F Björklund wrote:
>> Exactly my opinion: The basic types should have well-defined bit-sizes
>> and be portable across architectures.
> 
> It could just be a side-effect of DMD only targetting one architecture ?

That certainly is the core of the issue. The D specification contains a
bit of theoretical talk about portability, but effectively the language
is an x86-only language only.

> The real type is 80 bits in register on all the supported platforms, it
> just varies in size when stored to mem/disk (80 on Windows, 96 on Linux,
> and will probably increase to 128 bit when 64-bit Linux is supported ?)
> Usually it just follows the platform definition of "long double", for C.

This confusion is exactly what I have problems with.

> I had a similar suggestion, but the other way around... Keep the
> current type names, and added the bitsizenames as aliases instead.
> (my original post had names similar to stdint, such as float32_t)

That means trying to build something well-defined on top of shaky ground
which is exactly what causes the huge mess of C/C++-build systems like
"automake" and "autoconf". The build system has to do a number of tests
to find out what the implementation-dependend things are on a given
system to define portable types. This is just the thing I believed D was
supposed to solve.

> I thought including the bit size in the name made it a bit harder to
> read and more unattractive, quite similar to the case with integers ?
> (i.e. naming those types as int8, int16, int32, int64, int128 instead)

Harder to read? That's exactly what aliases should be used for. The
names including bit sizes are precise, well defined and to the point,
which is the best ground to build something on top

> But I haven't heard anything suggesting that "real" will ever change...
> As far as I know, that part of the D specification is already decided.

Yes, it is decided and Walter considers the topic closed. The whole
discussion that is going on here is completely academic as is the whole
question of portability. But one day, somebody might actually try to
port D to a seriously different architecture, and latest at that point,
this issue will have to be rolled up again.