[fpc-devel] new string - question on usage

[Marco van de Voort]

In our previous episode, Jonas Maebe said:

> That would not change the meaning of the "string" type. The code in
> rtl/classes would then use a custom string type (RTLString or whatever)
> that is defined as either an utf8string or a unicodestring based on some
> define.

I did plan to make the string type change. Since anything else would make
classes incompatible with Delphi code. (be it old or new, that uses string)
 
I know that Florian and you wanted to see the default string as something of a
dialect mode, but I never saw a way to do that practically.

> RawByteString will result in code page
> conversions that may be lossy (and RawByteString itself has its own share
> of gotchas to watch out for if you use it for anything else than
> parameters).

Important enough to quote again: view rawbytestring is like a special open array. Useful
for its specific purpose, but not a main type.
 
> I really don't see how adding a feature to the compiler to change the
> default definition of the string type would change anything.  As I said,
> you can achieve exactly the same result by using a custom defined string
> type.

It would make it match with the bulk of code out there. That is the main
point I'm trying to make with the multi rtl proposal. You can't simply see
the base type as something you {$H anymore.

With the shortstring -> ansistring conversion we changed RTL (from the TP
oriented to the Delphi oriented, and over time e.g. we exchanges dos for
sysutils). And effectively shortstring (while still a dialect mode) is
hardly used (and IMHO we should have changed default mode 5 years ago)

But now we keep using sysutils, and the rest of the RTL. If there is
anything that I want to avoid is telling 15 times a day how people must
change their delphi code to suit FPC. 

Such situation is effectively the end of compatibility, the end of sold
components for Lazarus (which works by the virtue of minimal changes
needed).