[fpc-devel] TRegistry and Unicode

[Michael Van Canneyt]

On Wed, 6 Mar 2019, Bart wrote:

> On Wed, Mar 6, 2019 at 2:16 PM Michael Van Canneyt
> <michael at freepascal.org> wrote:
>
>> Please add overloading using UTF8String.
>> Backwards compatibility is not an idle word.
>
> To be honest, that last sentence does not make sense to me.
> Before trunk TRegistry used (on Windows) the A-API and string
> parameters are just AnsiString(CP_ACP).
> Unicode caharcters were not supported in plain fpc programs using the
> default 1 byte encoded string type on Windows.
>
> Introducing Utf8Encode (and the plain wrong Utf8Decode) in TRegistry
> is backwards incompatible.
> Reverting this to using plain String does not introduce any backwards
> (compared to 3.0.4) incompatibilty AFAICS.
> (Unicode support in plain fpc programs simply is not there (unless you
> use the appropriate string type). There is a reason for the Lazarus
> UTF8-hack.)
> Introducing UnicodeString overloads does neither introduce regressions AFAICS.
> If it would have worked with A-API it certainly will work with
> UnicodeString, because the characters would have been inside the users
> codepage.
> It does however add unicode support for plain fpc programmers for
> those who need that.
> All would still be completely unicode-proof in Lazarus (with UTF8-hack).
>
> Using UTF8String would trigger 3 conversions instead of 1 (plain fpc
> programs): string->utf8string->unicodestring (the last conversion is
> inside the methods where we call the W-API).
> Using UnicodeString would trigger only 1 conversion: String->UnicodeString.
> For users using Utf8String inside there program calling the
> UnicodeString overload would also be just 1 conversion (lossless).

So, what do you propose for maximum backwards compatibility ?

By this I mean, for people that basically use plain strings and ASCII, they
should not get warnings about 
'conversion from widestring to ansistring' and vice versa.

Michael.