|Posted by Christopher Wright|
in reply to bearophile
Posted in reply to bearophile
> The following is just an hypotheses :-)
> For D 2.x I think it may be nice to have an int name system like this:
> uint8, int8, uint16, int16, uint32, int32, uint64, int64, uint128, int128, uintcpu, intcpu
Replacing 'intcpu' and 'uintcpu' with just 'int' and 'uint', I'd agree.
For now, you can use any aliases you want. And that's a good enough solution. std.nativetypes anyone? You could file an enhancement request in bugzilla with an attachment.
> Instead of the current:
> ubyte, byte, ushort, short, uint, int, ulong, long, ucent, cent, size_t, ...
> Plus an "int" type that is multi-precision, but:
> - With the help of the GC it's optimized (that is it requires 32 bits only) for small signed integers up to about 29-30 bit long.
> - The compiler is able to spot some places where int is used in a context where it can't use more than 29-30/63 signed bits, and use an uint32/int32/uint64/int64 there, to speed up the code a bit.
> - int can be used to perform some conversions, as in Python: int(" 125 ") => 125; int(1.5) == trunc(1.5); int("1210121012", 3) => 35429
What's wrong with toint("125") ?