Walter Bright Wrote:
> 	alias const(char)[] cstring;
> 
> Why cstring? Because 'string' appears as both a module name and a common variable name. cstring also implies wstring for wchar strings, and dstring for dchars.

I like it all, except the alias.  I would prefer 'string'.  'cstring' implies C's string to me, for example I often alias std.string.toStringz to cstr or CSTR.  I think wstring and dstring are ok, basically I'd like:

char, string
wchar, wstring
dchar, dstring

Is it really a problem that std.string is a module name?

I don't reckon it's a very common variable name, for example:

1. I wouldn't go to the trouble of typing 'string' for a throw away variable when I could use 'p', 's', or 'str'.

2. Likewise for a more long lived variable I would use something more descriptive i.e. nameString, ageString, promptString, boundaryString, ...

Slightly OT:  I think once we have const etc and 'string' working as desired then for many applications there will be no need for a additional String class.

Note that I said 'many applications' above;  I think that those applications that make heavy use of many different text encodings and/or languages may still want a 'String' (or 'Text') class.

This class would provide the extra functionality that aren't inherent in string, wstring, dstring, things like:

1. leveraging iconv (or similar) to handle various encodings.

2. choosing the best internal format string, wstring, dstring for the text based on the language used.

3. slicing on character boundaries regardless of internal format.

.. and probably other things I haven't thought of here.

Regan

Regan Heath Wrote:
> I like it all, except the alias.  I would prefer 'string'.  'cstring' implies C's string to me, for example I often alias std.string.toStringz to cstr or CSTR.  I think wstring and dstring are ok, basically I'd like:
> 
> char, string
> wchar, wstring
> dchar, dstring
> 
> Is it really a problem that std.string is a module name?

</lurk>
Concur
<lurk>