Some suggestions for D:

data types:
use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
char" "short" and so on, especially instead of "long long" and other stuff.

Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8 uint8;"...

address: instead of void* - an unsigned integer in the address width of the destination platform i.e. uint32 or uint64... address/pointer as memory block size in one.

int: is always "signed address" (address width of platform), but not treated as
a pointer.

filesize: an unsigned integer in the width of a filesize of the destination platform.

dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
to the base 10 for avoiding conversion errors between decimal float point values
and IEEE 754

"float" and "double" are o.k. float32/float64 would be more systematical.

- porting to D stays easy, simply add a typedef-header...

---

treating the data types like a class is a good idea (e.g. char.size char.max)

---

strings should be better classes - invent a new standard class.

The disadvantage of a compiler string type is, that it can't be extended, e.g. from ASCII to UTF8 or UTF16...

Resizing strings this way: string.length = ... is bad style; such must be done by a member function; further "length" is the length of the string, not the memory that has been allocated for.

---

I don't see any sense in the use of "interfaces" - this is just an invention of M$ making programming much more incompatible. But couldn't this really not be done by classes/member functions ?

---

Linking libraries by a simple "import" keyword instead of #including a header file and add the respective library to the linker settings is a good idea.

---

Doing without macros/preprocessor instructions is a bad idea. You can't do everything just with functions. A simple example is conditional compiling, e.g. debug stuff in debug builds...

I'd make "import" to a preprocessor instruction - and think "#using" is a better expression.

---

The advantage of prototypes/declarations was that it forced the programmers to write down all functions in some kind of overview, which lead to the first code documentation.

---

Memory managment should be the job of the debugger/library. If someone really doesn't care about the memory usage, his program shall crash, or he shall use BASIC.

At least functions like free() and delete/destructors shall stay for the clean
programmers.

Mr. B.B.C. wrote:

> Some suggestions for D:
> 
> data types:
> use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned char" "short" and so on, especially instead of "long long" and other stuff.

That would be taking a step back.  byte and char, short and wchar, int
and dchar weren't distinguished for nothing.

> Perhaps you may include even a "uint8" or let this make a "typedef
> unsigned int8 uint8;"...

'unsigned' is not a D keyword.  Have you even read the docs?

> address: instead of void* - an unsigned integer in the address width of the destination platform i.e. uint32 or uint64... address/pointer as memory block size in one.

That's exactly what a pointer is.

> int: is always "signed address" (address width of platform), but not
> treated as a pointer.

You mean that's your misunderstanding, or what you want it to be?

<snip>
> strings should be better classes - invent a new standard class.
> 
> The disadvantage of a compiler string type is, that it can't be extended, e.g. from ASCII to UTF8 or UTF16...

How do you work that out?

> Resizing strings this way: string.length = ... is bad style; such must be done by a member function; further "length" is the length of the string, not the memory that has been allocated for.

Are you a language purist?

> I don't see any sense in the use of "interfaces" - this is just an invention of M$

Actually, I think $un got there first.

> making programming much more incompatible.

Would you care to elaborate?

> But couldn't this really not be done by classes/member functions ?

If Walter had convoluted the language to support multiple inheritance,
it could.  But he hasn't, and for a reason.

<snip>
> Doing without macros/preprocessor instructions is a bad idea. You can't do everything just with functions. A simple example is conditional compiling, e.g. debug stuff in debug builds...

Troll alert!

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the
unfortunate victim of intensive mail-bombing at the moment.  Please keep
replies on the 'group where everyone may benefit.

>Some suggestions for D:
>
>data types:
>use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
>char" "short" and so on, especially instead of "long long" and other stuff.
>
>Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8 uint8;"...

There is no typeunsigend char, nor long long., so what are you talking about? look at http://www.digitalmars.com/d/type.html


>address: instead of void* - an unsigned integer in the address width of the destination platform i.e. uint32 or uint64... address/pointer as memory block size in one.

???

>int: is always "signed address" (address width of platform), but not treated as
>a pointer.

What is a sigend address.

>
>filesize: an unsigned integer in the width of a filesize of the destination platform.

Valid point. at the moment it's uint (32Bit) whih isn't enough.

>dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
>to the base 10 for avoiding conversion errors between decimal float point values
>and IEEE 754

Write your own class.


>"float" and "double" are o.k. float32/float64 would be more systematical.
>

D wants to look like C, so this isn't an option.

>- porting to D stays easy, simply add a typedef-header...

porting what?


>treating the data types like a class is a good idea (e.g. char.size char.max)
>

They arent. Ever tried

int foo = new int();


>The disadvantage of a compiler string type is, that it can't be extended, e.g. from ASCII to UTF8 or UTF16...

Don't get it.


>Resizing strings this way: string.length = ... is bad style; such must be done by a member function; further "length" is the length of the string, not the memory that has been allocated for.


In D methods with only one argument can be called using the assignment operator:

class Foo {
public void length (int x) {}
}


Foo foo = new Foo();
foo.length = 44;


So enforcing another synthax would be very inconsistent. So this is a very bad idea.

>I don't see any sense in the use of "interfaces" - this is just an invention of M$ making programming much more incompatible. But couldn't this really not be done by classes/member functions ?

M$ didn't invent interfaces. Thy took them from Java and there were languages
before that had some kind of interface/protocoll.
And no, it can't be done using classes, as D only supports single inheritance.


>Linking libraries by a simple "import" keyword instead of #including a header file and add the respective library to the linker settings is a good idea.

You don't link librarys using import.


>Doing without macros/preprocessor instructions is a bad idea. You can't do everything just with functions. A simple example is conditional compiling, e.g. debug stuff in debug builds...

Learn the basics of the language before you criticiese something!!! There is "version".


>I'd make "import" to a preprocessor instruction - and think "#using" is a better expression.

But import does something that can't be done by a preprocessor. So this is plain stupid.

>The advantage of prototypes/declarations was that it forced the programmers to write down all functions in some kind of overview, which lead to the first code documentation.

You have to write down everything twice at different places. That makes it harder to change something. You are the first person I know that likes redundancy.

>Memory managment should be the job of the debugger/library. If someone really doesn't care about the memory usage, his program shall crash, or he shall use BASIC.

(ironic)Of course, memory management is done by the debugger.(/ironic)
Do you know anything about coding?

>At least functions like free() and delete/destructors shall stay for the clean
>programmers.

What could you do what you can't using auto and/or self written allocators/deallocators?


Damn, this was the most stupid thread for a long time.

In doc , D has a type alias named "alias";
So you can write a type defined module like that

alias byte int8;
alias short int16;
alias int int32;
and let's go with the source ;)

int32 temp;
temp=32432; ettc...

I see it but I never try it ;) short and int are enough for me .
btw , the int32 seems like the one come from Delphi and HLA . D'you a HLA user ?
In article <c24l04$lrg$1@digitaldaemon.com>, Mr. B.B.C. says...
>
>Some suggestions for D:
>
>data types:
>use int8, int16, int32, int64, int128 and so on instead of "char" "unsigned
>char" "short" and so on, especially instead of "long long" and other stuff.
>
>Perhaps you may include even a "uint8" or let this make a "typedef unsigned int8 uint8;"...
>
>address: instead of void* - an unsigned integer in the address width of the destination platform i.e. uint32 or uint64... address/pointer as memory block size in one.
>
>int: is always "signed address" (address width of platform), but not treated as
>a pointer.
>
>filesize: an unsigned integer in the width of a filesize of the destination platform.
>
>dec64, dec128 - decimal data types, i.e. decimal factor(3/4) and exponent(1/4)
>to the base 10 for avoiding conversion errors between decimal float point values
>and IEEE 754
>
>"float" and "double" are o.k. float32/float64 would be more systematical.
>
>- porting to D stays easy, simply add a typedef-header...
>
>---
>
>treating the data types like a class is a good idea (e.g. char.size char.max)
>
>---
>
>strings should be better classes - invent a new standard class.
>
>The disadvantage of a compiler string type is, that it can't be extended, e.g. from ASCII to UTF8 or UTF16...
>
>Resizing strings this way: string.length = ... is bad style; such must be done by a member function; further "length" is the length of the string, not the memory that has been allocated for.
>
>---
>
>I don't see any sense in the use of "interfaces" - this is just an invention of M$ making programming much more incompatible. But couldn't this really not be done by classes/member functions ?
>
>---
>
>Linking libraries by a simple "import" keyword instead of #including a header file and add the respective library to the linker settings is a good idea.
>
>---
>
>Doing without macros/preprocessor instructions is a bad idea. You can't do everything just with functions. A simple example is conditional compiling, e.g. debug stuff in debug builds...
>
>I'd make "import" to a preprocessor instruction - and think "#using" is a better expression.
>
>---
>
>The advantage of prototypes/declarations was that it forced the programmers to write down all functions in some kind of overview, which lead to the first code documentation.
>
>---
>
>Memory managment should be the job of the debugger/library. If someone really doesn't care about the memory usage, his program shall crash, or he shall use BASIC.
>
>At least functions like free() and delete/destructors shall stay for the clean
>programmers.
>
>