Overload resolution for string

[Ali Çehreli]

Steven Schveighoffer wrote:
 > On Sun, 11 Apr 2010 15:33:09 -0400, Ali Çehreli <acehreli at yahoo.com> 
wrote:
 >
 >> This is a bug, right? I've been assuming that unqualified string
 >> literals were immutable char arrays, but the behavior is different
 >> between "hello" vs. "hello"c.
 >>
 >> Am I missing something?
 >
 > "hello" is typed as a string *only* if you are using at a string.  If
 > you are using it as a wstring or a dstring, then it is typed that way.
 > You can even use it as a const(char) * and it becomes an ASCII C-style
 > string with a zero terminator!

I did not know that. :)

Could you please share some guidelines about chosing the type of the 
D-string to use at the interface...

Should applications stick to one of these types and require callers to 
convert explicitly if needed? Should the common type be dstring? On the 
other hand, string seems to be a better choice because classes have the 
common toString member functions that return string.

In my case, I have a set of classes that represent alphabet letters and 
alphabet strings. The motivation is to provide logical sorting and 
capitalization. (To me, even for the English alphabet, â should be 
sorted between a and b.)

Since I want these types to be used as seamlessly as possibly, I wanted 
to provide opEquals overloads for char[], wchar[], and dchar[]. Should I 
not bother doing that? In fact, I really shouldn't due to this compiler 
error.

Should my classes only interface with dchar and dstring?

Thank you,
Ali