On 06/26/2013 05:09 PM, Marco van de Voort wrote:
"Should" is a complex thing here, since there is no implementation to
test with (and see if it has other consequences). I assume a
conversion should be inserted, so at least for non rawbytestrings the
runtime encoding always matches the compiletime one.
I feel such implementation details are up to the fpc developers to
decide. If everybody agrees that doing a conversion when a RawByteString
is assigned to a normal String and the dynamic encoding does not match,
is the better alternative vs the potentially unpredictable behavior in
DXE??, I think this should be the default behavior in fpc.
It might be nice to add Delphi quirks modes that issue an error message
in that case or just do the assignment even if an "intersexual" String
(the static encoding that the compiler sees does not match the dynamic
encoding) is the result with unpredictable consequences.
The result could be a strange thing that is encoded
other than the type requires. To me this behavior is a quirk go and
should not be capt just for compatibility. .
The whole concept is about compatibility, and that is a race that has
already been run.
The "incompatibility" only arises when doing something that in Delphi XE
is depreciated according to the docs (assigning a RawByteString to a
normal String), anyway. Thus I don't see any problem with implemented a
sensible behavior in that case.
Another option would be to invent yet another String type that basically
is a RawByteString but at compile time is used differently just in that
when assigning it to a normal string that does not match the dynamic
encoding, the conversion library call is done. (In fact this always was
my initial idea, in fact: giving the name RawByteString back the
meaning, the name suggests.) When doing so assigning a RawByteStrinig to
a normal String could be strictly forbidden (unless some Delphi Quirks
Mode is set). But I do see that the additional complexity of defining
jet another String type might be not nice.
-Michael
_______________________________________________
fpc-devel maillist - [email protected]
http://lists.freepascal.org/mailman/listinfo/fpc-devel
