Ben Hinkle wrote:

>>Here is the full list of my suggested type aliases for D:
>>
>>Integer: (std.stdint)
> 
> These are already done, right? I can't remember.

They are, except "cent" which is not implemented.

But they are done, with the _t suffix, and the
versions without the suffix has *not* been added
even if suggested multiple times over 3 years time.

See the thread list at the top of this page:
http://www.prowiki.org/wiki4d/wiki.cgi?StdTypeAliases

>>Floating Point: (std.stdfloat)
> 
> 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.

That's why it's just a suggestion...

But if it is to be, better be the same all over ?
(which is why I posted it to the group, yet again)

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

All the bool types use the Zero-Is-False ideom.
(the inequality above would still be true)

This would still "work", though:
assert(cast(wbool)10 && cast(wbool)20));


It's not in any way a boolean type for D, which is
something that Walter (and thus D) does *not* want...

But the suggestion was to spare the "weirdo"
wbool/dbool and wstr/dstr for explicit imports:
import std.stdbool; import std.stdstr;

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

But this code still works just fine:

alias char[] str;

void main()
{
  str str = "str";
}

And it would hide the array semantics, which can
be saved for later... str s = "hello," ~ "world!";
can be an easy start, just as void main(str[] args);

But yes, hiding that is half of the point.
(shortness of writing it being the other)

It's not a String struct/class, though.
That's something else D does not want...


It's not exactly a new issue, and this my last posting
is my final attempt to bring the issues to closure...
I'm not sure I will "succeed", but I won't try again.

"bool" is currently always defined, thankfully, and
I can just continue to just define "str" locally...
(and just "do an Arcane Jill" and get the hell out)


I've also tried to document boolean and strings in D,
something that bit and char[] haven't really helped ?

It's much easier in e.g. Java, but I do think that D's
types are an improvement over the C types (_Bool / char*)

--anders

PS.
"imaginary real" is still very very silly, though. IMHO.

In article <cuj2ro$2ofe$1@digitaldaemon.com>, Ben Hinkle says... <snip>
>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.

All salient points ...

In article <cuj45t$2pf3$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>>>  char[]          str    // UTF-8, optimized for US-ASCII
>>> wchar[]         wstr    // UTF-16, optimized for Unicode
>>> dchar[]         dstr    // UTF-32, easy codepoint access

Just a thought: how about naming those utf8, utf16, utf32, instead?

> I can just continue to just define "str" locally...
> (and just "do an Arcane Jill" and get the hell out)

Heck; don't do that ... for all the nice "Norman Rockwell" praise this NG ocassionally gets, it is often a most despairing place to suggest "change". FWIW: I find that those who disagree are the only vocal ones -- those who agree just don't say anything, publicly -- a somewhat strange arrangement that often caters mostly to the squeaky wheels. It can be frustrating.

> I've also tried to document boolean and strings in D, something that bit and char[] haven't really helped ?

You try to do something nice for the community, yet some focker goes and cuts the heads off the flowers.

What you're doing is cool. D has more facial warts than Lemmy -- they could have been removed long ago, but the patient has this argumentative multiple personality disorder.

>"imaginary real" is still very very silly, though. IMHO.

Certainly is :-)

Kris wrote:

>>>> char[]          str    // UTF-8, optimized for US-ASCII
>>>>wchar[]         wstr    // UTF-16, optimized for Unicode
>>>>dchar[]         dstr    // UTF-32, easy codepoint access
> 
> Just a thought: how about naming those utf8, utf16, utf32, instead?

I used those names for the individual code units instead...

"utf8string" or something could have been used,
but I just thought it to be much too technical.

I wanted the integer / float types to be techy,
and the boolean and string types to be simple ?

>>I can just continue to just define "str" locally...
>>(and just "do an Arcane Jill" and get the hell out)
> 
> Heck; don't do that ... for all the nice "Norman Rockwell" praise this NG
> ocassionally gets, it is often a most despairing place to suggest "change".
> FWIW: I find that those who disagree are the only vocal ones -- those who agree
> just don't say anything, publicly -- a somewhat strange arrangement that often
> caters mostly to the squeaky wheels. It can be frustrating.

Well, it was only half-true... I'm going on vacation :-)

I'll be back to check up on you guys later, upon return.

> What you're doing is cool. D has more facial warts than Lemmy -- they could have
> been removed long ago, but the patient has this argumentative multiple
> personality disorder.

Well, it's mostly because some wants D to become
"kewler than C#" or "easier than Java" when all it
wants is to become a better C and a simpler C++ ?

To myself, D fits just greatly between C and Java.
(I'm trying to avoid C++ and C# as much as I can)

--anders

"Anders F Björklund" <afb@algonet.se> wrote in message news:cuj45t$2pf3$1@digitaldaemon.com...
> Ben Hinkle wrote:
>
>>>Here is the full list of my suggested type aliases for D:
>>>
>>>Integer: (std.stdint)
>>
>> These are already done, right? I can't remember.
>
> They are, except "cent" which is not implemented.
>
> But they are done, with the _t suffix, and the
> versions without the suffix has *not* been added
> even if suggested multiple times over 3 years time.
>
> See the thread list at the top of this page: http://www.prowiki.org/wiki4d/wiki.cgi?StdTypeAliases

I scanned the rest of the thread before posting so I missed the updated update about not having _t.  Those int32 etc names were needed in C because of the unknown int sizes. Technically they aren't needed in D. IIRC Java and C# don't have aliases for "int" and friends. If you want a double in Java you say "double". If Walter wanted to change the _t's in std.stdint to non-_t's then that would be fine. One question I have is when should one use these aliases? In typical code or do you see them mostly used for special situations? I don't really know when I'd use those aliases.

>>>Floating Point: (std.stdfloat)
>>
>> 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.
>
> That's why it's just a suggestion...
>
> But if it is to be, better be the same all over ?
> (which is why I posted it to the group, yet again)

That's fine. Though right now the "same all over" are the standard names like "int", "double", etc. The case for "bool" being an alias for "bit" was strong. The case for a standard "float64" as an alias for "double" is much weaker IMO. I'm perfectly fine with personal aliases for things - people can do what they want. But to put it in std.stdfloat you have to have a strong case that many people would benefit from the name.

>> 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)
>
> All the bool types use the Zero-Is-False ideom.
> (the inequality above would still be true)

replace wbool with bool and the inequality is false.

> This would still "work", though:
> assert(cast(wbool)10 && cast(wbool)20));

true.

> It's not in any way a boolean type for D, which is something that Walter (and thus D) does *not* want...

The "bit" type has boolean behavior. It can only take on two values. The "byte" type can take many values and so it does not have boolean behavior.

> But the suggestion was to spare the "weirdo"
> wbool/dbool and wstr/dstr for explicit imports:
> import std.stdbool; import std.stdstr;

ok, but still in std, no?

>>>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.
>
> But this code still works just fine:
>
> alias char[] str;
>
> void main()
> {
>   str str = "str";
> }

shudder. :-)

> And it would hide the array semantics, which can
> be saved for later... str s = "hello," ~ "world!";
> can be an easy start, just as void main(str[] args);
>
> But yes, hiding that is half of the point.
> (shortness of writing it being the other)
>
> It's not a String struct/class, though.
> That's something else D does not want...
>
>
> It's not exactly a new issue, and this my last posting
> is my final attempt to bring the issues to closure...
> I'm not sure I will "succeed", but I won't try again.
>
> "bool" is currently always defined, thankfully, and
> I can just continue to just define "str" locally...
> (and just "do an Arcane Jill" and get the hell out)

I don't mean to be discouraging and I hope you don't abandon playing around with D and proposing changes. That's not the way D will get better. I posted to say what I see as some issues with the proposal. For example I'm all for a wbool but it should have boolean behavior. I would be for standardized names but not if we are going to keep the already-standard names. Aliases should be introduced carefully.

> I've also tried to document boolean and strings in D, something that bit and char[] haven't really helped ?

That was very nice to see.

> It's much easier in e.g. Java, but I do think that D's types are an improvement over the C types (_Bool / char*)
>
> --anders
>

> PS.
> "imaginary real" is still very very silly, though. IMHO.

yup

Ben Hinkle wrote:

> I scanned the rest of the thread before posting so I missed the updated update about not having _t.  Those int32 etc names were needed in C because of the unknown int sizes. Technically they aren't needed in D. IIRC Java and C# don't have aliases for "int" and friends. If you want a double in Java you say "double". If Walter wanted to change the _t's in std.stdint to non-_t's then that would be fine. One question I have is when should one use these aliases? In typical code or do you see them mostly used for special situations? I don't really know when I'd use those aliases.

I mostly tossed in the floats for "completeness", I don't know either :)
Just thought them a nice complement to the integer ones already there ?

And I agree there is a much weaker case in D, compared to what C has...

>>But if it is to be, better be the same all over ?
>>(which is why I posted it to the group, yet again)
> 
> That's fine. Though right now the "same all over" are the standard names like "int", "double", etc. The case for "bool" being an alias for "bit" was strong. The case for a standard "float64" as an alias for "double" is much weaker IMO. I'm perfectly fine with personal aliases for things - people can do what they want. But to put it in std.stdfloat you have to have a strong case that many people would benefit from the name.

The only strong argument I have is that "creal" and "ireal" are silly,
but changing that back to "extended" will do, without adding stdfloat ?

The ones I was more proud of were the utf#_t ones for char/wchar/dchar.

>>>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)
>>
>>All the bool types use the Zero-Is-False ideom.
>>(the inequality above would still be true)
> 
> replace wbool with bool and the inequality is false.

I think I wrote that poorly. I just meant what's below:

>>This would still "work", though:
>>assert(cast(wbool)10 && cast(wbool)20));
> 
> true.

Which means that 10 is still "true", assert(10);
and that 20 is also still "true", assert(20);
but *not* that 10 == 20, the way 1 == 1 for bit

And that works just like it does in C and C++.

>>It's not in any way a boolean type for D, which is
>>something that Walter (and thus D) does *not* want...
> 
> The "bit" type has boolean behavior. It can only take on two values. The "byte" type can take many values and so it does not have boolean behavior.

Bit is fine as a boolean type, exactly for that reason. And it also has
the weird non-integer casting behaviour in that 2 becomes 1 when put in
a bit variable - if you put 256 in a byte it's 0, 65536 in a short too.

But bit's OK for "bool", now that it can be addressed and used as inout.

However, both byte and int can also only have two values:
zero and non-zero, and that's what I wrote in the table and
how D uses them. (byte are a good substitute for addressable
arrays, and int is already being used in e.g. opEquals etc)

The aliases were just a tongue-in-cheek documentation of those facts...

>>But this code still works just fine:
>>
>>alias char[] str;
>>
>>void main()
>>{
>>  str str = "str";
>>}
> 
> shudder. :-)

So it shouldn't break any existing code, if "str" was in object.d ?

> I don't mean to be discouraging and I hope you don't abandon playing around with D and proposing changes. That's not the way D will get better. I posted to say what I see as some issues with the proposal. For example I'm all for a wbool but it should have boolean behavior. I would be for standardized names but not if we are going to keep the already-standard names. Aliases should be introduced carefully.

* stdfloat is mostly useless, and can be killed at the spot...

* cent types are not needed until cent/ucent keywords are added

* stdutf would be a nice complement to the stdint types...

* wbool and dbool and wstr and dstr are not really needed

* "str" should be added to object.d right next to bool, I think


Order ranking:
1) extended (for "real")
2) str (for "char[]")
3) std.stdutf
4) std.stdbool (ignorable, just a compliment to article)
5) std.stdstr (ignorable, just a compliment to article)
6) std.stdfloat (ignorable)

--anders