On Thursday, September 29, 2011 09:20:39 Christophe wrote: > Jonathan M Davis , dans le message (digitalmars.D:145653), a écrit : > > Having toUTF and toUTFz is a marked improvement in many cases - > > especially for generic code. They're being added regardless of what the > > deal with toUTF16z is. > > > > The reason that toUTF16z is being removed is essentially because Andrei > > is very much opposed to having functions with specific types in their > > names and thinks that they should all be generic. Personally, I'm not > > opposed to keeping toUTF16z as an alias or wrapper to toUTFz. It's > > Andrei that seems to feel stongly about it. So, if enough people really > > want to keep toUTF16z, then I think that that can happen. > > Sure, toWcharz would be a really bad name, but UTF16 is not a specific > type, it is a specific encoding.
UTF-16 and wchar are synonymous. wchar is UTF-16 by definition. If you have toUTF8, toUTF16, and toUTF32, then it's a pain for generic code, because yo uhave to do a bunch of static ifs on the type that you're converting to and call the appropriate function, in spite of the fact that the type that you're converting to gives you exactly what the conversion should be. So, putting UTF16 in the name is tantemount to putting wchar it the name, it just makes way more sense to have toUTF and toUTFz. The issue here is that using toUTFz is more cumbersome, because it's more verbose, and there is one very common use case which toUTF16z fulfills. So there is a usability argument in favor of toUTF16z. In general however, putting UTF8, UTF16, or UTF32 in a function name is bad design, since it's essentially identical to putting char, wchar, and dchar in the function names, which just is not generic at all. - Jonathan M Davis
