[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[Marco van de Voort]

In our previous episode, Felipe Monteiro de Carvalho said:
[ Charset ISO-8859-1 unsupported, converting... ]
> On Thu, Oct 13, 2011 at 10:47 AM, Marco van de Voort <marcov at stack.nl> wrote:
> > But I don't consider this as solution. You have to put each string type in
> > the entire libraries on trial, and keep it up.
> 
> Could you explain more? Which libraries are you talking about?

Pretty much everything that inherits from a class in classes, or passes to
VAR parameters in the RTL. (classes or not)
 
> showed, nothing would need to change in the RTL or FCL classes, they
> can use string as usual, or whatever else.

I'm talking from the usage viewpoint. That includes Lazarus. I don't think
this is a sane solution for Lazarus either.

> If the problem is in utf8string based libraries, then it only affects
> people that use such libraries and authors of such libraries would
> take care of solving the issues.

Assuming that Lazarus stays utf8 only long term. That is still the party
policy, but I have some doubts there.
 
> > Moreover, it gets funky when string is banana on Windows and banana2 on
> > unix. It keeps working, but if people make mistakes that "happen" to work on
> > one platform, the other people might have a problem etc.
> 
> That's a general problem of having a string type which varies across
> platforms, which is something I was always against.

True. But you are crafting a system out of a patchwork where these things
differ from block of code to another. 

A very informed person can make this work, since he has a lot of the
overview already memorized.

But for an uninformed (read user) this kind of stuff is nearly undoable,
since they don't know the exact string properties of each module that
contributes to the greater Lazarus system. (as in Lazarus + most used
components)

And of course I don't like having to modify Delphi code on a massive scale.
We didn't have to till now, and I see no reason to start.

If it comes to such solutions, I give up all my resistance, and go with 1:1
D2009 compatibility on all platforms all the way.  So string=unicodestring, and screw the
rest.

Having to modify Delphi sources before use, more than just uses clauses is
an absolute nono for me, which goes over everything.

Since all other sources (FPC backwards compat, Lazarus being UTF8), might
change, but Delphi isn't going to.

> > Also, dual maintenance of components with Delphi is next to impossible,
> > since you would force that scheme also onto them, and all new code first
> > needs to be lazarused.
> 
> It will not be worse then maintaining Delphi 7 and Unicode Delphi at
> the same time, and yet most components support both at the same time.

I disagree.  In D7 everything is the same "string", and so is in Delphi
unicode. They are just not the same. This is worse, much worse.

> Plus, isn't Embarcadero pushing FireMonkey anyway?

I don't see it that way. I see FM as a Delphi PHP/3rd Rail/Prism like
product, not as serious VCL contender. If I understood it correctly, it is
mostly a sideproduct of internal efforts to port Embarcadero's non-Borland
originating lines.