Mark Evans wrote:

> Perhaps D could adopt some aliases like these.  They are nice because they are
> unambiguous (unlike C ints whose size can vary from machine to machine).
> 
> The term "double" is made explicit by the use of 64, which is 32x2.  I really
> like having the size indicated in the type name.
> 
> You see this sort of thing all the time in cross-platform code and generic APIs
> which must cover several compilers or OS's.

Putting these in some special module, something like types.d,
seems like a good idea to me. Then one can import that module
when needed.

Having created an in-house .h file for our C++ work, I can state that it is very easy to fall back on the good old 'int' when you are coding, even though you know you were supposed to specify a particular type of int (int32, for instance).  Picking a consistent, flexible, and extendible type naming system and building it into the language avoids this problem.  If there is no such thing as an 'int' to use, then you have to specify what you meant.  I don't mind having to specify what I meant when I am programming ;)

The usual argument for 'int' in C/C++ is that it is supposed to represent the fastest integral type on the given architecture.  Fine, but why not have things like:

fast8  (8bit, on x86)
fast16 (32bit, on x86)
fast32 (32bit, on x86)
fast64 (??bit, on x86)

This way you can state that you are in a hurry, as well as specifying what kind of range you'll need.

Our internal .h file actually had types for 'fast', 'tight', and 'exact'. 'fast' gave you a fast type for loops, 'tight' gave you the smallest type that would hold your range (for arrays), and 'exact' gave you exactly what you asked for (for struct/packet overlays).  This may be overkill for general use, but it is a workable and explicit system...  For what it's worth, we ended up shortening the names considerably, so that we had things like F8 (fast 8bit), UT16 (unsigned tight 16bit), etc.  While it does make the names shorter to type, I'm not sure yet what it does to readability...  I can say that you either want highly abbreviated or fully expanded names, because trying to combine them is just confusing -- tint8 looks like a color, rather than a char; eint16 looks like an "extended" int16, whatever that would mean.

Mac

In article <al1hjr$2g87$1@digitaldaemon.com>, Pavel Minayev says...
>
>Mark Evans wrote:
>
>> Perhaps D could adopt some aliases like these.  They are nice because they are unambiguous (unlike C ints whose size can vary from machine to machine).
>> 
>> The term "double" is made explicit by the use of 64, which is 32x2.  I really like having the size indicated in the type name.
>> 
>> You see this sort of thing all the time in cross-platform code and generic APIs which must cover several compilers or OS's.
>
>Putting these in some special module, something like types.d, seems like a good idea to me. Then one can import that module when needed.
>

> D has "extended" right now. I confess I hate it. Perhaps "triple" is a better idea.

'extended' is too long to type indeed!
'integer' is one character shorter, but it has been shortened anyway (we
have 'int', in fact!).
Why don't you choose 'ext'?

People will be encouraged to use that type if it's fast enough to type. Few people use 'long double' in C: it's even two words long!!!

'triple' is pretty, but doesn't suit the definition. 'extended' isn't necessary 80bit (or 96): it's the largest representation available for the implementation.

Maybe we should have both. So we won't have to invent new types for implementations with 128bit floats. (i.e. float:32, double:64, triple:96, ext:128)