If I remember correctly this is indeed how this behaves in newer versions of Delphi if the left side is indeed a AnsiString.
The behavior has nothing to do with the type used on the left side of the assignment. The behavior is controlled by the {$HIGHCHARUNICODE} directive instead:
When HIGHCHARUNICODE is OFF:
All decimal #xxx n-digit literals are parsed as AnsiChar.
All hexadecimal #$xx 2-digit literals are parsed as AnsiChar.
All hexadecimal #$xxxx 4-digit literals are parsed as WideChar.
When HIGHCHARUNICODE is ON:
All literals are parsed as WideChar.
FPC does not support that switch. And please also see what I mentioned further down in my post after I looked at the compiler's code.
As for Delphi String = UnicodeString you won't notice this, cause there won't be any conversion necessary.
In FPC, String=AnsiString in {$mode Delphi}, and String=UnicodeString in {$mode DelphiUnicode} and {$modeswitch UnicodeStrings}.
I
know that FPC supports that modeswitch, but right now it's essentially a joke and useless. Because yes,
String might be set to
UnicodeString then, but the whole RTL still uses
AnsiString. So overriding any virtual methods of RTL classes requires you to explicitely use
AnsiString instead of
String thus providing even less compatibility to Delphi code than the current solution does.
> Why you expect 100% Delphi-compatibility?
Well, I don't. Clearly there's areas where there isn't. But when it comes to something as fundamental as unicode, and as uibiquituous as string handling, then I do expect a clearly documented way to write code that delivers source code compatibility, yes.
You're expecting wrong. What we do is document code so that it generates
working code,
not code that delivers source code compatibility to Delphi. And the Unicode related behavior is extensively documented
here.