"David L. Davis" <SpottedTiger@yahoo.com> wrote in message news:cht3o7$1u1n$1@digitaldaemon.com...
> In article <chaapt$1rac$1@digitaldaemon.com>, antiAlias says...
>>
>>There was some commentary about the benefits of auto-conversion between char[], wchar[] and dchar[], where the compiler will automatically convert array literals as it sees fit. So, for example, if you have a method:
>>
>># void myFunc (wchar[] string) {...}
>>
>>and call it with:
>>
>># myFunc ("a char array");
>>
>>the compiler will convert the literal to a wchar[] instead of a char[]. This is apparently considered a GoodThing. Recently, there's been a lot of talk regarding additional automatic conversion, between UTF8 and its wchar[] and dchar[] representations.
>>
>>Unfortunately, all this implicit conversion conflicts badly with method resolution. For instance, if I have two methods:
>>
>># myFunc (char[] string) { ... }
>># myFunc (wchar[] string) { ... }
>>
>>the compiler now can't tell which one should be called (vis-a-vis the prior example). To get around this, one has to cast the string literal like so:
>>
>># myFunc (cast(wchar[]) "a char array");
>># myFunc (cast(char[]) "a char array");
>>
>>Ugly. What some folks do to get around this is to add different method names for the same functionality, a la Win32:
>>
>># writeString (char[] x);
>># writeStringW (wchar[] x);
>>
>>They are forced into this approach to avoid having to use those ugly casts everywhere. This is what Streams.d does, along with others. Okay, so some might ask why this is a problem? Well, there are certain method names that are fixed in stone by the compiler, and you can't add a suffix even if you wanted to:
>>
>># class MyClass
>># {
>>#     this (char[] initialContent) { ... }
>>#     this (wchar[] initialContent) { ... }
>># }
>>
>>See the problem? The compiler cannot resolve which constructor to use when you write
>>
>># new MyClass ("blah blah blah");
>>
>>Instead, one is forced to use a cast:
>>
>># new MyClass (cast(char[]) "blah blah blah");
>>
>>One can hardly add a "W" suffix to the keyword "this". The same thing happens for operator overloads too. One way around this is to introduce string prefixes, such as w"this is a wchar string". This has been suggested before, and it would certainly get rid of those ugly casts (I was under the misguided impression that casts should not be used on a general basis). BTW: the w"string" prefix is not a cast; it's a storage-attribute. I'd like to suggest such prefixes be supported and adopted.
>>
>>Anyway; the reason for the post is to make folk aware of the kinds of problems introduced when a compiler performs implicit conversions. This is bound to become more troublesome if additional "convenience" conversions occur implicitly within the D language, such as the oft discussed UTF8 conversions.
>>
>>Please consider.
>>
>>
>>
>>
>
> antiAlias: To reiterate, I think your initial points that started this thread are on the money...also I'm not quite sure I understand how the thread took a hard right and then a nose dive soon after you posted it. But do hope Walter will fix this soon, with maybe adding the prefixes w"" and d"" for string literals, which should solve both the parameter passing and string concatenation (~) problems when using string literals. Well here's hoping anyway!
>
> Also, I think we all need a *Big Group Hug*. Let's all get back to supporting "D" and each other in very positive ways!!  :))

Ok. All, consider yourself on the receiving end of some big love from Bigboy. ;)