[fpc-devel] String and UnicodeString and UTF8String

[Marco van de Voort]

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.