> Why not just introduce a set of utf-16 routines with utf16string type > like the new Delphi? > > This proposal is at least better then the one from Marco
My is having both an UTF8string and a UTF16string, on all platforms that support unicode. So I don't get this remark. It is just that on unix, the fileroutines will be defined as utf8string and on windows with utf16 strings. SO if I pass a different type, the compiler will insert a conversion. The only problem with this scheme is that it doesn't support utf-32, or it needs yet another additional type. But at least it is a proper compiletime option, and in a procedure I can see from the declaration what unicode type I'm gonna get. I had hoped that the implementation of a clean orthogonal set of unicode types (2 or 3, 4 if you count the COMstring) might be not as bad as 3 new string types, since we know they can always be converted to eachother, so maybe we could reuse and share implementation here and there. But since Florian tries to cast it out of the compiler and to the runtime, I suspect he thinks that is not possible. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
