[fpc-devel] Russian locale information not compatible with FPC locale variables

[Daniël Mantione]

Op Tue, 29 Jul 2008, schreef Bee:

>> Could you show me the advantage of having an incompatible string 
>> implementation in FPC 2.4, which will be out after highlander?

> Boost the usage of Unicode in FPC that would boost the usage of FPC itself. 
> Unicode is one of the most demanded features (beside cross platform, 64bit 
> support, etc) in Delphi since Delphi 7 (2001?). Yet, CodeGear never fulfill 
> it until Tiburon.

Why would it boost FPC usage?

Okay, here is the deal: From now I'm going to stick my fingers in my ears 
until someone says "You should be incompatible because....".

Until now I have heard these valid arguments:
- Delphi's implementation is ugly/non portable.

> By providing DELPHI MODE (and other pascal dialects directive), IMO, FPC is 
> already in the correct way of being different but still united with other 
> pascal compilers.

The intention of the FPC mode is threefold:
- Allow FPC to be compatible by itself
- Fix the worst quirks in the Delphi dialect
- Disable some FPC features that interfere with compatibility

The FPC modes were never intended to design our own dialect from scratch, 
or give the finger to existing code. Any code should compile in FPC mode
with just a few fixes, at least that is how it is intended.

Further, you lack complete understanding of the impact of incompatible 
strings. Delphi mode is feasible because in one mode, you can call code in 
compiled in other modes.

>> Good. Now it's time show practical proposals or stop the discussion.
>
> Well, I'm not a compiler expert. Is it possible to keep the "old" string 
> in Delphi mode and implement "new" string in FPC mode? This way, FPC 
> could keep (backward) compatibility in Delphi mode and provide the new 
> (Unicode) implementation in FPC mode. FPC can modify Delphi mode string 
> later after Delphi shows its mechanism and follow it to get Delphi 
> compatibility.

I don't consider this a practical solution for Graeme's issue with the 
numeric separators, he would still have to wait for 2.4, and we could 
implement it compatible anyway in 2.4.

> However, I think it's too late to use this scenario since Unicode support in 
> Tiburon is just a few months away. I think FPC should have done it since 
> v.2.0. :( Perhaps FPC could think about multiprocessor support using this 
> scenario. ;)

Agree for the part that an proprietary unicode string would have made 
sense then and not now. I would not have done things differently in 
hindsight. Postponing it for even more features would have given extra 
stress supporting 1.0 and made users impatient waiting for 2.0.

Daniël