In our previous episode, Michael Schnell said: > > "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.
That already has been decided, everything Delphi compatible. I was just speaking hypothetic case. > 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. In general, it has been proven time and time again that deviating from Delphi is nearly always the worse choice. It just creates two cases to check for code that must still compile under Delphi instead of just one. So even if the extra "case" is better, it still produces more heartbreak for many people. Unless delphi changes it in some later version (since then, Delphi codebases will be adapted anyway) > 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. I don't think quirks mode would be useful. It is not just syntax, the resulting encoding in the string type is different between quirks and non-quirks mode. IOW passing strings between an quirks and non-quirks unit would get very intransparent. > > 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. In general the average code doesn't really honour such fine differences, so in practice this doesn't matter. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
