[fpc-pascal] The world is ending (was: Warning not to use the "String" type with FPC 3.x)

[Tomas Hajny]

On Mon, May 9, 2016 21:34, Jonas Maebe wrote:
> Graeme Geldenhuys wrote:


Hello Graeme,

>> Now some would say, simply switch your compiler mode to DelphiUnicode.
>> But I don't want to do that, because I like the stricter ObjFPC mode,
>> and prefer ObjFPC's syntax.
>
> While still missing in the documentation, you can already do that with
> {$modeswitch unicodestrings}.
>
> And please stop this nonsense about how dangerous the String type in FPC
> 3.x supposedly is, after I've explained several times in this thread
> already how it's just as dangerous in FPC 2.6.x.

In addition to the comment raised by Jonas, note that in the example
mentioned by you, the decision about possible data loss isn't cause by the
compiler but rather by the user who sets his environment to use a
character set which can only process a limited subset of all possible
characters while he intends to use a bigger set. Similarly, a user
processing a text file saved in a particular character set needs to
understand that such a text file cannot host files not supported in the
particular character set.

Let's have another look at what FPC gives you: In spite of platform
limitations, FPC provides the programmers with means to support the full
range of Unicode characters even on platforms using limited character sets
natively (e.g. using fpwidestring Unicode string manager). However, such a
decision comes with a price (e.g. bigger executables and memory
requirements plus a possible slow-down with certain operations) and the
programmer needs to decide whether he wants to pay the price, or not.

You can use UnicodeString in your own code since long time ago. You're
welcome to help us with removing restrictions existing in our RTL today
(like you did in your strutils patch provided today, thanks!). There are
many places where UnicodeString and ansistring/shortstring interfaces may
coexist happily. Admittedly, there are other places where this isn't
possible and you're perfectly right that the FPC team needs to make some
decision about those. My _personal_ feeling is that we probably will bite
the bullet (as you suggested) for those in the end, although it will
probably result in certain incompatibility for those particular routines /
interfaces. However, I don't think that we need to sacrifice all backwards
compatibility everywhere just because of that.

Tomas