Zitat von Marco van de Voort <marcov@stack.nl>:

> > Zitat von Marco van de Voort <marcov@stack.nl>:
> > > > types?
> > >
> > > It will be released in August.
> >
> > If they are bold enough for this big incompatibility, then maybe we must be
> > braver too.
>
> What, also stop supporting anything but Windows?

;)

I meant, break some compatibility too.

At the moment the RTL uses Ansi = current code page < unicode.
And so any filename that uses indirectly these functions is limited to the
current code page.

One solution is to create a new string type UTF8String.
Similar to AnsiString/WideString auto conversions, there would be an auto
conversion AnsiString/UTF8String, IFF there is an UTF-8 string manager.
The RTL and FCL can use it for filenames and similar things.
There should be some compiler flags to set the default string type to either
ansistring or utf8string.
All lazarus related sources would set the default string type to utf8 and would
load an UTF-8 string manager.

Drawbacks:
- If a UTF8 string manager is enabled, old code that uses ansistring would
double recode filenames under windows. From ansistring to UTF8 to widestring. I
guess in case of filenames this is hardly measurable.

- Mixing code compiled with ansistring and compiled with UTF8String will be
slower due to the conversions. Especially when exchanging big lists of string
like TStringList.Assign. Remedy: enable UTF8String and fix the few issues. This
might be arbitrary difficult and/or unpleasant. But hey, CodeGear says that even
switching from ansistring to widestring is easy. And of course you can still use
'ansistring' explicitly.

- Mixing code compiled with ansistring and compiled with UTF8String with dirty
typecasts will create hidden conversion errors. Remedy: Same as above.

- If the most common RTL/FCL functions are *not* converted to UTF8String then
all UTF8String programs will become very slow and might even get conversion
errors, due to typecasts. So, if RTL/FCL don't use it, no one will.


Mattias


