[fpc-devel] But what /is/ a string?

[Marco van de Voort]

In our previous episode, Graeme Geldenhuys said:
> > I doubt it. You maybe could (and probably would) in a new language, and have
> > one single stringtype.
> >
> > FPC is closer to 20 stringtypes or types with autoconversions.

(First, while 20 sounds bad, you will keep at least ten-twelve anyway, with
this way of counting (think types like char, pchar and array of char (open
array dynamic and static), all in 1-byte and 2-byte versions, then literal),
simply because _WE_ can standarize on one type, but the outside world
won't)

> Thinking hypothetical here... what if FPC 3.0 did just that... Rethink 
> the whole 20 string types mess, and implement only one string type for 
> 3.0 onwards. How would developers feel about that?

More, why not go wild and explorative, and use Michael Schnell's idea to use an
object per char? Since it would be your fork,  you can do whatever you want with it :-)

Seriously, even if you forget compatibility, it is impossible to assess
something like that without in-depth design (and preferably a test
implementation).

> What would the advantages be to developers and FPC maintainers?  What
> would the disadvantages be (other than it will probably break existing
> code - which the Unicode support will probably do too).

Read the unicode pdf. There was some deep thinking on that before D2009 came
out, and some of the problems are that you never will know what is in a
polymorphic string type. 

Moreover, think that you will have to satisfy everybodies requirements, not
just what you think you need.