Hi..

>> I think it should rather be the other way around:
>> int8 should be the internal type, with "byte" as an alias.
>
> I think that ship has sailed, like a few years ago... Besides, it would work the same in the end wouldn't it?

Well, yes, but all those aliases will prevent you from using those identifiers for other purposes. It's like all those #undef 's I have to type to prevent conflicts when including windows.h (Is there an 'unalias' by the way?). That's why the built-in names should actually be the only ones; only aliased to ease a transition from C to D.

It just feel 'the wrong way around' for me that the compiler uses platform dependent names and you have to use aliases (different on different platforms) to end up with the same struct, interface.

> How about changing { for BEGIN and } for END,
> or using := for assignment and = for equality ?

Just giving other extreme suggestions doesn't really built a case against mine.

>> The only types that actually mean something are bit, "int" for integers and "float" for floating point numbers. The others are basically based on these.
>
> Yup. And "char" should probably be renamed as "codeunit", too. (Since there are no characters in technical Unicode lingo...)
>
> Only problem is that the "float" precision is too poor, just like the "int" was - back when it was a 16-bit type...
>
> So today, int and double are now the "standard" types  - short and float can be used when space/time is an issue more than precision and long and extended can both be used if the hardware so allows (i.e. on a 64-bit / X86 machine) and bit and byte are provided for other special uses
>
>> Weren't "short" and "long" originally meant as type modifiers? "short int" for a 16-bit number, "long int" for a "longer than normal" (multi-register) 64-bit number. "double float" for a float with double precision? What about "short real" for float and "long real" for a double?
>
> That was then, this is now. And two-word keywords are *not* in D. (and a "long int" was a 32-bit type, the "long long" was 64-bits)

Read on, you yourself wrote about "signed int" and "complex real". What's the difference with "short int" ?

> Shouldn't that include "regular int" and "single float" too then ? Then you can have "unsigned regular int" and "imaginary single float"

Hey, I'm making a case for fewer keywords, not more :-)

> But complex is now a type modifier: "complex float" (cfloat)
> A lot like "unsigned integer" (uint) or "wide character" (wchar).

That's nice, but just as "long int" became simply "long", there's nothing that prevents "complex real" to become simply "complex" (seeing as there's no use for 'complex int' and even "complex float" will be of little use, because complex is used during big calculations, needing a lot of precision).

> Which reminds me, there is no boolean type. Live with it :-)

Hey, if it looks like a bool and it 'walks' like a bool, then I'm happy :-)

> How about "There are more important things to fix before release" ?

Uhm - then what's your post all about?

> And it would be nice if cent and ucent could be hacked in, so that
> I can get a type with 16-byte alignment to use for the vector types...
> (for linking to SIMD extensions outside of D, such as AltiVec or SSE)

You have to agree that it makes more sense to add "int128" to the language, and an alias "cent" (whatever that's derived from).

What will "int256" be called? Why all those new names?
Seriously: is D primarily meant for C/C++ programmers that got tired of
strcpy, ->, malloc/free?

Lionello.

Alex Stevenson wrote:

>> No, but in reality the type is *always* 80 bits (when implemented)
>>
>> It's just that on CPU platforms that *do not have* the type, it falls
>> back to using one or two doubles (which is better than simply failing)
>>
>> On the offical platforms, it's always 80 bits. (Win32 and Linux X86)
> 
> Hmm, all I can find in the D spec is this note in http://www.digitalmars.com/d/type.html is:
> 
> "real : largest hardware implemented floating point size (Implementation Note: 80 bits for Intel CPU's)"
> 
> This suggests to me that while on x86 platforms it should be 80 bits, but on other platforms it will change.

Correct. It uses the C type "long double", so it depends on the
implementation of that type. Mac OS X does not have it, so GDC
simply uses the regular "double" type instead - for that type too.

Other platforms with PowerPC or Sparc processors might have
a standard library that implements a "long double" using
two double registers (making it 128 bits), just as they now
implement a "long long" (64-bit integer) using two 32 bit
registers, unless the platform processor is a 64-bit one ?
And that's "hardware support", as far as DMD is concerned.

Note: DMD/GDC is written in C++, and not in D itself...

> This is fine while D only officially supports x86 platforms, but this situation isn't guaranteed to hold forever.
> 
> Plus should the language spec really limit the hardware platform? The situation as I understood it was:
> 
> D Language Spec: Does not limit to specific platforms (but provides implementation guidance)
> DMD compiler: Supports x86 Linux/Win32 only
> GDC : Supports x86/Mac/Solaris
> 
> If my understanding is correct, the 'always 80-bit' assumption is based on the DMD compiler rather than the D language spec.

The D specification does not limit the hardware platform.

It just says the "biggest precision available", and that
will be one of 64 or 80 or 128 bits depending on CPU...

But "float80_t" is just an alias, so it can be the same ?
(I do not think it has much use in reality, since one might
as well use the more verbose: "real", "imaginary", "complex"
that doesn't have the same false implementation hints...)


The size of e.g. (void*) is not fixed either. It's usually
32 bits now, but can become 64 bits any day on the 64-bit
platforms (that is: "version(AMD64)" or "version(PPC64)")

http://www.digitalmars.com/d/version.html
http://www.prowiki.org/wiki4d/wiki.cgi?DocComments/Version


There are currently some "char" issues in C with building
GDC on Linux PPC platforms, but David is working on that...

Solaris was finally added after fixing alignment issues
in DMD that caused crashes (!) with the Sparc processor.

So the list above should have been:
GDC : Supports Linux/Mac OS X/Solaris
(since GDC does not support Mac OS 9)

Currently GDC does not support inline assembler either,
since it needs to be tied in with the D variables and such

--anders

Lionello Lunesu wrote:

> Well, yes, but all those aliases will prevent you from using those identifiers for other purposes. It's like all those #undef 's I have to type to prevent conflicts when including windows.h (Is there an 'unalias' by the way?). That's why the built-in names should actually be the only ones; only aliased to ease a transition from C to D.

That was actually another reason for the _t suffixes in stdint.

> It just feel 'the wrong way around' for me that the compiler uses platform dependent names and you have to use aliases (different on different platforms) to end up with the same struct, interface.

Just the way Walter designed the language, I suppose.

>>How about changing { for BEGIN and } for END,
>>or using := for assignment and = for equality ?
> 
> Just giving other extreme suggestions doesn't really built a case against mine.

No, that was called something in the meta-discussion language...
Not "strawman", but something else? I'll try to stay on topic :-)

>>That was then, this is now. And two-word keywords are *not* in D.
>>(and a "long int" was a 32-bit type, the "long long" was 64-bits)
> 
> Read on, you yourself wrote about "signed int" and "complex real". What's the difference with "short int" ?

Walter didn't like it, and replaced it with "short" which was
an allowed abbrevation in regular C. Java uses the same thing.

And that is nice, makes D easier to understand for Java programmers,
especially for people who started programming with Java (a lot now)
but want something closer to the machine and think C is "too low"...

The main differences to Java is: "boolean" -> "bit", and "char" -> wchar
(and java does not have the "extended" float or "cent" int types either)

>>Shouldn't that include "regular int" and "single float" too then ?
>>Then you can have "unsigned regular int" and "imaginary single float"
> 
> Hey, I'm making a case for fewer keywords, not more :-)

I don't think shorter keywords that make up bigger ones
are coming back into fashion. At least not before D 1.0 ?

>>But complex is now a type modifier: "complex float" (cfloat)
> 
> That's nice, but just as "long int" became simply "long", there's nothing that prevents "complex real" to become simply "complex" (seeing as there's no use for 'complex int' and even "complex float" will be of little use, because complex is used during big calculations, needing a lot of precision).

It actually *was* "complex", before the float and double versions
were added. When they were, it changed from "complex" to "c".

The only mistake was introducing the new "imaginary real" type...
(which came as a unfortunate side effect of changing "extended")

>>Which reminds me, there is no boolean type. Live with it :-)
> 
> Hey, if it looks like a bool and it 'walks' like a bool, then I'm happy :-)

The bool type is alright. The issue is just with if(0) and if(null)...

>>How about "There are more important things to fix before release" ?
> 
> Uhm - then what's your post all about?

Three new std alias modules, and a DMD change from "real" to "extended"
A few dozen lines of source code in total, and pretty trivial as well.

Not rewriting the names of the built-in types, or something like that?

>>And it would be nice if cent and ucent could be hacked in, so that
>>I can get a type with 16-byte alignment to use for the vector types...
>>(for linking to SIMD extensions outside of D, such as AltiVec or SSE)
>
> You have to agree that it makes more sense to add "int128" to the language, and an alias "cent" (whatever that's derived from).

But "cent" is already in the language, and has been for some time ?

(and I don't think types with integer suffixes are a good idea, no)

> What will "int256" be called? Why all those new names?

I don't see any need for any more types, no.
But 128-bit registers are a reality today...

And std.stdint was written by Walter Bright,
and comes ported over from standard C99 / C++

I just extended it with the logical int128_t

> Seriously: is D primarily meant for C/C++ programmers that got tired of strcpy, ->, malloc/free?

I think so ? At least that's the way that I am using it, to stay off C++

It also has a large potential for Java programmers that want more speed.

--anders

Anders F Björklund wrote:

> Norbert Nemec wrote:
> 
>>>Here is the full list of my suggested type aliases for D:
>>>
>>>Integer: (std.stdint)
>>>    byte        int8_t  // 8-bit signed
>>>   ubyte       uint8_t  // 8-bit unsigned (0x00-0xFF)
>> 
>> [...]
>> 
>> are those _t suffices really needed?
> 
> There are two reasons:
> 
> 1) to avoid mixing them up with integers.
> 
>     int8_t x = 8;
>     int16_t y = 16;
>     int32_t z = 32;

I don't understand at all. What might someone mix up and where does the _t help? Of course, people have to think when reading the above lines, but I see no special danger of mixing anything up.

> 2) They are already in use, in ISO C99...
> 
>     #include <stdint.h>

OK, but I never really liked that _t thing in the C libraries. It makes sense for identifiers that do not necessarily sound like a type ('size_t', 'date_t' and so on) but int, float & Co. immediately look like a type to anyone who has ever worked in C.

Probably a pure matter of taste...

Norbert Nemec wrote:

>>There are two reasons:
>>
>>1) to avoid mixing them up with integers.
>>
>>    int8_t x = 8;
>>    int16_t y = 16;
>>    int32_t z = 32;
> 
> I don't understand at all. What might someone mix up and where does the _t
> help? Of course, people have to think when reading the above lines, but I
> see no special danger of mixing anything up.

I think it was mostly with cast(int8) and such expressions, but I'm not
sure myself to be honest. :-) I know it was discussed on this newsgroup
in great length (as usual), so search the archives for it perhaps ?

I do know that "int8" and friends were forever rejected as a D type...
(similar to how boolean conditionals and a String class are rejected)

>>2) They are already in use, in ISO C99...
>>
>>    #include <stdint.h>
> 
> OK, but I never really liked that _t thing in the C libraries. It makes
> sense for identifiers that do not necessarily sound like a type ('size_t',
> 'date_t' and so on) but int, float & Co. immediately look like a type to
> anyone who has ever worked in C. 
> 
> Probably a pure matter of taste...

Probably, and there aren't any debate of e.g. the sizes of int and wchar
in D, but int32_t and utf16_t makes it self-explanatory which is which ?
(they are also a *compromise* between SInt32 and INT32 and all variants)

Having both (at the same time) is a matter of appealing to both...

Note that std.stdint is *not* imported by default, so you still have
to explicitly import it to get the alias types. Ditto with std.stdfloat,
and probably the proposed stdbool and stdstr as well - although the
suggestion is that "bool" and "str" aliases should always be defined.
The more esoteric wbool and dbool and wstr and dstr can be imported
explicitly, if wants to use them over the built-in types they represent.

Just that newcomers to D do find "bool" easier than bit,
and might just find "str" easier than the actual char[] ?

Then, when they are ready for it, you can slap them with the full
bool/wbool/dbool and str/wstr/dstr performance considerations...
Simple to begin with, but still with all the options open later ?

--anders

"Norbert Nemec" <Norbert@Nemec-online.de> wrote in message news:cuibd3$1v0o$1@digitaldaemon.com...
> Anders F Björklund wrote:
>
> > Norbert Nemec wrote:
> >
> >>>Here is the full list of my suggested type aliases for D:
> >>>
> >>>Integer: (std.stdint)
> >>>    byte        int8_t  // 8-bit signed
> >>>   ubyte       uint8_t  // 8-bit unsigned (0x00-0xFF)
> >>
> >> [...]
> >>
> >> are those _t suffices really needed?
> >
> > There are two reasons:
> >
> > 1) to avoid mixing them up with integers.
> >
> >     int8_t x = 8;
> >     int16_t y = 16;
> >     int32_t z = 32;
>
> I don't understand at all. What might someone mix up and where does the _t help? Of course, people have to think when reading the above lines, but I see no special danger of mixing anything up.
>

I' don't like those t's either. int8_t wouldn't get my vote but int 8 would.

> > 2) They are already in use, in ISO C99...
> >
> >     #include <stdint.h>
>
> OK, but I never really liked that _t thing in the C libraries. It makes sense for identifiers that do not necessarily sound like a type ('size_t', 'date_t' and so on) but int, float & Co. immediately look like a type to anyone who has ever worked in C.
>
> Probably a pure matter of taste...
>

Ivan Senji wrote:

>>>>>Here is the full list of my suggested type aliases for D:
>>>>>
>>>>>Integer: (std.stdint)
>>>>>   byte        int8_t  // 8-bit signed
>>>>>  ubyte       uint8_t  // 8-bit unsigned (0x00-0xFF)
>>
>>I don't understand at all. What might someone mix up and where does the _t
>>help? Of course, people have to think when reading the above lines, but I
>>see no special danger of mixing anything up.
> 
> I' don't like those t's either. int8_t wouldn't get my vote but int 8 would.

int8_t has already been added to std.stdint long ago*, it's a bit late ?

It also rhymes with size_t, time_t, pthread_t, ptrdiff_t, wchar_t etc...

--anders

* Like five years ago, or something ? At least in regular ISO C and C++.

Anders F Björklund wrote:
> Ivan Senji wrote:
> 
>>>>>> Here is the full list of my suggested type aliases for D:
>>>>>>
>>>>>> Integer: (std.stdint)
>>>>>>   byte        int8_t  // 8-bit signed
>>>>>>  ubyte       uint8_t  // 8-bit unsigned (0x00-0xFF)
>>>
>>>
>>> I don't understand at all. What might someone mix up and where does the _t
>>> help? Of course, people have to think when reading the above lines, but I
>>> see no special danger of mixing anything up.
>>
>>
>> I' don't like those t's either. int8_t wouldn't get my vote but int 8 would.
> 
> 
> int8_t has already been added to std.stdint long ago*, it's a bit late ?

That's too bad.

> It also rhymes with size_t, time_t, pthread_t, ptrdiff_t, wchar_t etc...
> 
> --anders
> 
> * Like five years ago, or something ? At least in regular ISO C and C++.

I agree with Norbert. type_t seems so ugly. To me it ranks up there
with Hungarian notation for ugliness. I always hated size_t, time_t,
etc. Please, keep D easy on the eyes.

Jason

Jason Mills wrote:

>> It also rhymes with size_t, time_t, pthread_t, ptrdiff_t, wchar_t etc...
>>
> I agree with Norbert. type_t seems so ugly. To me it ranks up there
> with Hungarian notation for ugliness.

Most of these are totally optional extras, or portability aliases.
So you don't have to use them, if you find them visually apalling ?

The only aliases suggested for defining always are:  bool,  str

The rest would be available as optional modules, import if you want.
(as usual, there's always the risk of someone else using them, but)

Of course, there is also the issue of changing "real" type back to
"extended" again, just to avoid the silly "imaginary real" (ireal)

>  I always hated size_t, time_t, etc. Please, keep D easy on the eyes.

But if you've always hated C, then maybe D will always be ugly too ?

(I know, "_t" is more Unix and Posix than it is C. But they're related)

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cuhudm$1gla$2@digitaldaemon.com...
> Revised,
> Here is the full list of my suggested type aliases for D:
>
>    TYPE        ALIAS   // RANGE
>
>    void                // void
>
> Integer: (std.stdint)
>    byte        int8_t  // 8-bit signed
>   ubyte       uint8_t  // 8-bit unsigned (0x00-0xFF)
>
>   short       int16_t  // 16-bit signed
>  ushort      uint16_t  // 16-bit unsigned (0x0000-0xFFFF)
>
>     int       int32_t  // 32-bit signed
>    uint      uint32_t  // 32-bit unsigned (0x00000000-0xFFFFFFFF)
>
>    long       int64_t  // 64-bit signed (could be two int registers)
>   ulong      uint64_t  // 64-bit unsigned (could be two uint registers)
>
>    cent      int128_t  // 128-bit signed (reserved for future use)
>   ucent     uint128_t  // 128-bit unsigned (reserved for future use)

These are already done, right? I can't remember.

> Floating Point: (std.stdfloat)
>      float  float32_t  // 32-bit single precision (about 6 digits)
>     double  float64_t  // 64-bit double precision (about 15 digits)
>   extended  float80_t  // 64/80/128-bit extended precision (platform)
>
>     ifloat   imag32_t  // \
>    idouble   imag64_t  // imaginary versions of the above real ones
>  iextended   imag80_t  // /
>
>     cfloat   comp32_t  // \
>    cdouble   comp64_t  // complex (with both real and imaginary parts)
>  cextended   comp80_t  // /
>
> Character: (std.stdutf)
>    char        utf8_t  // \x00-\x7F (ASCII)
>   wchar       utf16_t  // \u0000-\uD7FF, \uE000-\uFFFF
>   dchar       utf32_t  // \U00000000-\U0010FFFF (Unicode)
>
> Boolean: (std.stdbool)
>     bit          bool  // false (0) | true (1)
>    byte         wbool  // false (zero) | true (non-zero)
>     int         dbool  // false (zero) | true (non-zero)

The module std.stdint is defined because C programmers will look for it - and it has some useful "fast" and "least" aliases etc. I haven't heard of people needing these float, char or bool aliases except for individual naming preferences. The argument for including them is different that the argument for including std.stdint. I'd be hesitent to define wbool and dbool unless they have some boolean behaviors (eg it would confusing that cast(wbool)10 != cast(wbool)20)

> String: (std.stdstr)
>   char[]          str    // UTF-8, optimized for US-ASCII
>  wchar[]         wstr    // UTF-16, optimized for Unicode
>  dchar[]         dstr    // UTF-32, easy codepoint access

"str" is a common variable name for strings. Plus it would hide the array semantics.

[snip]