"Bent Rasmussen" <exo@bent-rasmussen.info> wrote in message news:cj73a1$j5r$1@digitaldaemon.com...
> Perhaps this is the essence

Or maybe this little part from lexer.h: :)

#define CASE_BASIC_TYPES   \
 case TOKwchar: case TOKdchar:  \
 case TOKbit: case TOKchar:  \
 case TOKint8: case TOKuns8:  \
 case TOKint16: case TOKuns16:  \
 case TOKint32: case TOKuns32:  \
 case TOKint64: case TOKuns64:  \
 case TOKfloat32: case TOKfloat64: case TOKfloat80:  \
 case TOKimaginary32: case TOKimaginary64: case TOKimaginary80: \
 case TOKcomplex32: case TOKcomplex64: case TOKcomplex80: \
 case TOKvoid

:)

> http://www.digitalmars.com/drn-bin/wwwnews?D/8100
>
>

Ivan Senji wrote:
> "Helmut Leitner" <helmut.leitner@wikiservice.at> wrote in message
> news:41568D76.A0536642@wikiservice.at...
> 
>>
>>Brian Bober wrote:
>>
>>>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 

In article <41568D76.A0536642@wikiservice.at>, Helmut Leitner says...

>As no-one else contradicts, I do.

<humor>There's always one, isn't there! (rolls eyes)</humor>

Trouble is, of course, you're basically right. But let me argue with you anyway...


>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

Arcane Jill wrote:
> In article <41568D76.A0536642@wikiservice.at>, Helmut Leitner says...
<snip>
> 
> 
>>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

"Helmut Leitner" <helmut.leitner@wikiservice.at> escribió en el mensaje
news:4156ABF5.494C80F5@wikiservice.at...
| 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

Those aliases exist: std.stdint

-----------------------
Carlos Santander Bernal

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

In article <cj73a1$j5r$1@digitaldaemon.com>, Bent Rasmussen wrote:
> Perhaps this is the essence
> 
> http://www.digitalmars.com/drn-bin/wwwnews?D/8100

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

Antti Sykäri wrote:

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

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

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

Kevin Bealer wrote:

>>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;
> 
> 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) ?

In article <clq73e$1gln$1@digitaldaemon.com>, Anders F Björklund wrote:
> Antti Sykäri wrote:
> 
>> (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;

(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?

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

Thumbs up for this. I don't remember what char, wchar and dchar mean, but utf8(_t) makes it instantly crystal clear.

-Antti