String Basics

[Kent Boogaart]

I'm a late entrant on this discussion, but I've only just gotten on the D band
wagon . . .

I think adding a string type has some serious merit. Namely:

1. "string" is a lot easier on the eyes than "char[]", to me at least.
Especially when being used in an associative array:

int[char[]] arr;

versus

int[string] arr;

2. string-specific functions can be added to the string type. I'm a complete D
noob so forgive any misinformation here. Currently I understand there to be a
separate module for string-related functions. To me, there should be a string
type that defines those functions:

char[] upper = toupper(myString);

versus:

string upper = myString.toupper();

The latter seems like much better OO design to me. Side note: I don't understand
the namng of "toupper" as opposed to "toUpper" - isn't camel-casing the norm in
D?

Now arguably developers could just typedef or alias char[] as string and be done
with it. But this doesn't address my second point.

Or they could develop their own string class and be done with it. But this means
that almost every decent-sized D project will have its own string
implementation. Obviously not good.

Regards,
Kent Boogaart


In article <e7oki3$2pfe$1 at digitaldaemon.com>, Stewart Gordon says...
>
>Heinz wrote:
><snip>
>> Thanks guys for your answers. I know it is a basic stuff, i used to work with
>> char[] in lower level languages but now i was used to the string type in managed
>> languages.
>> 
>> I'll use an alias for now but hope Walter to add a string type in phobos.
>
>http://www.digitalmars.com/d/builtin.html
>
>"But after all, what is a string if not an array of characters? If the 
>builtin array problems are fixed, doesn't that resolve the string 
>problems as well? It does. It seems odd at first that D doesn't have a 
>string class, but since manipulating strings is nothing more than 
>manipulating arrays of characters, if arrays work, there's nothing a 
>class adds to it."
>
>Stewart.