[fpc-devel] new string - question on usage

[Marco van de Voort]

In our previous episode, Jonas Maebe said:
> > 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.
> 
> How about this: a new language feature is added to the compiler that
> enables defining a type alias that resolves to a different type depending
> on whether {$modeswitch unicodestrings} is active in the current code.  If
> necessary, it could also be extended for functions/procedures (but I'd
> like to use it as sparingly as possible).
 
> E.g. (with the first statement obviously in need of being replaced with something more legible)
> 
> type
>   // needs to be defined in advance with this particular syntax so that the
>   // compiler will write "tstringlist" as the type name in the RTTI of the
>   // two classes below;
>   // the compiler will still generate separate RTTI for both classes though
>   tstringlist = FpcStringModeDifferentiatedType(tansistringlist,tunicodestringlist);
> 
>   tansistringlist = class
>     <ansi stringlist code>
>   end;
> 
>   tunicodestringlist = class
>     <unicode stringlist code>
>   end;
> 
> (obviously, you could also implement both types using generics, include
> files and macro substitution, etc).  An alternative could be to extend the
> syntax for generics or specializations and incorporate such functionality
> there, but that is only practical if in all cases the two different
> classes can be expressed using a single generic implementation.
> 
> Such a feature would enable duplicating functionality where absolutely
> necessary for compatibility reasons (e.g., inside the classes unit)
> without adding the complexity of having two completely separate RTLs.  And
> the result should be completely compatible with both code written for an
> ansistring-based and for a unicodestring-based RTL.  In fact, if I'm not
> missing anything it would also make combining components depending on an
> ansistring-based and on a unicodestring-based RTL into a single program
> possible (at the expense of including two copies of some data structures,
> of course, but nobody forces you to do this; it's simply an option that's
> available).

If it was just one class it would work. But essentially it is all OOP. (e.g. 
tcomponent and tcontrol has string properties, and thus the whole of
lazarus), same for the OOP parts of packages/ It would also mean rewriting
delphi code using such schemes to be encoding agnostic to follow this.

So sorry, but I don't see anything usable in this proposal. If I understand
it right it is a workaround that allows to switch a handful of classes in
FPC that way, at considerable cost (duplication), but disallows the user to
keep his code encoding agnostic.