[fpc-devel] Unicode RTL

[Marco van de Voort]

> From: "Marco van de Voort" <marcov at stack.nl>
> > Nothing. You can't. It was meant to illustrate that there is more to it 
> > than
> > simply declaring an "tbasicstring" or so alias and fixing some internal
> > routines. It will "just" mean full checking and ifdeffing of/in every part
> > of the entire fpc/lazarus repository, and maintaining that, the added 
> > support
> > burden etc.
> 
> When unicode RTL will be used with existing non-unicode applications or 
> libraries there will be a problems in any case.

Correct.

> But it does not mean that unicode RTL is not needed at all.

Correct.

> Unicode RTL is needed for people who want to develop unicode applications 
> from the beginning. In such case the developer will be aware of unicode and 
> will write correct code.

All correct, BUT

1) it is not Unicode RTL but Unicode FPC/Lazarus.
2) it is not backwards compatible. We have to take care of more people's need
than just the ones that urgently need Unicode to be as easy as possible.
3) thus creating an huge support problem

4) as mentioned before (and forgotten by me earlier) even UTF32 is 
	not 100% fixed width

> There is no magic solution to make unicode RTL compatible with existing apps 
> or libs.

Correct. But what is then the use of stuffing it into the entire codebase?
That extra work is then useless

> Unicode RTL will be an option for people who really need it.

Unicode is. I'm not sure "Unicode RTL" is. 
 
> IMHO RTL code base must be the same for ansi and unicode. To build unicode 
> RTL some define must be used.

As said, since legacy RTL code doesn't become magically unicode, maybe it is
better to keep it separate, and overload a few funcs (like filesystem) if
necessary at all (on *nix, use utf8).