Complex number functions for std.math

[Anders F Björklund]

Georg Wrede wrote:

> Ehh, if I understand this correctly, this would be the opposite from:
> 
> Define "bitsizenames" as the ultimate "Genuine Types", and only alias 
> them to the "usually used" types.

Yes, this would be the opposite from changing the base type names...

But all those D types (again: except for real) have a fixed size, so
it's nothing like what you encounter in the old C headers/libraries ?

The only question is which of them is genuine and which is the alias.

> This "opposite" is what I have a problem with. I start seeing ghosts in 
> the bedroom as soon as somebody tries to define "reality" with a set of 
> incongruent "colloquial" names, and only then -- and as defined by them, 
> define the "reality" types.
> 
> I hope I've seriously misunderstood the above post.

Depends on what you read into it. It's only a pragmatic approach, based
on the assumption that the names in the current type list won't change.

Thus, adding types with embedded bit sizes would *have* to be aliases ?
Here was the entire list, with the floating points changed and added to:

INTEGER
byte (8)
short (16)
int (32)
long (64)
cent (128)

FLOATING-POINT
half (16)
float (32)
double (64)
extended (80)
quad (128)

I don't think the current D names are that bad. Similar to C and Java...
And I don't think that they (D) are going to change, either ? Do you ?

And whether you use "int" or "int32_t", and perhaps "double" or e.g.
"Float64", is more a matter of style and taste than of the D language ?

--anders