[fpc-devel] [Suggestion] Enumeration range-check intrinsic

[Ondrej Pokorny]

On 05.07.2019 11:33, Michael Van Canneyt wrote:
> On Fri, 5 Jul 2019, Ondrej Pokorny wrote:
>> On 05.07.2019 10:52, Sven Barth via fpc-devel wrote:
>>> Michael Van Canneyt <michael at freepascal.org 
>>> <mailto:michael at freepascal.org>> schrieb am Fr., 5. Juli 2019, 10:47:
>>>
>>>     If memory serves well, FPC introduced this (before delphi) to be
>>>     able to import C enums with assigned values.
>>>
>>>
>>> Correct. That is also why we allow both "=" and ":=" for the value 
>>> assignments. Because Delphi only supports one of the two and we 
>>> picked the other back then. ;)
>>
>> Ignorant Delphi core developers have never checked how FPC does 
>> things before implementing their own solution to keep compatibility 
>> ;) And then they added ARC, then they removed ARC, they then added 
>> 0-based strings, then they killed the product (AppMethod) they made 
>> it for... Unfortunately the 0-based string features made it into FPC 
>> in TStringHelper as well...
>
> TStringHelper is for delphi compatibility, so there is no choice.

I know, I am not blaming you (or anybody else) for doing so.

Still, in my opinion the 0-based string feature is the best candidate 
for knowingly breaking Delphi compatibility. The same as the core team 
communicated that the inline var declaration from Delphi 10.3 is not 
welcome in FPC.


> All in all, I am still of the opinion that the whole SysUtils unit is a
> monster that should be taken apart and its functionality spread over 
> various units: StrUtils, DateUtils, IOUtils, Exceptions, Helpers.
>
> Doing so would also release us from the need to be Delphi compatible 
> in those
> units. Alas, this is meanwhile a huge undertaking.

Yes, that is actually a good compromise: to move the 
Delphi-compatibility TStringHelper into a different unit (e.g. 
DelphiHelpers.pas) and offer a similar helper with 1-based strings in 
Helpers.pas. Yes, there is too much to do :(

Ondrej