[fpc-pascal] Strings - suggestions

[dev.dliw at gmail.com]

Hi,
concerning the string topic, for me (using fpc since 2.0.4 on a regular basis; 
TP experience ~ average user) there really should be an decision what way to 
go as early as possible.
I'm not ranting and I know, that I'm not in the position to demand anything...
[I would really like to help, but unfortunately studies take all my time - at 
least for one more year - but time will come... :D ]

Nonetheless I would like to make a suggestion:

1.
Make a general "String" type, with no statement what the internal structure is 
like.
Users can define the internal type with e.g. {$STRING UTF8} for their *whole* 
project. On compilation now the defined type is used and there should be no 
problems as long as the source code does not make any assumptions, what the 
internal structure looks like and uses a general string unit (e.g. Sysutils).
External libraries (no source) define their string type accordingly in their 
import "header" [sorry :) ] for their scope, strings are converted based on 
this information, if necessary.

If you make it possible for users to define their own string unit (as 
"override" of the general one), many string types are possible.
To clarify (an example; the main program file, not a unit):

...
{$STRING *user defined*}
{$USESTRINGUNIT *some user unit which implements all string ops for the own 
string implementation*}
...

The advantage is, that anything compiled from source within a project 
(external libraries, too) uses the user defined (=preferred) string type and 
no conversion is needed (assuming there is no direct string access, which 
should be good programming style nowadays).
[You see, I'm not a friend of the idea, that a string itself contains the 
information about its internal type...]

2.
With this design (and most users never thinking about their own string type) 
there still should be a defaul fpc string type. This is at least necessary for 
string conversions. Any custom string type *must* provide a function to 
convert to and from the default fpc string type, but *may* also provide such 
to/from other string types.
Now any string can be (automatically) converted to any other, in the worst 
case like this:
*user defined* -> fpc default -> *any other, maybe Ansistring*

There is still the problem, that conversions should be lossless, so the 
default string type must be able to handle any character [but that should 
obviously be possible anyway]...
... and I really hope that explicit conversions won't be necessary in future 
(have I to use GetFilenameUTF8 or GetFilname or ...?? - you know)...

I can't say how much work this would be to implement, but in my eyes a more 
complex but flexible solution should be worth it, thats not something you 
change everyday...
... with {$STRING ANSI} it would work for any old project, so no problems in 
backwards compatibility, although IMO a cut in compatability for the new 
string type (supported defines, etc.) - if its necessary and makes things 
cleaner - is definitely no problem and even the way to go...

3.
Now, what string type to use as default?
No suggestion from my side, but an suggestion how to quickly and 
constructively find the "right" one.

Make a wiki page e.g. "new string type suggestions" where within a certain 
time, everyone can describe his preferred string type, the best would be a 
table with pros/cons...
... the core devs than can decide based on this.
[Basically summarized info of all the posts floating around in the mailing 
list]

-> So, don't waste your energy one more time, to fight each other in response 
to this post, just fill the wiki page :)
[IMHO nobody will ever read all the postings about strings in the mailing 
list, there *must* be a summarized overview somewhere]
[Sorry if this wiki page already exists...]

And a last thought from my side:
Please, don't try to stay Delphi compatible no matter what.
IMHO its time for fpc to move forward, not sticking to any (bad) Delphi design 
change. Even now its almost impossible to use ("modern") Delphi code 1:1 in 
fpc, and it certainly won't be better in future. It would be much better to 
define a "last almost supported Delphi version" and then go an own way.
Fpc (and Lazarus even more) shouldn't be reduced to "make any Delphi(!) 
project crossplatform" - and doing the difficult (not to say "dirty") work for 
Embarcadero to make a Windows-oriented design work on many platforms - it 
should be an independant implementation of ObjectPascal (and not Delphi!), in 
the optimal case being compatible to Delphi, as long as its possible and makes 
sense...

With the above suggestion, it would be even possible to make an own Delphi 
compatible string type for Delphi mode.
- And, if the Delphi design really is superior to any other - then lets use it 
(unfortunately its not).

Uff, a long post, hopefully at least a little helpful - and constructive.
Certainly many wait for the final decision (including me) - let's hope it will 
come in near future... :D

Regards,
d.l.i.w