[fpc-devel] Unicode RTL

[Yury Sidorov]

From: "Marco van de Voort" <marcov at stack.nl>

>> 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).

I agree. There is no need to make existing RTL APIs unicode aware, because 
there will be no compatibility with existing apps in any case.
So how about to add alternative unicode versions of RTL APIs via overloading 
or via adding some suffix (eg. Assign and AssignW, TStringList and 
TStringListW - like in WinAPI)?

There are following benefits in such approach:
1. It will be possible to develop unicode apps using these APIs.
2. There will be only one RTL.
3. There will be single source tree.
4. It will not break existing RTL code.

Yury Sidorov.