Hello! Anything new?

[Fibonacci]

Good point. I did not open a separate thread immediately because I was not sure whether that would be appropriate here.

This forum is centered on Free Pascal itself, while FPC Unleashed is an unofficial fork with significant language changes that upstream chose not to include (so it is not aligned with the current FPC direction), so I am not sure if a dedicated topic about it would be welcome.

If moderators/admins are okay with it, please point me to the appropriate section and I will open a separate thread for discussion there.

[440bx]

A few Some years ago, there was another FPC fork named "New Pascal" and there are a good number of threads about it (they are no longer seen because "New Pascal" is now "Dead Pascal" but, at least at the time, there were no objections from the moderators to "New Pascal" threads.)

[Fibonacci]

So which board would you suggest?

  Free Pascal -> General
  Free Pascal -> FPC development
  Miscellaneous -> Other

[creaothceann]

"Third party" or "Miscellaneous -> Other"

[440bx]

As suggested by @creaothceann, I'd go for Miscellaneous -> Other

[VisualLab]

<cut>... FPC Unleashed is an unofficial fork with significant language changes that upstream chose not to include (so it is not aligned with the current FPC direction) ...<cut>

I was very curious about the proposals and changes introduced in the forked version of PFC. I went to https://github.com/fibodevy/devfork-fpc-unleashed. I read the description. And I have to admit, it was a huge disappointment. There is no significant, interesting or useful proposition given in this description. Just minor code quirks. So I'm not surprised that people "holding their hand in the FPC project" rejected these ideas.

Of course, the FPC compiler (Object Pascal language) needs development, improvement, and enhancement. I would like to see specifics, not minor quirks. As a concrete example, I can give you: constraints on primitive types when declaring generic types (e.g., integer, real, enum).

[Fibonacci]

<cut>... FPC Unleashed is an unofficial fork with significant language changes that upstream chose not to include (so it is not aligned with the current FPC direction) ...<cut>

I was very curious about the proposals and changes introduced in the forked version of PFC. I went to https://github.com/fibodevy/devfork-fpc-unleashed.

Wrong link. That repository was only a temporary fork used for testing and CI setup. It was created (and last updated) months ago and does not contain the current features. The README there is incomplete and outdated. Even in the current repository, not all changes are documented yet. Documentation will be expanded gradually, as this is a hobby project done in spare time, so things get documented when I have time and the motivation to do it.

Official repository:
https://github.com/fpc-unleashed/freepascal

Please check that one instead. The repo you looked at does not reflect the current state of the project, so the description there is outdated.


I've created a separate thread for FPC Unleashed, so discussion can continue there:
https://forum.lazarus.freepascal.org/index.php?topic=73678

[VisualLab]

Official repository:
https://github.com/fpc-unleashed/freepascal

I read the description from the current page. The only idea I liked was the option to remove type names from the executable file. Although I don't really like its implementation, because it requires adding additional directives for the compiler. This can be tedious when adding such directives to classes that aren't forms but also require specifying names. In such situations, you'd need well-written documentation (rare in open source) or laboriously review the entire source code of such a library. Well, there are no perfect solutions.

[Thaddy]

Pity there is no sync with main. To me it is a downgrade. (basically solely for inline vars, which I won't use anyway. If then else is a commit away.)
One such an irritating issue is that {$mode delphi}($modedelphiunicode} is not synced with multiple modeswitches that are already done/included for months.
Another irritating issue regarding sync is that about two years worth of bug fixes are missing.

About where? Firmly third-party.

(BTW: Although I disagree with inline vars, I admire the people who implemented it. That is no minor achievement even if I dislike it)

As it stands, I can not recommend this fork because it has too many issues (two years worth of fixes is the least of them: many new essential libraries are also missing, also like to be able to run the tests without so many errors)

[Fibonacci]

Official repository:
https://github.com/fpc-unleashed/freepascal

I read the description from the current page. The only idea I liked was the option to remove type names from the executable file. Although I don't really like its implementation, because it requires adding additional directives for the compiler. This can be tedious when adding such directives to classes that aren't forms but also require specifying names. In such situations, you'd need well-written documentation (rare in open source) or laboriously review the entire source code of such a library. Well, there are no perfect solutions.

Hint - currently undocumented.

Add this to the project custom options:

Code: Pascal  [Select][+][-]

1. --unleashed=nortti

This removes RTTI for the entire project. Note that if you have {$mode ...} in a unit, it overrides unleashed mode and the NORTTI option.

Managed classes normally keep RTTI strings, so RTTI will remain in the binary unless it is disabled (project option or per-unit modeswitch).

Required classes can be explicitly exposed using:

Code: Pascal  [Select][+][-]

1. {$expose}

placed before the class declaration.

Pity there is no sync with main. To me it is a downgrade. (basically solely for inline vars, which I won't use anyway. If then else is a commit away.)
One such an irritating issue is that {$mode delphi}($modedelphiunicode} is not synced with multiple modeswitches that are already done/included for months.
Another irritating issue regarding sync is that about two years worth of bug fixes are missing.

Will be synced, just not by pressing the "sync" button in GitHub, the fork was detached, so it has to be merged manually.

If then else is a commit away.

I hope.

BTW: Although I disagree with inline vars, I admire the people who implemented it. That is no minor achievement even if I dislike it

Thank you. AI assisted with some parts.

As it stands, I can not recommend this alternative distro because it has too many issues (two years worth of fixes is the least of them)

About 9 months, not two years. As I said, it will be synced.


Please continue there:

https://forum.lazarus.freepascal.org/index.php?topic=73678

[Thaddy]

9 months? The commits seem to suggest otherwise.

[marcov]

Afaik Delphi has a $RTTI directive to omit extended RTTI.

By default I have

Code: Pascal  [Select][+][-]

1.  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

in my delphi projects

[Fibonacci]

9 months? The commits seem to suggest otherwise.

The last upstream FPC commit currently present in the unleashed repo is: 562048c965f06a75caf878087aae44a10be56a55 by Rika Ichinose on Thu, 19 Jun, 2025, 20:16

273 days. 273 / 30 = about 9.1 months.

[Fibonacci]

Afaik Delphi has a $RTTI directive to omit extended RTTI.

By default I have

Code: Pascal  [Select][+][-]

1.  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

in my delphi projects

Are you willing to compile the test code and check for the presence of the strings in the binary output? https://github.com/fpc-unleashed/freepascal?tab=readme-ov-file#no-rtti

[marcov]

Afaik Delphi has a $RTTI directive to omit extended RTTI.

By default I have

Code: Pascal  [Select][+][-]

1.  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])}

in my delphi projects

Are you willing to compile the test code and check for the presence of the strings in the binary output? https://github.com/fpc-unleashed/freepascal?tab=readme-ov-file#no-rtti

I tested with both FPC/trunk and Delphi, and they still have the identifiers. With Delphi I also see "destroy", which I don't see with FPC (but that probably requires extended RTTI to turn on).

The question is _WHY_ Delphi doesn't smartlink it out. Usually there is a reason.

Anyway, even then it is easier to implement it using the compatible directives instead of inventing new ones.