Hi there,

the idea was brought up by Georg Wrede in the "80 bit challenge" thread, but I think it is more general:

Why not generalize the behavior of types and literals:
* have types of exactly-defined size/precision
* alternatively have types that default to the optimum size/precision of the platform
* have suffixes for literals to specify exact precision
* have literals without suffix result in the default type

Now, the mapping between the default type and the exact precision should be done by the implementation, but there should be a pragma to change it by hand.

The details of the naming are a secondary topic. The following has been proposed, discussed and rejected over and over again. Still, together with the idea of making the mapping configurable via a pragma and coupling it with the default size of literals, it might be interesting to reconsider.

I would still propose to clean up the mess of C types completely and start from scratch:

	int8, int16, int32, int64, int128
	uint8, uint16, uint32, uint64, uint128
	float32, float64, float80, float128
	ifloat32, ifloat64, ifloat80, ifloat128
	cfloat32, cfloat64, cfloat80, cfloat128

No further explanation necessary. Any programmer coming from whatever language will understand intuitively without consulting a manual. (One has to be aware that cfloat32 has actually 64 bits, but that matter is awkward no matter which way you put it.)

The "optimum-size" types:
	int, real, imaginary, complex

As said, the mapping between optimum-size types and exact-size types is given by default by the compiler, but there should be a pragma to fix it on a per-source-file basis.

The fixed-size types might look ugly like hell, but they are not supposed to be used a lot, except in places where you need to be aware of exact bit-sizes. Most code will only deal with the optimum-size types, which is easy to be remapped if you need to work around compatibility issues.

This solution will do away with the awkward historical short/int/long and float/double/long-double confusion without just running into another confusion.

Compatibility with existing D code might break in some places but not badly. Porting C code should not be a problem: int in C never was cleanly defined, so any code depending on a fixed size was broken anyway. float and double simply don't exist anymore, so you either define an alias or replace them by "real".

Norbert Nemec wrote:

> The details of the naming are a secondary topic. The following has been
> proposed, discussed and rejected over and over again. Still, together
> with the idea of making the mapping configurable via a pragma and
> coupling it with the default size of literals, it might be interesting
> to reconsider.
>
> I would still propose to clean up the mess of C types completely and start from scratch:
> 
>     int8, int16, int32, int64, int128
>     uint8, uint16, uint32, uint64, uint128
>     float32, float64, float80, float128
>     ifloat32, ifloat64, ifloat80, ifloat128
>     cfloat32, cfloat64, cfloat80, cfloat128

You could also add these Unicode types to the mess:
      utf8, utf16, utf32

BTW:
Have you looked at the DMD source code yet ?
You might want to peek at "dmd/mars.h"... :-)

> No further explanation necessary. Any programmer coming from whatever language will understand intuitively without consulting a manual. (One has to be aware that cfloat32 has actually 64 bits, but that matter is awkward no matter which way you put it.)

I made a half-hearted attempt to reuse the stdint types
for floating point types too, but withdrew it again...

See http://www.prowiki.org/wiki4d/wiki.cgi?StdTypeAliases
It just seemed like too many people hated the _t suffix ?

> The "optimum-size" types:
>     int, real, imaginary, complex

That should probably just be "integer", to avoid
a couple of decades of confusion on the matter ?
(just as real could also be "floating" or something)

You also have the "types": size_t and wchar_t, too ?
(linking to uint/ulong and wchar/dchar, respectively,
alias target depending on what the target ABI/API is)

    version (X86) alias ulong size_t;
    else version (AMD64) alias uint size_t;
    else static assert(0);

    version (Win32) alias wchar wchar_t;
    else version (linux) alias dchar wchar_t;
    else static assert(0);

D currently uses the CPU and OS here (a mistake, IMHO,
as it should instead be all about the ABI and the API...)

> Compatibility with existing D code might break in some places but not badly. Porting C code should not be a problem: int in C never was cleanly defined, so any code depending on a fixed size was broken anyway. float and double simply don't exist anymore, so you either define an alias or replace them by "real".

These are (IMHO) the D names-du-jour, for the above list:

     byte, short, int, long, cent
     ubyte, ushort, uint, ulong, ucent
     float, double, extended, quadruple
     ifloat, idouble, iextended, iquadruple
     cfloat, cdouble, cextended, cquadruple
     char, wchar, dchar

Mapping these two sets could be given as a quiz... ;-)
(probably right after the Mars/Phobos/Deimos question)


As long as the irreal and cereal types dies, all's well...
(but I do not like the proposed number suffixes myself, at
least not as the primary type names? I'm too used to C/Java)

--anders

>     version (X86) alias ulong size_t;
>     else version (AMD64) alias uint size_t;
>     else static assert(0);

Oops, seems I made a small copy-and-paste error:

     version (X86) alias uint size_t;
     else version (AMD64) alias ulong size_t;
     else static assert(0);

--anders