Casting between char[]/wchar[]/dchar[]

[kris]

Hasan Aljudy wrote:
> What are the rules for implicit/explicit casting between char[] and 
> wchar[] and dchar[] ?
> 
> When one casts (explicitly or implicitly) does the compiler 
> automatically invoke std.utf.toUTF*()?
> 
> Here's an idea that should simplify much of string handling in D:
> allow char[] and wchar[] and dchar[] to be castable implicitly to each 
> other, provided that the compiler invokes the appropriate std.utf.toUTF* 
> method.
> I think this is perfectly safe; no data is lost, and string handling can 
> become much more flexable.
> 
> Instead of writing three version of the same funciton for each of char[] 
> wchar[] and dchar[], one can just write a wchar[] version (for example) 
> and the compiler will handle the conversion from/to char[] and dchar[].
> 
> This is also relevies developers from writing templetized 
> functions/class when they deal with strings.
> 
> Thoughts?

This one was beaten soundly around the head & shoulders in the past :)

In a systems language like D, one could argue that hidden conversions 
and/or translations (a) can mask what would otherwise be unintended 
compile-time errors (b) can be terribly detrimental to performance where 
multiple conversions are implicitly applied. Such an environment could 
potentially put C0W to shame in terms of heap abuse -- recall some of 
the recent CoW examples, and sprinkle in a few unintended conversions 
for good measure :)

IIRC, the last time this came up there was a pretty strong feeling that 
such things should be explicit (partly because it can be an expensive 
operation ~ likely sucking on the heap also). Although foreach() will 
convert on the fly, that's perhaps not something one should do with 
extensive chunks of text?

One approach would be to make the Unicode converters more attractive for 
daily use. There are libraries other than Phobos which attempt to do 
just that.

On the other hand, if you're writing some kind of platform where 
convenience is more important than, say, performance, being able to 
/add/ the implicit conversion might be of real value. One might, for 
example, implement such a platform using a String class to abstract the 
encoding differences. Functions could accept said String rather than one 
of the three stooges^H^H^H^H^H^H^H Unicode types.

If I recall correctly, I think Regan was quite keen on implicit Unicode 
conversions (during function calls also), so a google on the subject 
along with his name might get you to the prior threads?

Either way, having the compiler tell you at compile time when you're 
mixing metaphors is a-good-thing (tm). Being able to 'extend' the 
language (via classes or whatever) to implement higher level 
abstractions such as String is also a-good-thing. Having both provides 
for differing uses of D without stepping on toes, or hitting said 
appendages with a hammer

- Kris