Hello! Anything new?

[Fibonacci]

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]

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]

Thanks

 

[440bx]

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]

Are inline vars in already?

No and the core team has repeatedly stated they won't be implemented.

Has 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]

Are 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.

The 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]

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]

The status of the

Have 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.

[Nimbus]

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]

Has 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.   

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.

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]

"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]

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]

OT
@Thaddy, first of all, best wishes for your success surgey.

Users 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]

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]

Are 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.