Hello! Anything new? lazarus / 64-FPC development ---------------------------------------------------------------------- Fibonacci · 2026-03-09 07:57 It's been 7 months since my last post here. Has anything new happened? Are inline vars in already? Have statement expressions been merged? Has anything else been merged since then? I haven't been following the changes in FPC recently, so if anything new or noteworthy has happened, I'd appreciate it if someone could list the main updates. ---------------------------------------------------------------------- 440bx · 2026-03-09 08:16 I'll give you a short summary... There have been a few releases of Lazarus (don't remember how many) that introduced some new features and corrected known bugs. On the FPC side, not much has changed, FPC v3.2.4 is yet to be released, which is the state it was in 7 months ago. ---------------------------------------------------------------------- Fibonacci · 2026-03-09 08:19 Thanks ---------------------------------------------------------------------- 440bx · 2026-03-09 08:27 I forgot to mention one thing on the FPC side that is significant but will not be in v3.2.4. Forum user @Wallaby fixed the compiler's exception handling code for 64 bit ARM.  That's a significant accomplishment and step forward.   When it will be part of an FPC release, that, is TTBMK unknown at this time. ---------------------------------------------------------------------- Thaddy · 2026-03-09 11:10 Quote from: Fibonacci on March 09, 2026, 08:57:50 amAre inline vars in already? No and the core team has repeatedly stated they won't be implemented. QuoteHas anything else been merged since then? Quite a lot. Daily. Both new features and bug fixes or improvements (like a new heaptrc) Better check the commit logs. The one I like best - but is not the most spectacular - in the past 7 months is that the delphi modes (not mode objfpc) do no longer need modeswitches related to delphi compatibility: functionreferences,anonymousfunctions,implicitfunctionspecialization are no longer needed. ---------------------------------------------------------------------- Fibonacci · 2026-03-09 11:40 Quote from: Thaddy on March 09, 2026, 12:10:35 pmQuote from: Fibonacci on March 09, 2026, 08:57:50 amAre inline vars in already? No and the core team has repeatedly stated they won't be implemented. I see. That's a bit disappointing to hear. To me it feels like a lot of potential is being left unused. People who already use FPC will probably keep using it out of habit or because they maintain existing codebases. But obviously new users will rarely come - there are so many other languages to choose from today, so it's hard to see why someone new would pick it if the language intentionally stays very conservative. From the outside it feels like FPC is preserving an older style of Pascal rather than evolving it. At the same time a lot of effort clearly goes into keeping FPC compiling and running on modern systems and architectures, which is valuable. But the language itself often remains quite archaic, and there seems to be a strong group of people who prefer it to stay exactly the way it was decades ago. As a result, language evolution feels very slow. To be fair, some things did improve - anonymous functions for example were a good addition. Personally I actually like Pascal a lot. It's native, very simple and clean - in some ways even nicer than C. But the lack of things like inline variables makes everyday coding unnecessarily cumbersome. It's one of those small features that significantly improves ergonomics. A big plus on the ecosystem side is Lazarus itself. I actually like the IDE quite a lot, and its refactoring tools are very useful. Honestly, I would even support some kind of funding effort if it helped core developers spend time on modernizing parts of the language. I'd gladly contribute to something like that. These days I mostly use FPC when I need to maintain or extend older codebases where rewriting everything into another language would be too time-consuming. For new projects I usually choose more modern languages that continue to evolve and improve developer ergonomics. Which is a bit sad, because I genuinely like Pascal. It just feels like it could be much more if some of these limitations were addressed. Quote from: Thaddy on March 09, 2026, 12:10:35 pmThe one I like best - but is not the most spectacular - in the past 7 months is that the delphi modes... I dont care about Delphi mode, nor Delphi, at all. ---------------------------------------------------------------------- Thaddy · 2026-03-09 11:54 Well, I am firmly with the core developers in that inline vars violate the separation of declaration and use/implementation. Which means it is not Pascal anymore. Otoh: I can see the point from the other side too: for that I use Delphi CE, clean the code from inline vars and recompile in fpc. One exception would be type inference for loop vars (indices), but that would not even need the var keyword inside codeblocks. ---------------------------------------------------------------------- Thaddy · 2026-03-09 12:29 The status of theQuote from: Fibonacci on March 09, 2026, 08:57:50 amHave statement expressions been merged?The merge request for ternary if then else (and case) is still open and seems to hang only on removal of the use of some default parameters and time. There will be no true statement expressions, though, as per PascalDragon's answers. ---------------------------------------------------------------------- olatov · 2026-03-09 12:51 Delphi-style JSON serializers are in trunk now, pushed by Michael just a few days ago https://gitlab.com/freepascal.org/fpc/source/-/work_items/41509 ---------------------------------------------------------------------- JuhaManninen · 2026-03-10 10:22 Quote from: Fibonacci on March 09, 2026, 08:57:50 amHas anything new happened? The biggest news is that there is still no release, even a minor bug fix release, after many years of waiting. What more, nobody seems to be working on it. There will be no releases in near future, or maybe even in rather far future.  Quote from: Fibonacci on March 09, 2026, 12:40:13 pmHonestly, I would even support some kind of funding effort if it helped core developers spend time on modernizing parts of the language. I'd gladly contribute to something like that. Please fund them to release FPC 3.2.4. "Modernizing the language" is partly the reason why FPC trunk is so very far from a release. Most of those modernizations are quite useless in my personal opinion. ---------------------------------------------------------------------- PascalDragon · 2026-03-12 20:39 Quote from: JuhaManninen on March 10, 2026, 11:22:16 am"Modernizing the language" is partly the reason why FPC trunk is so very far from a release. Most of those modernizations are quite useless in my personal opinion. You shouldn't always assume from only your own perspective, because then you clearly have not seen the demand that features like custom attributes and function references have. 🤔 ---------------------------------------------------------------------- Thaddy · 2026-03-13 12:52 I guess 50% is candy and 50% is savoury. Meaning that if you examine the new features in trunk you are not looking very well which features have a profound impact on expression. I thoroughly enjoy and follow main/trunk and decide on a per application basis if the generated code is "production". Coverage is rather a different issue and may withhold people of using trunk for that reason. There are basically two really simple main constraint: time and knowledge. Users should take those into account:contribute or stop moaning. ---------------------------------------------------------------------- LeP · 2026-03-13 14:07 OT @Thaddy, first of all, best wishes for your success surgey. Quote from: Thaddy on March 13, 2026, 01:52:09 pmUsers should take those into account:contribute or stop moaning. Then, in response to the post, while you're right about rolling up your sleeves instead of complaining, I don't think that's the right approach. The Lazarus/FPC project is an open source project, and not everyone is capable of working on the source code and following the correct modification philosophy (not to mention lacking the appropriate technical knowledge). Many users have and are using Lazarus/FPC for commercial purposes, and therefore they can't go beyond the stable releases. Therefore, complaints must be acknowledged (obviously if they're justified) by the development teams. Then, development progress will proceed as it will, but a user with a complaint has a duty to raise it. Developing an open source project like this obviously exposes the development teams to some liability, and it should be normal for them to be put under pressure. ---------------------------------------------------------------------- dbannon · 2026-03-14 02:00 Yes LeP, thats accurate but not complete. The problem now is that FPC (main) has been allowed to evolve to far from FPC322 that its very hard to compare the two. It is, in effect, a new product. Maybe we need  new branch, fpc-ng, subject to some public testing and release as, just that, a new Pascal Compiler ? Ok, some jest included      Davo ---------------------------------------------------------------------- Fibonacci · 2026-03-14 09:14 Quote from: Thaddy on March 09, 2026, 12:10:35 pmQuote from: Fibonacci on March 09, 2026, 08:57:50 amAre inline vars in already? No and the core team has repeatedly stated they won't be implemented. Hypothetical question. If a core developer got, say, $5k USD for the work, would inline variables be implemented then? This is not really a question for you @Thaddy, but for the FPC core developers. I'm just curious whether the real limitation is technical, ideological, or simply time - and if money would change anything. Another hypothetical question. If someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk? FPC is not really true Pascal anymore anyway, so why not allow more modern features? Delphi already has them, and even you @Thaddy said you use Delphi CE for convenience, and then rewrite (degrade) the code for FPC, move the variable declarations to the top, and compile it there. ---------------------------------------------------------------------- LeP · 2026-03-14 09:51 Quote from: dbannon on March 14, 2026, 03:00:38 amYes LeP, thats accurate but not complete. The problem now is that FPC (main) has been allowed to evolve to far from FPC322 that its very hard to compare the two. It is, in effect, a new product. Maybe we need  new branch, fpc- ng, subject to some public testing and release as, just that, a new Pascal Compiler ? Ok, some jest included      Davo I didn't want to delve into the specific development difficulties of FPC, but the problem here seems to be that there's no concrete "governance" of the project and it's being moved haphazardly according to individual needs. The fact that the latest official stable version still has problems with "generics" (and has been for 5 years now) is illustrative. Quote from: Fibonacci on March 14, 2026, 10:14:10 amIf a core developer got, say, $5k USD for the work, would inline variables be implemented then? I'm just curious whether the real limitation is technical, ideological, or simply time - and if money would change anything. If someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk? Even if, as @FIbonacci says, someone were paid to make a new implementation (and it would be yet another one), on which version would it be applied, and what would be the release time and maintenance cycle? Always thinking of a SINGLE FPC, because otherwise it would be enough to create your own repo and develop independently. P.S.: many have claimed that the trunk version isn't ready for release and production, so what's the point of all the effort put into making changes to this "version"? I mean, is FPC still a viable product for building something reliable, or is it just for hobbyists? ---------------------------------------------------------------------- 440bx · 2026-03-14 10:00 Quote from: LeP on March 14, 2026, 10:51:55 amI mean, is FPC still a viable product for building something reliable, or is it just for hobbyists? A recent post from @PascalDragon specifically characterized FPC as being a hobbyist project. This came a bit as news to me since I remember reading somewhere that FPC was meant to be an "industrial strength" compiler.  Bottom line: it's kind of hard to know what FPC is at this point.  The one thing that is fact is that the upgrade/improvement cycle is rather long. ---------------------------------------------------------------------- marcov · 2026-03-14 11:25 Quote from: 440bx on March 14, 2026, 11:00:28 amQuote from: LeP on March 14, 2026, 10:51:55 amI mean, is FPC still a viable product for building something reliable, or is it just for hobbyists? A recent post from @PascalDragon specifically characterized FPC as being a hobbyist project. Probably mostly from a resource allocation and timescale perspective. QuoteThis came a bit as news to me since I remember reading somewhere that FPC was meant to be an "industrial strength" compiler.  Those are the goals, yes. Keep in mind it was born as a 32-bit TP replacement. So usability and compatibility was put before redoing the language with a purist bend. QuoteBottom line: it's kind of hard to know what FPC is at this point.  The one thing that is fact is that the upgrade/improvement cycle is rather long. Not exactly the same. More releases doesn't mean that development necessarily goes harder. The same development just get split up over more releases. ---------------------------------------------------------------------- 440bx · 2026-03-14 11:36 Quote from: marcov on March 14, 2026, 12:25:52 pmMore releases doesn't mean that development necessarily goes harder. Maybe not but, I believe that a serious piece of software (not a hobbyist thing) is characterized by a steady stream of releases to eliminate existing known bugs. Do you know what is currently holding up the release of 3.2.4 ? ---------------------------------------------------------------------- marcov · 2026-03-14 12:22 Quote from: 440bx on March 14, 2026, 12:36:41 pmQuote from: marcov on March 14, 2026, 12:25:52 pmMore releases doesn't mean that development necessarily goes harder. Maybe not but, I believe that a serious piece of software (not a hobbyist thing) is characterized by a steady stream of releases to eliminate existing known bugs. My point was that various aspects of the project can have various degrees of "seriousness", as you call it. One field, like compiler complexity can be further ahead than e.g. release engineering. QuoteDo you know what is currently holding up the release of 3.2.4 ? No. ---------------------------------------------------------------------- runewalsh · 2026-03-14 14:14 Quote from: 440bx on March 14, 2026, 12:36:41 pma serious piece of software (not a hobbyist thing) Since when is FPC a serious piece of software and not a hobbyist thing? :‌D ---------------------------------------------------------------------- marcov · 2026-03-14 14:29 Quote from: runewalsh on March 14, 2026, 03:14:54 pmQuote from: 440bx on March 14, 2026, 12:36:41 pma serious piece of software (not a hobbyist thing) Since when is FPC a serious piece of software and not a hobbyist thing? :‌D For me: Since I started doing work in it, somewhere since 2015-2018 period. ---------------------------------------------------------------------- PascalDragon · 2026-03-14 17:50 Quote from: Fibonacci on March 14, 2026, 10:14:10 amIf someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk? That already exists, we rejected it nevertheless. Inline variables don't fit the core concept of the language of separating variable declarations from their use which is one of the important points that makes Pascal easier to use than other languages. Quote from: LeP on March 14, 2026, 10:51:55 amI didn't want to delve into the specific development difficulties of FPC, but the problem here seems to be that there's no concrete "governance" of the project and it's being moved haphazardly according to individual needs. The fact that the latest official stable version still has problems with "generics" (and has been for 5 years now) is illustrative. From the compiler's point of view generics is a rather complex feature and only comparatively recently users have started to use them more seriously so of course issues continued to be discovered. That Delphi had to use that annoying ambigous syntax (compared to the non-Delphi modes that use keywords) doesn't make things much easier, because in the worst case the parser needs to do backtracking. ---------------------------------------------------------------------- Fibonacci · 2026-03-14 18:11 Quote from: PascalDragon on March 14, 2026, 06:50:13 pmQuote from: Fibonacci on March 14, 2026, 10:14:10 amIf someone made a proper, clean implementation of inline variables, would there be any chance of merging it into trunk? is one of the important points that makes Pascal easier to use than other languages. This is your very subjective opinion, and it couldn't be more different from mine. The lack of inline vars is genuinely painful to work with. I can't imagine coding in PHP without inline vars - that would be absolutely wild. Same goes for JS, C#, Rust, Go, or virtually any modern language. None of them enforce this artificial separation. The day any of those languages introduced such a restriction would be the day they died. And that's exactly why FPC is dead. A hobby project, maintained for old-timers, with museum value at best. A language artificially kept on life support by simply making it possible to compile on modern hardware - while the language itself remains frozen in amber. Thanks for the final confirmation - now I can leave FPC to rest in peace and move on Cheers! ---------------------------------------------------------------------- 440bx · 2026-03-14 18:51 @PascalDragon, Quote from: PascalDragon on March 14, 2026, 06:50:13 pmThat already exists, we rejected it nevertheless. Inline variables don't fit the core concept of the language of separating variable declarations from their use which is one of the important points that makes Pascal easier to use than other languages. I'm not particularly fond of Delphi's implementation of inline variables, there are definitely better ways to implement the feature than the one they chose.   With that out of the way, I believe you use C and/or C++ regularly and, if that is the case, you probably use C/C++ ability to declare variables just about anywhere.  The important point resulting from that, is that you must have noticed that there are many cases where that ability actually results in simpler and easier to understand code, which is one of Pascal's original design purposes. Personally, I've ported a fair amount of C code to Pascal and I've noticed that being able to have separate blocks of local variables in a function makes the function easier to understand.  In Pascal porting that function requires declaring all the block-scoped variables at the top of the function which makes them global to the function, which is inappropriate because they really are not global to the function, they only apply to a few statements.  Being at the top effectively turns them into annoying noise that only applies to a few statements that are normally in their own scope but, in Pascal must be at the global function scope. My point is: inline variables are fully consistent with Pascal's design purpose which is to facilitate the production of code that is easy to understand and maintain.  It's just a feature that has been missing in the language, one which enables _locality_ which is extremely important in good programming.    Its presence in Pascal would make the language easier to use and the code easier to understand. ---------------------------------------------------------------------- marcov · 2026-03-15 16:14 Quote from: Fibonacci on March 14, 2026, 07:11:01 pmThis is your very subjective opinion, and it couldn't be more different from mine. The lack of inline vars is genuinely painful to work with. I can't imagine coding in PHP without inline vars - that would be absolutely wild. Same goes for JS, C#, Rust, Go, or virtually any modern language. None of them enforce this artificial separation. The day any of those languages introduced such a restriction would be the day they died. And that is your very subjective opinion, dressed up with hollow phrases and comparisons to conceal/confirm preconceived biasses. QuoteThanks for the final confirmation - now I can leave FPC to rest in peace and move on Cheers! Tada! ---------------------------------------------------------------------- Curt Carpenter · 2026-03-15 17:37 Answering the question "anything new" with "no" is often a feature not a bug.  I think that's the case with Pascal, and I salute the developers that have (for the most part) resisted calls for innovations.  (The ultimate abstraction ("vibe code") will be upon mankind soon enough -- rage, rage against the dying of the light!). ---------------------------------------------------------------------- 440bx · 2026-03-15 17:54 Quote from: Curt Carpenter on March 15, 2026, 06:37:36 pmI salute the developers that have (for the most part) resisted calls for innovations. There are new features in FPC trunk, I don't know that I'd characterize them as innovations since, TTBMK, they have all been part of other programming languages for some time. ---------------------------------------------------------------------- Curt Carpenter · 2026-03-15 22:53 I don't know if being part of other languages is much of a recommendation though, especially weighed against a seriously stable platform.  But I'm old and that probably makes me anti-change in general.  Still, I bet there are plenty of system managers out there that shudder at the thought of new things being done to their COBOL ---------------------------------------------------------------------- 440bx · 2026-03-15 23:48 Quote from: Curt Carpenter on March 15, 2026, 11:53:40 pmI don't know if being part of other languages is much of a recommendation though, My point was that I haven't seen what I consider innovation in a computer language, including FPC, in a rather long time.  What I've seen a lot of is "cross polination", that is, features found in one language being adopted by another (whether or not those features are actually good and/or genuinely useful.) Quote from: Curt Carpenter on March 15, 2026, 11:53:40 pmBut I'm old and that probably makes me anti-change in general.  I'm a little bit on the old side myself and I don't want to waste my time on changes that implement very dubious features (I define those as features I need less than once a year.)  OTH, there are _many_ features I've longed for that are not implemented in any language and a few that are  only somewhat implemented.  Quote from: Curt Carpenter on March 15, 2026, 11:53:40 pmStill, I bet there are plenty of system managers out there that shudder at the thought of new things being done to their COBOL COBOL... that's a language that is very dear to my heart.  It has _plenty_ of deficiencies but when it comes to defining and formatting data, it puts C, C++ and Pascal put together to absolute shame.  That early 60s language does it better than the majority (likely all) currently popular programming languages.    I find it absurd how much time and effort is spent in other languages to do what in COBOL is done in seconds (and many times even less than a second if you are a reasonably fast typist.)   In spite of that, COBOL may very well be the "real programmers" favorite whipping boy (which reflects very poorly on those programmers because it shows a very severe lack of understanding of what a programming language is supposed to accomplish and how it should accomplish it.) ---------------------------------------------------------------------- LeP · 2026-03-16 08:31 Quote from: 440bx on March 14, 2026, 07:51:50 pm.........  you use C and/or C++ regularly and, if that is the case, you probably use C/C++ ability to declare variables just about anywhere.  The important point resulting from that, is that you must have noticed that there are many cases where that ability actually results in simpler and easier to understand code, which is one of Pascal's original design purposes. Personally, I've ported a fair amount of C code to Pascal and I've noticed that being able to have separate blocks of local variables in a function makes the function easier to understand.  In Pascal porting that function requires declaring all the block-scoped variables at the top of the function which makes them global to the function, which is inappropriate because they really are not global to the function, they only apply to a few statements.  Being at the top effectively turns them into annoying noise that only applies to a few statements that are normally in their own scope but, in Pascal must be at the global function scope. My point is: inline variables are fully consistent with Pascal's design purpose which is to facilitate the production of code that is easy to understand and maintain.  It's just a feature that has been missing in the language, one which enables _locality_ which is extremely important in good programming.    Its presence in Pascal would make the language easier to use and the code easier to understand. While I use inline variables often in Delphi, I have to say that this doesn't always improve code readability. It's an opportunity that should be used wisely. And the comparison with C/C++ is apt: in many C/C++ source files, you see scattered variables defined almost randomly, and reading the entire set isn't always easy. This doesn't happen in Pascal, and the ability to use inline variables could lead to this "drift." As always, it's the programmer who decides whether to write good code or not, it's not the novelty itself. ---------------------------------------------------------------------- Thaddy · 2026-03-16 08:46 In my C/C++ work, inline variables were also forbidden in the development guidelines. (As per the guidelines for the Linux kernel I believe, may I add) ---------------------------------------------------------------------- JuhaManninen · 2026-03-16 09:15 I also enjoy having a separate variable section when I study code made by others, or even made by myself some years ago. ---------------------------------------------------------------------- marcov · 2026-03-16 09:23 In my C work, I sometimes use them in case node blocks   In many cases I should have converted those to static inline functions completely anyway. But I'm mentally still in transition, since I only moved to a compiler that supports such functionality a few years ago. But while a quick and dirty convenience for myself, I do struggle to read other people's code that uses inline variables, and as said it is usually a smell that procedures are too long anyway. ---------------------------------------------------------------------- 440bx · 2026-03-16 09:31 Quote from: LeP on March 16, 2026, 09:31:29 amWhile I use inline variables often in Delphi, I have to say that this doesn't always improve code readability. There is no doubt in my mind that inline variables can be misused (particularly in Delphi), resulting in code that is not as easy to understand as could be but, I have not seen that often. Quote from: LeP on March 16, 2026, 09:31:29 amIt's an opportunity that should be used wisely. Agree.  Just like every other feature the language offers, not just that one. Quote from: LeP on March 16, 2026, 09:31:29 amAnd the comparison with C/C++ is apt: in many C/C++ source files, you see scattered variables defined almost randomly, and reading the entire set isn't always easy. I _very rarely_ see inline variables abused/misused in C/C++ code, very much unlike the preprocessor that is very often misused/abused... I mention that because misusing inline variables isn't easy (unlike abusing/misusing the preprocessor.)  I believe the misuse of inline variables would be obvious even to a beginner, which is why misuse/abuse of inline variables is very seldom seen (at least in C/C++, I don't really know in Delphi.) Quote from: LeP on March 16, 2026, 09:31:29 amThis doesn't happen in Pascal, and the ability to use inline variables could lead to this "drift." What happens in Pascal is that there are _often_ variables at the global function level that should NOT be at that level, instead they should be _local_.   A very commonly seen example of that are index variables (such as "i"), those indexes should NOT be function global, they should be local to the loop (for _more_ than one reason.) The inability to define those indexes locally is a major deficiency in the Pascal language. Quote from: LeP on March 16, 2026, 09:31:29 amAs always, it's the programmer who decides whether to write good code or not, it's not the novelty itself. That's true but, there are features, in the case of inline variables a structural feature, that _enables_ the programmer to write better, cleaner, simpler code and, that structural feature is missing in Pascal (and poorly implemented in C/C++, of course, that's no surprise but, at least they have something that does the job, even if not as well as could be.) Quote from: Thaddy on March 16, 2026, 09:46:49 am(As per the guidelines for the Linux kernel, may I add) And how do they justify that ?   Is that some commandment ordained by a higher power appearing next to a burning hard drive ? or is there a _logical_ solid foundation to justify it ?  Just in case, are you saying that _nowhere_ the Linux kernel uses something like "for (int i = 1; i < SomeValue; i++) { some code here }" because the declaration of "i" in the "for" itself is an inline variable declaration.  I find it very difficult to believe that's not used in the Linux kernel or any other Linux-related C/C++ program that does something useful.  From what I've seen that type of inline variable in C is probably more common than a Papiermark unit was in the early 1920s. Dogma is worthless and there is way too much dogma in programming. ---------------------------------------------------------------------- Thaddy · 2026-03-16 09:46 This seems to have changed in the past. Simple ones are allowed. More complex ones discouraged. It used to be the case, though, also because back in the days C compilers did not even allow it. ---------------------------------------------------------------------- jamie · 2026-03-16 10:30 There was talk about enhancing the WITH operator to open a branch of local variables, whatever happened to that? Jamie ---------------------------------------------------------------------- marcov · 2026-03-16 13:36 Quote from: jamie on March 16, 2026, 11:30:54 amThere was talk about enhancing the WITH operator to open a branch of local variables, whatever happened to that? Afaik there was only talk. I had some sympathy for it in principle, but that is more from the viewpoint of what I would do in a new language. Too many seldomly used features make a language baroque and unmaintainable. ---------------------------------------------------------------------- simone · 2026-03-16 15:36 My opinion on inline variables is uncertain. Therefore, my question should not be interpreted as a provocation, but rather as an attempt to understand the current goals of this project. If inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal? To reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}? ---------------------------------------------------------------------- PascalDragon · 2026-03-16 15:58 Quote from: 440bx on March 16, 2026, 10:31:33 amQuote from: Thaddy on March 16, 2026, 09:46:49 am(As per the guidelines for the Linux kernel, may I add) And how do they justify that ?   Is that some commandment ordained by a higher power appearing next to a burning hard drive ? or is there a _logical_ solid foundation to justify it ? Originally the C compilers used for Linux did in fact not allow the declaration of variables after the first statement of a block that isn't a variable declaration. So back then it was in fact enforced by the compiler itself. Nowadays the reasoning is the same as Pascal had ever since: it makes it easier to find what variables are declared. Quote from: 440bx on March 16, 2026, 10:31:33 amJust in case, are you saying that _nowhere_ the Linux kernel uses something like "for (int i = 1; i < SomeValue; i++) { some code here }" because the declaration of "i" in the "for" itself is an inline variable declaration.  I find it very difficult to believe that's not used in the Linux kernel or any other Linux-related C/C++ program that does something useful.  From what I've seen that type of inline variable in C is probably more common than a Papiermark unit was in the early 1920s. You can in fact find both styles inside the kernel, namely with the loop variable declared separately and with the loop variable being declared as part of the loop header. I don't know right now whether the original compilers used for Linux allowed for the loop variable declaration inside the loop header or not. And at least in the kernel's coding style there's no mention regarding the declaration of loop variables (except that they should be named using simple names). Quote from: simone on March 16, 2026, 04:36:18 pmIf inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal? To reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}? Adding them for one mode nevertheless means that they need to be maintained in general. I for one have no desire to maintain that nonsense. ---------------------------------------------------------------------- simone · 2026-03-16 16:13 These seem definitive words to me. As in all open source projects, whoever writes the code decides the direction.  Now I'm perfectly aware that FPC/Lazaurs and Delphi are each going their own way. ---------------------------------------------------------------------- 440bx · 2026-03-16 16:14 Quote from: simone on March 16, 2026, 04:36:18 pmIf inline variables are conceptually rejected by core developer, given that Delphi implements them, does this mean that compatibility with Delphi is no longer the project's goal? I've wondered that too. Quote from: simone on March 16, 2026, 04:36:18 pmTo reconcile fidelity to Pascal's tradition with compatibility with Delphi, could they be implemented only in {$Mode Delphi}? I'm not an FPC developer but, IMO, it makes little sense to have such a major feature be available in Delphi mode only.  I say that because I feel the ObjFPC mode is the "native" FPC mode, therefore omitting such a significant feature from that mode would pretty much amount to splitting the compiler's development. Just my $0.02... Quote from: PascalDragon on March 16, 2026, 04:58:18 pmOriginally the C compilers used for Linux did in fact not allow the declaration of variables after the first statement of a block that isn't a variable declaration. So back then it was in fact enforced by the compiler itself.IIRC, that was circa mid-90s.  Lots of water (i.e, new features) have flowed under the bridge since. Quote from: PascalDragon on March 16, 2026, 04:58:18 pm Nowadays the reasoning is the same as Pascal had ever since: it makes it easier to find what variables are declared. Actually, I believe it is the opposite of that.  Inline variables make it clear which variables are genuinely global to the function because they are not mixed with "supporting" variables that are used only by a very small number of statements in the function, e.g, loop indexes.  That said, I don't like the way the feature is implemented in Delphi, it's very poor but, I guess, it's better than nothing. Quote from: PascalDragon on March 16, 2026, 04:58:18 pmYou can in fact find both styles inside the kernel, namely with the loop variable declared separately and with the loop variable being declared as part of the loop header. Which makes sense, parts of the code reflect the fact that it was written when the compiler did not have the feature while newer code is rather likely to use the feature since it makes for cleaner and clearer code. ---------------------------------------------------------------------- simone · 2026-03-16 16:47 Quote from: 440bx on March 16, 2026, 05:14:43 pmActually, I believe it is the opposite of that.  Inline variables make it clear which variables are genuinely global to the function because they are not mixed with "supporting" variables that are used only by a very small number of statements in the function, e.g, loop indexes.  That said, I don't like the way the feature is implemented in Delphi, it's very poor but, I guess, it's better than nothing. I completely agree. This is why Delphi, C++, C99, Java, C#, Go, Javascript, Python, Ruby, PHP, Rust, Swift, etc. have this feature. ---------------------------------------------------------------------- Fibonacci · 2026-03-19 04:45 Upstream said no. FPC Unleashed says yes - inline variables, statement expressions, array equality, no-RTTI mode, and more. Demo below (screenshot attached): Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program app; procedure main;begin  // *** INLINE VARIABLES ***   var s := 'hi there';  var i := 42;  // or  var s2: string := 'hello';  var i2: integer := 66;   writeln(s, ' | ', i);  writeln(s2, ' | ', i2);   // *** INLINE VAR IN FOR LOOP ***   for var j := 1 to 5 do writeln('j = ', j);   // *** STATEMENT EXPRESSIONS + INLINE VARIABLES ***   randomize;  var d := if random(20) > 10 then 'less than 10' else 'more than 10';  writeln('d = ', d);   // *** FOR-IN + INLINE VAR ***   var a := ['foo', 'bar', 'baz'];  for var z in a do writeln('a[] = ', z);   readln;end; begin  main;end.  This is WIP and experimental. A hobby project - just like FPC. Compiles and runs, see for yourself. Want to try it? The project is here: https://github.com/fpc-unleashed/freepascal Install via fpcupdeluxe. Open fpcup.ini and add to the top of [ALIASfpcURL]: Code: INI  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unleashed.git=https://github.com/fpc-unleashed/freepascal.git  For Lazarus Unleashed (with autocomplete support for some of the new features), add to the top of [ALIASlazURL]: Code: INI  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i unleashed.git=https://github.com/fpc-unleashed/lazarus.git  Optionally enable docked IDE in Setup+, then click Install/update FPC+Lazarus. ---------------------------------------------------------------------- 440bx · 2026-03-19 07:06 @Fibonacci, I believe that the emergence of a forked/new version of Pascal should have its own thread. That would make it crystal clear that the posts are specific to the new version and not the existing FPC version. I suggest you create a new thread where the initial post is the one you posted above to introduce the "FPC Unleashed" version.  (For some people it may be the last post on the previous page.) ---------------------------------------------------------------------- Fibonacci · 2026-03-19 07:18 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 · 2026-03-19 07:37 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 · 2026-03-19 07:44 So which board would you suggest?   Free Pascal -> General   Free Pascal -> FPC development   Miscellaneous -> Other ---------------------------------------------------------------------- creaothceann · 2026-03-19 07:59 "Third party" or "Miscellaneous -> Other" ---------------------------------------------------------------------- 440bx · 2026-03-19 08:10 As suggested by @creaothceann, I'd go for Miscellaneous -> Other ---------------------------------------------------------------------- VisualLab · 2026-03-19 08:34 Quote from: Fibonacci on March 19, 2026, 08:18:57 am... 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) ... 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 · 2026-03-19 08:46 Quote from: VisualLab on March 19, 2026, 09:34:14 amQuote from: Fibonacci on March 19, 2026, 08:18:57 am... 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) ... 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 · 2026-03-19 09:04 Quote from: Fibonacci on March 19, 2026, 09:46:16 amOfficial 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 · 2026-03-19 09:14 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 · 2026-03-19 09:31 Quote from: VisualLab on March 19, 2026, 10:04:49 amQuote from: Fibonacci on March 19, 2026, 09:46:16 amOfficial 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i --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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$expose} placed before the class declaration. Quote from: Thaddy on March 19, 2026, 10:14:30 amPity 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. Quote from: Thaddy on March 19, 2026, 10:14:30 amIf then else is a commit away. I hope. Quote from: Thaddy on March 19, 2026, 10:14:30 amBTW: 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. Quote from: Thaddy on March 19, 2026, 10:14:30 amAs 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 · 2026-03-19 10:00 9 months? The commits seem to suggest otherwise. ---------------------------------------------------------------------- marcov · 2026-03-19 10:08 Afaik Delphi has a $RTTI directive to omit extended RTTI. By default I haveCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  {$RTTI EXPLICIT METHODS([]) PROPERTIES([]) FIELDS([])} in my delphi projects ---------------------------------------------------------------------- Fibonacci · 2026-03-19 10:13 Quote from: Thaddy on March 19, 2026, 11:00:27 am9 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 · 2026-03-19 10:16 Quote from: marcov on March 19, 2026, 11:08:14 amAfaik Delphi has a $RTTI directive to omit extended RTTI. By default I haveCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  {$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 · 2026-03-19 11:39 Quote from: Fibonacci on March 19, 2026, 11:16:55 amQuote from: marcov on March 19, 2026, 11:08:14 amAfaik Delphi has a $RTTI directive to omit extended RTTI. By default I haveCode: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  {$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. ---------------------------------------------------------------------- Thaddy · 2026-03-19 13:09 As far as I know the syntax in FPC main is the same as in Delphi at least as the screenshot is concerned. (It lacks docs, though) ---------------------------------------------------------------------- dbannon · 2026-03-20 05:31 Quote from: Thaddy on March 19, 2026, 10:14:30 amAs 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) Two years of fixes unacceptable Thaddy. How about the battlers still using FPC322 ? Davo ---------------------------------------------------------------------- valdir.marcos · 2026-03-21 05:47 Quote from: dbannon on March 20, 2026, 06:31:29 amQuote from: Thaddy on March 19, 2026, 10:14:30 amAs 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) Two years of fixes unacceptable Thaddy. How about the battlers still using FPC322 ? Davo Excellent question to Thaddy! I will improve it a little bit: Two years of fixes are unacceptable, Thaddy? How about the uncountable daily battlers that are still using 5-year-old FPC 3.2.2? Status of FPC 3.4.0 or FPC 4.0.0 [major release] https://forum.lazarus.freepascal.org/index.php/topic,73355.0.html ---------------------------------------------------------------------- Thaddy · 2026-03-21 19:05 Well, I use trunk/main almost solely and 3.2.2/3.2.4 only for testing. Very few users need to confine themselves to 3.2.4, even fewer to 3.2.2. But that is opinion, not fact.