[fpc-pascal] Weird string behavior

[Santiago A.]

El 27/07/2016 a las 16:10, Michael Schnell escribió:
> On 07/26/2016 04:19 PM, Michael Van Canneyt wrote:
>>
>> This is not correct. In pascal the right-hand side of an assignment
>> has a well-defined type. The compiler checks whether the type on the
>> right is assignment-compatible to the left side.
>
> Hmm.
>
> if you do
>
> x := y + z;
>
> with x a real and y and z integers, the type of x will not change to
> be an integer, but the value will be converted.
>
>
> Now I understand that with strings the encoding is a kind of
> "sub-type" and hence (usually) static and not convertible to allow for
> the compiler do decide if a conversion is necessary.
>
> This has been discussed a long time ago and the argument was that
> _fully_ dynamically typed  strings are to costly regarding CPU demand.
>
> I did not get to know that those design decision has been changed for
> the normal usage case (while there seems to be ways to sue certain
> kinds of strings in a fully dynamical way) .
>
> Changing the encoding of the left side operand of ":=" would only be
> logical if the encoding is never an attribute to the string's type but
> always a dynamical attribute to the string's content.

And what are the rules for changing left side operand? It looks that
they are a little complicated.

Freepascal needed codepages, so string with codepage was needed.
Should it need dynamic codepage for backward compatibility?  INHO, no.
String should had been an alias of rawbytestring, and "codepage aware
strings" should be another new type, but codepage should be static.

Legacy programs could compile and run perfectly, and you could start
using codepage aware strings type.

Automatic conversions? Well, I'm not for it, but any way, left side
shouldn't change its codepage.

Nevertheless, that's my two cents. I looks that there is some pressure
to be Delphi XX compatible, I left Delphi long long time ago (Delphi 5),
so these  compatibility issues are not in my radar.

-- 
Saludos

Santiago A.