[fpc-devel] Unicode RTL

[Daniël Mantione]

Op Thu, 17 Nov 2005, schreef Yury Sidorov:

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

If you look at the discussion I tried to convince Juras that such an 
assignw solutions was best. However, he convinced me instead of that I 
convinced him.

IMHO the "hope" is that if there is a Tnativestring, people will 
start to design their libraries using Tnativestring, which will result in 
that those libraries can be compiled for 8 of 16 bit strings.

With assignW, TstringlistW etc., that won't happen, i.e. everyone who 
writes a library has to decide if he uses 8 bit, 16 bit or both code 
paths. Practice will be that people design libraries with 8 bit in mind, 
if you are lucky utf-8 aware. People who have an interrest in Unicode 
would have to add Unicode support to way more code than they can manage.

Daniël