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 <mich...@freepascal.org
<mailto:mich...@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
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
