In our previous episode, Jonas Maebe said: > >> > >> If/when this is done, it will only be with a compiler switch or > >> directive. > > > > ( > > That won't be enough, since that would not change the relevant units > > and > > classes to such type. (e.g. tstringlist would remain defined > > ansistring) > > If it's a D2009-style ansistring, does that matter?
A lot of conversion, since it will use ansistring(0) so reading/writing ansistring(cp_utf8) will force conversions. (0 means system encoding, $FFFF means never convert) Besides that the usual three problems: - I don't know how VAR behaves in this case. (passing a ansistring(cp_utf8) to a "var ansistring(0)" parameter), - maybe overloading (only cornercases?) etc. - inheritance. FPC defines base classes as ansistring(0) parameters, and Lazarus wants to inherit and override them with a different type. This will clash. I've thought long and hard about this. Since the discussion what the dominant type should be won't stop anytime soon, and we probably will have to support both UTF8 (*nix) and UTF16 (Windows and *nix/QT) as basetypes in the long run, plus a time ANSI as legacy, the RTL has to be prepared for it anyway, we might as well allow this on all platforms from the start. (actually releasing them is a different question and depends on manpower) That doesn't mean that a per unit switch is useless, but I think a target switch to fixate the bulk of the cases will save both us and the users a lot of grief. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel