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.

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...

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

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

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.

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.

If 'twere done, 'twere best done quickly!
(I see a lot to like about those names, but perhaps the current
names should be kept, for awhile, as aliases? And, of course,
deprecated.)

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

In all modern network protocols, a byte contains eight bits. A few
(generally obsolete) computers may use bytes of different sizes for other
purposes.

So, strictly, it would have to be int8 and uint8 - which I would be quite happy
with.

Also wikipedia has the details on this topic: http://en.wikipedia.org/wiki/Byte
"C, for example, defines byte as a storage unit capable of at least being large
enough to hold any character of the execution environment (clause 3.5 of the C
standard)."
So even though I doubt anyone will be backporting D to legacy systems with
non-8-bit-bytes, it makes sense to define byte as uint8 or something similar.
pragma(EricAnderton,"at","yahoo");

...
Also wikipedia has the details on this topic: http://en.wikipedia.org/wiki/Byte
"C, for example, defines byte as a storage unit capable of at least being large
enough to hold any character of the execution environment (clause 3.5 of the C
standard)."
So even though I doubt anyone will be backporting D to legacy systems with
non-8-bit-bytes, it makes sense to define byte as uint8 or something similar.
pragma(EricAnderton,"at","yahoo");

...
Also wikipedia has the details on this topic: http://en.wikipedia.org/wiki/Byte
"C, for example, defines byte as a storage unit capable of at least being large
enough to hold any character of the execution environment (clause 3.5 of the C
standard)."
So even though I doubt anyone will be backporting D to legacy systems with
non-8-bit-bytes, it makes sense to define byte as uint8 or something similar.
pragma(EricAnderton,"at","yahoo");

So if the current environment includes utf32 characters, then...

Yeah the wording could probably be refined a bit. I'm pretty sure the current
expectation is for char/uchar to always occupy one byte, otherwise they'd have
to go and define a new type name. Also, the wording is such that uchar is
basically a building-block for everything, so it almost has to be one byte in
size.
Sean

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

As no-one else contradicts, I do.
The problem is that this change would break all existing D code.
Developers world-wide would have to put thousands of hours into
their code to update. This is unfun. There are surely other
issues where we can put this time into.
All programming languages require some effort to learn their
basic data types. It's so simple and so fundamental that I think
there is no need to make it simpler.
It would also increase the distance to languages like C and Java
and add work to translations.
This is not a logical argument, it's pragmatic. The suggestion
is valid and should maybe be used for another language designed from
scratch. But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com

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

As no-one else contradicts, I do.
The problem is that this change would break all existing D code.

Why should it break all code if we keep aliases to current types?
like: alias int 32 int...

Developers world-wide would have to put thousands of hours into
their code to update. This is unfun. There are surely other
issues where we can put this time into.
All programming languages require some effort to learn their
basic data types. It's so simple and so fundamental that I think
there is no need to make it simpler.
It would also increase the distance to languages like C and Java
and add work to translations.
This is not a logical argument, it's pragmatic. The suggestion
is valid and should maybe be used for another language designed from
scratch. But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com

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

As no-one else contradicts, I do.
The problem is that this change would break all existing D code.

Why should it break all code if we keep aliases to current types?
like: alias int 32 int...

Then it is not a rename.
Then create aliases for the suggested types.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com

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

As no-one else contradicts, I do.
The problem is that this change would break all existing D code.

Why should it break all code if we keep aliases to current types?
like: alias int 32 int...

This is good, but be sure to deprecate the aliases... if not
immediately, then DECIDE that they will be deprecated in, say, 6 mo.s.

...scratch. But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.
--
Helmut Leitner leitner hls.via.at
Graz, Austria www.hls-software.com

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

As no-one else contradicts, I do.
The problem is that this change would break all existing D code.
Developers world-wide would have to put thousands of hours into
their code to update. This is unfun. There are surely other
issues where we can put this time into.

All programming languages require some effort to learn their
basic data types. It's so simple and so fundamental that I think
there is no need to make it simpler.
It would also increase the distance to languages like C and Java
and add work to translations.
This is not a logical argument, it's pragmatic. The suggestion
is valid and should maybe be used for another language designed from
scratch. But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.

Walter's answer here (to my proposal, actually) practically states that int16
and other identifiers with numbers appended don't look good and are visually
confusing when in algebraic expression.
I don't remember whether I replied to that article two years ago, but now I
don't think it's such a big deal. In common programming, one usually just uses
the venerable 32-byte integer type called "int", since that's pretty good for
most uses. The other integer types are mostly for systems and embedded
programming, squeezing the last bit of performance, or interfacing with
libraries that are designed for one of the aforementioned purposes. Or indeed
for situations where you actually need those extra bits.
If I really wanted to shoot down the his answer and the reasoning behing it,
though, I'd reuse the previous point (== "other types than 'int' are quite
rarely used so them having numbers doesn't matter that much) and additionally
point out that type names are not used in arithmetic expressions -- variable
names are. (And those are even more rarely used, especially in arithmetic
contexts.)
However it is Walter's opinion, and you don't shoot down opinions. Not at least
that easily. <evil grin>
(By the way - I don't think that typenames with integers appended are ugly, yet
I still loathe^H^H^H^H^H^H am very reserved about other syntactic baggage like
ITheHorribleInterfacePrefix or pszawflHungarianNotation. Or even long
identifiers if you can say it shorter. It would be difficult to think
objectively if I were deciding whether to include one of them into the language
conventions. Behold the power of opinions.)
-Antti
P.S. Is there a list for long-standing feature/change proposals in some kind
of Wiki, Bugzilla or something? I'll add one argument:
* The names are self-documenting

(This article speaks mostly about ints, although I definitely like utf8, utf16
and utf32 as well.)

I'm not sure I understand all of this post, just wanted to pointed out
that stdint and stdbool aliases *have* now been added to the language...
module std.stdint;
/* Exact sizes */
alias byte int8_t;
alias ubyte uint8_t;
alias short int16_t;
alias ushort uint16_t;
alias int int32_t;
alias uint uint32_t;
alias long int64_t;
alias ulong uint64_t;
module object;
// there's a long rant about whether this alias should go in std.stdbool
// instead, and why true and false should not be keywords if bool isn't
alias bit bool;

P.S. Is there a list for long-standing feature/change proposals in some kind
of Wiki, Bugzilla or something? I'll add one argument:
* The names are self-documenting

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList
I posted the suggestion of std/stdutf.d to the item list:
module std.stdutf;
/* Code units */
alias char utf8_t;
alias wchar utf16_t;
alias dchar utf32_t;
Unfortunately I mixed it up with the "string" and "ustring",
which confused people. It should be split into two separate...
It would be neat if some "voting" procedure could be installed,
right now it's usually down to a final veto from the One Vote.
--anders

I personally find these ugly, but there is an additional annoyance with this
kind of naming: What is an int8? Is it equivalent to byte, or long? About
half of the code I see that uses these uses int32 to represent the "int" and the
other half uses "int4". There is no standardization on whether this is bytes or
bits. Or rather, there are several standardizations.
Kevin

I personally find these ugly, but there is an additional annoyance with this
kind of naming: What is an int8? Is it equivalent to byte, or long? About
half of the code I see that uses these uses int32 to represent the "int" and
the
other half uses "int4". There is no standardization on whether this is bytes
or
bits. Or rather, there are several standardizations.

This is *the* standard. It's called "stdint",
and it is available in: C99, C++ - and D.
// C99 / C++
#include <stdint.h>
// D
import std.stdint;
It's a standard *just* to keep folks from
inventing their own types like "int4"...
--anders
PS. All new standards seems to be about bits (not bytes)
At least if you compare UTF-16 (new) vs UCS-2 (old) ?

(Sorry for the excessive quoting)
Ah, I see. I thought I remembered something like that.
So we have them. Hurray. Not that I will (at least initially) want to
touch anything equipped with the dreaded '_t' suffix from the C era, but
at least we have them.
And to think of the fact that the original reason for rejecting them was
that they are not "aesthetically pleasing". Heh.
I suppose that the _t suffix should be added to the D style guide as the
official suffix denoting ... umm, what does it denote actually? You
don't use it in every alias, do you?

So we have them. Hurray. Not that I will (at least initially) want to
touch anything equipped with the dreaded '_t' suffix from the C era, but
at least we have them.
And to think of the fact that the original reason for rejecting them was
that they are not "aesthetically pleasing". Heh.
I suppose that the _t suffix should be added to the D style guide as the
official suffix denoting ... umm, what does it denote actually? You
don't use it in every alias, do you?

I think that it stands for "typedef" (the name of alias in C),
but the main reason is so that they would be totally different...
Since people already had all kinds of aliases defined locally,
the new standard one had to stand out a little.
http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html
It also gets rid of the "but it could be confused with a number",
since it no longer ends in any numeric characters... Or something?
In D, you can also find the suffix in the standard aliases:
"size_t" (either 32 or 64) and "ptrdiff_t" (either 32 or 64)

The problem is that this change would break all existing D code.
Developers world-wide would have to put thousands of hours into
their code to update. This is unfun. There are surely other
issues where we can put this time into.

It doesn't /actually/ take thousands of hours to do a simple search-and-replace,
however. And the old names could be deprecated during the transition.

All programming languages require some effort to learn their
basic data types. It's so simple and so fundamental that I think
there is no need to make it simpler.

You'd think so, wouldn't you? In the case of D, however, it seems that the basic
types still have not been learned by everyone, and even the D manual get
confused sometimes. Is a D char the same thing as C char? Or is it the same
thing as a C byte or ubyte? Does D's "bool" count as a type? Technically it's
just an alias, but since that alias is declared in object.d, it's pretty
difficult to ignore, and most of us treat is as if it were a basic type. But
then, why does Object.opEquals() return int, not bool (which is an alias for
bit, not int)? Walter says it's more efficient - in which case, shouldn't bool
be int? And what does the "d" in "dchar" stand for anyway? Double-wide?
So long as people write programs in C and D at the same time and expect them to
interoperate, confusion over the meanings of "char", "bool array" and so on,
will continue, and discussions like this will come back, over and over again.

It would also increase the distance to languages like C and Java
and add work to translations.

On the contrary, the fact that you can store Chinese characters in a "char"
array in D but not is C is already a great "distance". The fact that an array of
sixteen bools is sixteen bytes in C but only two bytes in D (and you can't take
the address of elements) is more "distance". Using different words for different
concepts would, in my view, decrease the distance, not increase it.
In fact, the only existing overlaps between C and D are "short", "int", "float"
and "double" (and even then not on all platforms).

But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.

Many people have said (and I agree with them) that getting it /right/ is more
important than getting it /soon/. I can wait 3-4 months, if it means D gets it
right. Hurrying things along out of impatience is a recipe for disaster.
In my humble opinion
Jill

But not at this stage of D development where we are
longing for a 1.00 release. This would put us back 3-4 months.

Many people have said (and I agree with them) that getting it /right/ is more
important than getting it /soon/. I can wait 3-4 months, if it means D gets it
right. Hurrying things along out of impatience is a recipe for disaster.

</snip>
To Walter's credit, if all we wanted to do is rename the data types,
that would take about 35 seconds. If we wanted to add aliases, that
would take maybe another minute and a half, depending on whether or not
Walter knew exactly where he wanted to put them.
I'm already considering renaming the data types for D.NET and aliasing
them to the current D types. It just seems more confusing to look at C#
code where a function returns an Int16 and the D code that receives it
using a short and vice versa.
It's not at all a complex operation, so the time it would take to
actually implement is negligable. Of much more concern, I would think,
is the public's reaction, and I think that evidence has been
overwhelming to this point that such a change would be welcomed by the
majority of D users.
-Deja