I think it's time to re-hash an old discussion from a couple years ago. I propose replacing type names for integers (http://www.digitalmars.com/d/type.html) with the following:

bit
byte
ubyte
int16
uint16
int32
uint32
int64
uint64
int128
uint128

... etc

Why?
1) It's more logical and easier to remember
2) It better reflects the integer size, so people are less likely to make
mistakes when moving from C. It'll also make people more careful when
converting, and make sure no type names overlap when doing automatic
conversions using things like sed or awk.
2) The second is that cent and ucent is not a very good name for 128 bit
variables. Cent means 100. int128 makes more sense.



1) Instead of using names
like long, short, and int, it would be better to use names that show the
number of bits each variable has, and whether it is unsigned. This is the
convention used in the Mozilla project, and it works very well. This will
have the advantage, also, of making people more careful when porting C/C++
applications to D. It will also mean that people migrating to D won't be
caught up in the old definition of long, which is different on Alpha and
PC systems. This will also mean there won't a lot of different types when
128 and 256 bit systems come along. It'll get too complicated. It'll also
be easier for strange system designers who want to do, say, 24-bit
integers, which might be the case on integrated systems. Then they could
just do a int24 and uint24, and no one would be confused.

You can
provide a temporary standard header that will provide the alternate names
you provided on http://www.digitalmars.com/d/type.html until people have
migrated to the new system I suggested here.

This method is a lot more logical in my opinion, and I'm sure a lot will agree.

2) cent and ucent is not a good name for a 128-bit variable. First of all, it might be too easily mixed up with a simple structure for representing currency. Second of all, 128 is not 100. In fact, a 128-bit integer simply backs up what I said in 1. Naming data types is getting ridiculous. What is longer than long? I guess it could be 'extended' or 'stretch', but seriously... Let's make things a bit less complicated.

I have to say that I fully agree with Brian on this one.  Even .NET has moved to this style of nomenclature (Byte, Int16, Int32, UInt64, Single, Double, etc...) and it makes things a lot less confusing.

For me, the most compelling of the reasons listed below is talking about people coming from a C/++ background.  If you have a conversion chart with entries like these:

long double        = real
unsigned long long = ulong
long long          = long
unsigned long      = uint
long               = int

that's bad news.  It's confusing enough to say aloud: "A long long is a long and a long is an int"

-Deja

In article <cisodp$2vok$1@digitaldaemon.com>, Brian Bober says...
>
>I think it's time to re-hash an old discussion from a couple years ago. I propose replacing type names for integers (http://www.digitalmars.com/d/type.html) with the following:
>
>bit
>byte
>ubyte
>int16
>uint16
>int32
>uint32
>int64
>uint64
>int128
>uint128
>
>... etc
>
>Why?
>1) It's more logical and easier to remember
>2) It better reflects the integer size, so people are less likely to make
>mistakes when moving from C. It'll also make people more careful when
>converting, and make sure no type names overlap when doing automatic
>conversions using things like sed or awk.
>2) The second is that cent and ucent is not a very good name for 128 bit
>variables. Cent means 100. int128 makes more sense.
>
>
>
>1) Instead of using names
>like long, short, and int, it would be better to use names that show the
>number of bits each variable has, and whether it is unsigned. This is the
>convention used in the Mozilla project, and it works very well. This will
>have the advantage, also, of making people more careful when porting C/C++
>applications to D. It will also mean that people migrating to D won't be
>caught up in the old definition of long, which is different on Alpha and
>PC systems. This will also mean there won't a lot of different types when
>128 and 256 bit systems come along. It'll get too complicated. It'll also
>be easier for strange system designers who want to do, say, 24-bit
>integers, which might be the case on integrated systems. Then they could
>just do a int24 and uint24, and no one would be confused.
>
>You can
>provide a temporary standard header that will provide the alternate names
>you provided on http://www.digitalmars.com/d/type.html until people have
>migrated to the new system I suggested here.
>
>This method is a lot more logical in my opinion, and I'm sure a lot will agree.
>
>2) cent and ucent is not a good name for a 128-bit variable. First of all, it might be too easily mixed up with a simple structure for representing currency. Second of all, 128 is not 100. In fact, a 128-bit integer simply backs up what I said in 1. Naming data types is getting ridiculous. What is longer than long? I guess it could be 'extended' or 'stretch', but seriously... Let's make things a bit less complicated.

On Wed, 22 Sep 2004 21:46:17 +0000, Deja Augustine wrote:

> I have to say that I fully agree with Brian on this one.

me too.

this was suggested before.

  Even .NET has moved to
> this style of nomenclature (Byte, Int16, Int32, UInt64, Single, Double, etc...)

but something has to be done to float, single, double, real also.

Ant

So you suggest something like float32, float64, float80, imag32, imag64, imag80, and complex32, complex64, and complex80?

On Wed, 22 Sep 2004 18:20:23 -0400, Ant wrote:
> but something has to be done to float, single, double, real also.
<snip>

On Thu, 23 Sep 2004 09:21:52 +1200, Regan Heath wrote:

> What no go all the way...
> 
> "byte"   -> "int8"
> "float"  -> "float32"
> "double" -> "float64"
> "real"   -> "float80" (intel only?)
> "char"   -> "char8"
> "wchar"  -> "char16"
> "dchar"  -> "char32"
> 
> Regan


I thought about byte being int8, but thought that people would like byte better since bit and byte are standard on all platforms but anything above that is not. For instance, word means the word length on a system.

int8 would be more consistent, but I assumed in general people would like byte better than int8.

char8/16/32 sounds good, and could also be utf8/16/32

I strongly agree with this suggestion (for types other than integer as
well).

When types are constrained to a particular size, it just seems intuitive to include that size in the type name.

More ambiguous names such as "int" could be used to indicate a type corresponding to the natural word size of a particular machine architecture (pretty sure someone else suggested this ages ago).

Tony

"Brian Bober" <netdemonz@yahoo.com> wrote in message news:cit099$289$1@digitaldaemon.com...
> So you suggest something like float32, float64, float80, imag32, imag64, imag80, and complex32, complex64, and complex80?
>
> On Wed, 22 Sep 2004 18:20:23 -0400, Ant wrote:
> > but something has to be done to float, single, double, real also.
> <snip>
>

In article <cisodp$2vok$1@digitaldaemon.com>, Brian Bober says...
>
>I think it's time to re-hash an old discussion from a couple years ago. I propose replacing type names for integers (http://www.digitalmars.com/d/type.html) with the following:
>
>bit
>byte
>ubyte
>int16
>uint16
>int32
>uint32
>int64
>uint64
>int128
>uint128
>
>... etc
>
>Why?
>1) It's more logical and easier to remember

Though not /quite/ as logical as:

int8   (instead of byte)
uint8  (instead of ubyte)

Arcane Jill

In article <pan.2004.09.22.22.20.21.173705@yahoo.ca>, Ant says...

>but something has to be done to float, single, double, real also.

Well, the /logical/ names would have to be: rational32, rational64 and rational80. But maybe they could be abbreviated to rat32, rat64 and rat80 (in the same way that "integer" is abbreviated to "int"). What's left? How about ieee32, ieee64 or ieee80?

(Of course, as I'm sure you all realise, IEEE floats can only represent rationals, not reals. One cannot represent /any/ irrational number as an IEEE float).

Jill

In article <cit6j3$4sp$1@digitaldaemon.com>, Brian Bober says...
>
>On Thu, 23 Sep 2004 09:21:52 +1200, Regan Heath wrote:
>
>> What no go all the way...
>> 
>> "char"   -> "char8"
>> "wchar"  -> "char16"
>> "dchar"  -> "char32"
>> 
>> Regan

What the hell. Let's go /all/ the way...

char  -> utf8
wchar -> utf16
dchar -> utf32

Then we'll have none of that nonsense of people confusing D's chars with C's chars, which should /in fact/ be mapped to int8 and uint8.

Jill

PS. I also suggest float32, float64, float80, ifloat32, ifloat64, ifloat80, cfloat64, cfloat128 and cfloat160 for the float types.

Brian Bober wrote:
> On Thu, 23 Sep 2004 09:21:52 +1200, Regan Heath wrote:
> 
> 
>>What no go all the way...
>>
>>"byte"   -> "int8"
>>"float"  -> "float32"
>>"double" -> "float64"
>>"real"   -> "float80" (intel only?)
>>"char"   -> "char8"
>>"wchar"  -> "char16"
>>"dchar"  -> "char32"
>>
>>Regan
> 
> 
> 
> I thought about byte being int8, but thought that people would like byte
> better since bit and byte are standard on all platforms but anything
> above that is not. For instance, word means the word length on a system.
> 
> int8 would be more consistent, but I assumed in general people would like
> byte better than int8.
> 
> char8/16/32 sounds good, and could also be utf8/16/32

Agreed with this point of view. I always have trouble with the words "int", "long", etc. Many languages and platforms have their own explanation of the length of each of these.

In the solution to provide the bitlength for each type (except bit and byte) it is possible for each platform to have their own lengths. In future, you might want to have int128 or utf64 even int4 (a nibble). These representations seem much more logical to me. (Besides that int128 couldn't possibly be named: long long long).

Regards,
Sjoerd