New language features?

[Muus]

I read it and I do not agree with 99% of it.

You are funny because we both use FPC so my comment wasnt even towards you as a target audience for things to fix. Yet you still have this weird attitude. It's not about me or you but about attracting contributors and welcoming them. You are proving me right immediately, I guess I can thank you.

But I was talking about beginners and getting them onboard and you immediately go for the "solve it yourself with a stylesheet". I can't solve what a new person to freepascal.org sees with a stylesheet on my end. Though again, you prove me right as what the general attitude from veterans are to such things like this. So to that end, thanks.

[440bx]

the fact Pascal lets you access uninitialized memory outside of the scope in which it's allocated is a design flaw of the language.

It's a fact of programming that there is information that is global to an application and that information will be accessed by various sections (functions/procedures) of the program as needed.  Therefore, except in trivial programs, accessing memory in routines other than the one that allocated it is, not only normal but, a necessity.

As an aside, I read a lot of code written in C and C++ and I find that one of the most common habits is _not_ initializing variables at the time they are declared (strangely C programmers are better about initializing variables than Pascal programmers are.)  The point is, programmers who don't initialize variables can't complain a variable isn't initialized.  (three guesses as to why the variable isn't initialized...)

Because declaration and assignment are disjointed you can never be sure if the memory is actually initialized or not.

that's a matter of programming discipline.  No language can force a programmer to produce a good design and good code.  That doesn't exists and the languages that attempt to impose "good rules" on programmers often create as many problems as they solve if not more.

The biggest disadvantage that new programmers face is that the sources of good programming advice are roughly 3 decades old if not more.  Today, I couldn't be paid to read some of the books that are "highly recommended" by industry-recognized "experts".  (I unfortunately have wasted some of my time perusing them... oh well)

Aside from Ada and Modula-"n", I find that most programming languages today leave a great deal to desire (I'm being really kind, I consider most of them to be embarrassments... IMO, it is extremely rare when it is justified to place the word "science" after the word "computer".)

Pascal isn't perfect but everything considered it's pretty good, particularly FPC (it's not wart-free but, nothing's perfect anyway.)

Lastly, when it comes to learning how to program, it is still the best language to learn.  A good book to learn programming and Pascal is "Oh Pascal" from Doug Cooper  (probably 40 years old if not more.)

[Ryan J]

the fact Pascal lets you access uninitialized memory outside of the scope in which it's allocated is a design flaw of the language.

It's a fact of programming that there is information that is global to an application and that information will be accessed by various sections (functions/procedures) of the program as needed.  Therefore, except in trivial programs, accessing memory in routines other than the one that allocated it is, not only normal but, a necessity.

I'm not saying the language should be like Swift and never allow nullable pointers but the most common case is that you need to allocate some memory (like a class) in a particular scope and there's no reason whatsoever to allow it to be accessed outside of the scope, and if fact doing so would be  crash. The lifetime of variables being fixed to routines is simply wrong in terms of how the memory is used. I know there are times you must do this but there are many others when you don't and Pascal doesn't give you this option because of it's "declare before use" syntax.

[marcov]

Well Free Pascal suffers from inertia as well

Which is a good thing in a mature project. It took C++ 35 years to follow Modula-2 and Pascal's lead with a module system, but I don't hear anyone compiling.

, one can just look at the RTL docs that the code examples have no syntax highlighting or proper formatting, the user's guide is one massive list, the amount of switches in the languages as-is is beyond comprehension.

Which RTL docs? The PDFs are authoritative, and can be highlighted using anything in the latex LISTINGS package. You are welcome to code a html highlighter for the html generator.

It is open source, everyone is responsible.

Not only by themselves but also by how they are laid out (see attachment). Not to mention that Lazarus cant be used as an editor on its own, you HAVE to open a project and as someone who uses Castle Engine, one look at the ifndefs and switches used and any argument about "readability" and "pascal way" goes right out the window.

That is no problem. For children's programming, there is  Scratch, in case you teach groups that can't handle mature tooling.

The different amount of files .lpr,lps,lproj, .pp, .fpc, ppu, inc and fpmake, compiler magic functions and to beat the limping horse to the ground a bit; This is before you even get to the naming of the files vs the unit X; definition having to match.

If you can't master 10 filetypes, then I wonder what _IS_ achievable in your book.

Implementing what Delphi is doing like inline vars or skipping @ in callbacks or w/e can stay in Delphi but _sane_

The @ in callbacks is gone if you switch to Delphi mode, no implementation needed.  Inline vars is a different subject, but sufficient to say, if there are two ways of doing things, supporting them both is usually the worst option. We have that situation with generics and that @ and IMHO it is a nuisance.

Delphi simply hoped for some easy money by appearing "modern" and cash in on the various mobile vibes. They didn't care if any of them succeed, as long as they get a few years of subscriptions of hopefuls.

But we don't really benefit in anyway from newbies. We need them to mature and contribute.

But duck taping on features from other languages doesn't make the language better, it makes it worse, since you can't abandon the old syntax out of compatibility.

defaults rather than {$than edge-case-for-syntax-used-10-years-ago-compat} supporting would go a long way already.

You can always write a specialized lazarus distribution (that e.g. defaults to {$mode delphi} etc for Castle usage. This ifdeffing is simply because neither faction that use FPC/Lazarus is big/strong enough to deal with what is essentially  a fork, albeit one that looks at the original as upstream. (only CodeTyphon exists, and there is a discussion how much customized code is really in there, it might not even qualify.)

The language server tooling is also lacking, although Michelis does impressive work and it's improving steadily.

Yes. That is what people that want something do. They work on it, rather than rant in forums.

But ranting on the forum is kinda pointless anyway, someone like marcov will come along and ask where my patches are but contributing means that the patch should go to a team that is amicable towards those patches to begin with, when you have the main devs already throwing the brakes on it just means whoever sent that patch becomes the maintainer and 5 years from now it'll be "old and unmaintained". Since I just lurk and see discussions like this often the core devs (or at least the ones that talk here) already sound cynical about peoples contributions do not motivate in the slightest.

Always eager to please :-)

(and while I don't think you have considered it, giving a response, even if negative is still work. I could have ignored the discussions like most other devels)

One would think that if someone came with a suggestion that they'd get encouraged to contribute rather than "well where's your patch then?"

Contribute is something different than forcing decisions about course in the project. There are many contributors that work in their niche, and slowly growing into the project.

The ranters that you see on the forum are however a vocal minority that want to direct start making crucial course discussions using a one of patch , usually of some highly visible language feature. (and it is _always_ about language syntax. Forks about internals of the compiler are rare)

Those ranters are to lazy to grow into the project, and usually no hope that the person ill be around to finish issues with the patch, let alone do long term work there.  And if they are rebuffed, or even just corrected a bit in their views, they rant, and whine that core doesn't really want contributors.

What do you think was the last time a feature ended up due to ranting into C# or C++ ? Do you really think blackmailing with a patch is a normal way ?

The contributions wont come if the motivation is lacking from the people at the top.

Contributions won't come from those kind of people period. There will always be something that offends their "my way or the highway" kind of viewpoint.

The main page of freepascal not being updated has also been mentioned before but development activity can also be shown in the header about when the last commit was and what about. Or the latest actual version _and_ snapshot with date attached to it; maybe dont mention LLVM backend development _last_ in the paragraph after uhm, the Motorola 68K and uh, DOS; Actively hiding dev activity (on top of outdatedness) on the frontpage of a Pascal compiler that already has an inherent "oldness" bias towards it (even if unwarranted and FPC is great; theres just a few rough edges) would be the first thing to fix.

I think this is also the fate of a backend technology like a compiler. The web presence of binutils of gdb is also not exactly impressive.

The website not having a new look, ordained and approved by greybeards on this forum by a _core_ dev nor random contributor in a decade already shows preference towards inertia.

Sorry, did I miss a submission or offer? Can't remember.

tl;dr project intro is as outdated as a 56k modem, the rather cynical responses, no little blurbs about whats added, lack of modern documentation layout (Sphinx exists, so does PasDoc)

And so does fpdoc. It just needs people doing things, not just whining and doing false comparisons with heavily sponsored projects. Or just fork over the dough.

Overall I just get an "ANTI" vibe from your posts, desperately trying to fling various bits of unrelated grievances to make a point. It feels more like a venting of undirected frustration than a well made case for some change.

There is no plan except "core should do this" or "core should make sure that" from an extreme helicopter viewpoint without much detail.

[Thaddy]

Hear, hear.

[Muus]

Well at least I feel like you read most of what I said but skipped over understanding it. The only reason I mentioned Delphi is because those features are _whatever_, as in, not desired nor dealbreaking. In fact ommitting the @ is bad. And if you look at Simone's comment,

...
But since Delphi has recently introduced new (and questionable, I agree) features into the language like the ones described here:

https://blog.marcocantu.com/blog/2018-october-inline-variables-delphi.html

which the core developers reject on principle, as they violate the founding philosophy of Pascal, consisting of "declare before using", it seems clear to me that Delphi and FPC have taken different paths.

This is one of the main problems of object pascal: lack of standardization and proliferation of dialects... The ISO 7185:1990 and ISO/IEC 10206:1991 standards, if I remember correctly, concern classic pascal, not object pascal.

since I assume you know how forums work I expected it wouldn't be necessary to once again state that copying Delphi should NOT be a goal but to be its own thing. I can't even use Delphi, haven't used a Windows system in over a decade, I don't write proprietary software either nor run Windows in any VM. The lovely switch combos like {$H+}{$J-} or whatever combo you want should not be needed. Either you get Delphi mode or not, and if it's half assed and not really like Delphi; well too bad. Burderning a potential objfpc (mode from terminal, not in source) file with  different buttons and switches to really specify behaviour as such does not make the language more ergonomic. Implementing halfbaked namespacing is in a similar vein. Metaprogramming is nowhere to be seen, contract programming neither and ifndef's just pile on more curly brackets to the point where the language in some has more curly brackets than begin/ends.

Well clearly you think Lazarus way of doing this is great user experience but it's not, the tooling _not_ to work with Lazarus at all is getting better though but that's not coming from anyone involved here. It's also not what I'm contributing to because as you and Thaddy put on display, changes aren't wanted. However if Castle Engine does want new people to use the engine and to work with it, sadly they do have to get FPC in some manner. That means seeing this UI/UX that was outdated in the mid 2000s. Seeing as FPC clearly doesn't want new blood into the ecosystem, disconnecting it from FPC altogether in branding and simply rebadging would be better for modern projects that do want new users; but I wouldnt be surprised if comments were to be made "why not contribute to FPC instead" in some shape or form.

And let's be honest, being a compiler backend website is no excuse when it comes to not updating the design, you also implement the language as there's no alternative. Even a GNU project like Guile manages to look not outdated which should tell you something. Not to mention the likes of OCaml or D (which also has its own back end plus GCC/LLVM, who do look outdated but they are not the main reference for Pascal beginners).

Plus in the time it took you to reply you could also have made a change but you wrote this reply instead so ranting on the forums seems to be just as enjoyable for you. In any case, being downstream from FPC is a net-negative because if they have look up any reference, oh boy, lets go to the weirdly aligned purple gradient that has white stripes admidst white text. They want to look up something for arrays? Better hope they don't hit https://www.freepascal.org/docs-html/current/ref/refsu14.html#x38-500003.3.1 where the documentation and code are not clearly delineated with no highlighting. Looking beyond dated.

With an eye to contributing to fixing this, neither of you nor Thaddy said "Well, if you can improve it for us please do" or "Show us a concept". You tell me to edit on my own end instead. Potential Castle Engine users, whose average age is not 45 and didn't do button{1,2,3} style but come from Unity or potentially looking for an engine that suits their needs would be put off immediately by whats shown here. I am not unwilling to contribute but the cathedral that's on display, let alone the people that control it simply don't think it couldn't be any better, I guess. I am not suggesting to revamp the whole site but this consistency in shutting people down rather than, I don't know, looking at any other programming language project that does want to improve _and_ is getting fresh blood in is foreign to some here.

As it is now, both you and Thaddy are just fine with it being the way it is but Thaddy doesn't parse non-Pascal text as we've seen, preferring to lash out and my account is 6 years old, lurking a long time, so I've seen you (marcov) being cynical towards people who ask for even the slightest change. I understand completely where it comes from but this place does not exhude collaborative environment. Hence the comment. Here's another one for the record books, I guess.


^{En nu moet ik naar de Jumbo, krieg mien tog honger}

[marcov]

Well at least I feel like you read most of what I said but skipped over understanding it.

Well, I can only understand what you write.

The only reason I mentioned Delphi is because those features are _whatever_, as in, not desired nor dealbreaking. In fact ommitting the @ is bad. And if you look at Simone's comment,

I was back then (in the previous century) a proponent of @, it was all about FPC going its own way etc etc etc. I've since regretted that. Same reaason as generics or inline vars. If there are two ways to implement a feature, having them both is the worst choice, regardless of which one of the two is slightly better or not

since I assume you know how forums work I expected it wouldn't be necessary to once again state that copying Delphi should NOT be a goal

Well, it is since we kinda of a Delphi compatible compiler. The goal is to provide a production environment, not a playground for language experimentation. The inline var thing is a special case, quite far from the baseline Delphi functionality, and since the component builders we primarily target usually only slowly absorb features, there is time. See also the namespace bit below.

but to be its own thing. I can't even use Delphi, haven't used a Windows system in over a decade, I don't write proprietary software either nor run Windows in any VM.

Well, you are not the only FPC user.

The lovely switch combos like {$H+}{$J-} or whatever combo you want should not be needed.

Those combos are the mark of a grown up language. Only toy languages don't have legacy, even if it is the remnants of language experimentation like {$mode objfpc}.

Backwards compatibility is really the only way, unless something changes majorly and we get ginormously more developers. Otherwise your new ideal configuration will be outdated before it is actually implemented.

Implementing halfbaked namespacing is in a similar vein.

I do have my own doubts about that functionality too. Halfbaked is IMHO too much credit.

However it is a delphi compatibility item, though, like inline vars, a bit far further the baseline. Again some desperate attempt from Embarcadero's PR department to  make it seem more "modern", without implementing the actual feature. Justt from a different (2007-2009) era, when .NET was all the rage.

But be that as it may,  that is meanwhile engrained after 13 years. Maybe in 13 years, inline vars will be the same.

Designing a language top down and only judge on one single moment in time is easy. Implementing a language with 50 years of legacy is slightly different.

Metaprogramming is nowhere to be seen,

I never got the memo this should be part of a language. Usually it is only used to paper over language defects, or, more specialised in dedicated codegenerators

contract programming neither

So what is implementing an interface according to you?

and ifndef's just pile on more curly brackets to the point where the language in some has more curly brackets than begin/ends.

As said, a minor amount of that can't be avoided in a grown up language. 

Well clearly you think Lazarus way of doing this is great user experience but it's not, the tooling _not_ to work with Lazarus at all is getting better though but that's not coming from anyone involved here.

Well, there are some people loving VSCode, but I always failed to see the attraction.

It's also not what I'm contributing to because as you and Thaddy put on display, changes aren't wanted.

Or maybe because it is easier to blame others than to take a long hard look at yourself?

And let's be honest, being a compiler backend website is no excuse when it comes to not updating the design, you also implement the language as there's no alternative. Even a GNU project like Guile manages to look not outdated which should tell you something

Not to mention the likes of OCaml or D (which also has its own back end plus GCC/LLVM, who do look outdated but they are not the main reference for Pascal beginners).

I don't make excuses. I just try to provide a explanation why even people with a somewhat serious attitude chose to work on the codebase rather than the website.  Apropos, Guile has a newest news item from early 2023, not sparkly fresh either, and an year older than the newest news item on the FPC site.

With an eye to contributing to fixing this, neither of you nor Thaddy said "Well, if you can improve it for us please do" or "Show us a concept".

I at least do. But to do so, I do have to have some hope that such request will land in somewhat fertile grounds. I simply don't want to induce false hope where I tell people to come up with something that is far out of the projects course just to get rid of them, only for them to be rejected after a lot of work.

You tell me to edit on my own end instead. Potential Castle Engine users, whose average age is not 45 and didn't do button{1,2,3} style but come from Unity or potentially looking for an engine that suits their needs would be put off immediately by whats shown here.

I do think if you want to make very Castle Engine specific modifications as changing the dialect default, a fork is the way to go yes. If it is such a big deal for you, it might even be worth it.

I am not unwilling to contribute but the cathedral that's on display, let alone the people that control it simply don't think it couldn't be any better, I guess. I am not suggesting to revamp the whole site but this consistency in shutting people down rather than, I don't know, looking at any other programming language project that does want to improve _and_ is getting fresh blood in is foreign to some here.

As I said in my previous message "my way or the highway" is not a constructive attitude for  a new contributor. A bit more flexible thinking about ways to reach goals might be in order. Stay away from contented subjects like language dialect.

So avoid staring down core members that have to weigh various uses of the project and try to force them to make some landslide decision.

If that means that you have to fork to get  something Castle specific, fork and start something Castle specific. If it takes of, some merger at a later point can still be discussed.

We developers are also humans, and our view on the project is not constant and might change over time.

As it is now, both you and Thaddy

Thaddy is also not core, so does not speak to the project. 

I myself, though a developer, also don't speak for the project in an absolute, definitive way. You can always ask a different developer for a 2nd opinion.

_BUT_ I only try to avoid raising false expectations, and I don't like it when threads about change are left hanging  without any developer answer, met by universal silence. Yes, I do realise that being the messenger of bad news doesn't always make me popular, but at least give me some credit for it.

Luckily it is not needed as much as it used to be since Pascaldragon (who has implemented the bulk of dialect changes in the last half decade or more) also weighs in on dialectal matters. Feel free to bug him, if my answer is not satisfactory. I'm sure he'll thank me for that.

[Bart]

About the docs.
They are written in Latex if I'm not mistaken, and the documaetations has it's own bugtracker.
So, you're more than welcome to provide patches there.

If you know a better way to translate the Latex to html with a more modern look, IMO you're welcome as well.
We might either not have the expertise, or just lack the time to do this.

Also I take objection to phrases like:

Plus in the time it took you to reply you could also have made a change

The changes you propose (without even giving a hint on how to achieve this) are not something you can accomplish in say 30 minutes.
This is just insulting the team.

With an eye to contributing to fixing this, neither of you nor Thaddy said "Well, if you can improve it for us please do" or "Show us a concept"

Well, I'm inviting you.
But radical changes like getting rid of {$mode xxx} or {$modeswitch yyy} are just not realistic.

Notice that I'm not an fpc devel.

Last but not least: if you're hungry, don't post messages on the forum, get something to eat first.

Bart

[marcov]

If you know a better way to translate the Latex to html with a more modern look, IMO you're welcome as well.
We might either not have the expertise, or just lack the time to do this.

For the RTL guide this should be very doable, and a nice task for a junior developer. Probably fpdoc just simply loads the example and stuffs it in a PRE tag or so.

[Muus]

I was back then (in the previous century) a proponent of @, it was all about FPC going its own way etc etc etc. I've since regretted that. Same reaason as generics or inline vars. If there are two ways to implement a feature, having them both is the worst choice, regardless of which one of the two is slightly better or not

...
I do have my own doubts about that functionality too. Halfbaked is IMHO too much credit.

However it is a delphi compatibility item, though, like inline vars, a bit far further the baseline. Again some desperate attempt from Embarcadero's PR department to  make it seem more "modern", without implementing the actual feature. Justt from a different (2007-2009) era, when .NET was all the rage.

But be that as it may,  that is meanwhile engrained after 13 years. Maybe in 13 years, inline vars will be the same.

Designing a language top down and only judge on one single moment in time is easy. Implementing a language with 50 years of legacy is slightly different.
...

As said, a minor amount of that can't be avoided in a grown up language. 

It doesn't end up being minor though, at least not always although you see the snippets here that post as answers to help and it wraps $T+ or advanced records on top of it, the readability suffers. I'd rather look at actual code but I guess FPC built itself in this corner. Some might not find that as annoying, but I guess there's no easy line to draw at which point are you programming-through-compiler-instrinsic or Pascal. I'd prefer it to be Pascal or at least 1 implementation that's somewhat void of them. If FPC and Delphi were the only two modes with the latter being fully implemented, I'd probably be programming in the latter too. But only if it truly went _full send_ on either mode.

Well, there are some people loving VSCode, but I always failed to see the attraction.

tmux + nnn + nvim is the way to go. It definitely is not my favorite either.

Or maybe because it is easier to blame others than to take a long hard look at yourself?

Hmm, when I clearly write that my issue is more the presentation and layout of FPC and explicitly say that I dont care about inline vars or not and some greybeard jumps in with the attitude I mentioned in the same paragraph, I see no need to look in the mirror.

I don't make excuses. I just try to provide a explanation why even people with a somewhat serious attitude chose to work on the codebase rather than the website.  Apropos, Guile has a newest news item from early 2023, not sparkly fresh either, and an year older than the newest news item on the FPC site.

I am sure you can tell the difference in presentation, how to get started is not in some sidebar and there's examples right in the center. Itself it's used for Guix, a Linux distro similar to Nix. But you knew what I meant, I'll play along, haha.

I at least do. But to do so, I do have to have some hope that such request will land in somewhat fertile grounds. I simply don't want to induce false hope where I tell people to come up with something that is far out of the projects course just to get rid of them, only for them to be rejected after a lot of work.

Well, I am sure Im not the only one who has come and gone by, saying that some landmowing might be in order to tidy things up. No one seems to be willing to do it nor care, it's not an observation at that point to say it's unwillingness to change. I assume you can change a banner or a layout as well, you can counter this with why dont I do it; well my point is that the people who've said this are countless, years gone by and yet; still the same.

Personally I'd want the software I worked on to also be presented well, but if the FPC devs themselves are fine with it, alright. Though FPC devs shouldnt complain about lack of manpower if they don't care to market themselves well, zero attempt is made to actually make things obvious but it's already been explained, though not in many words, that the only people expected to visit freepascal.org are people who wrote Pascal in the 90s and need their Delphi 7 nostalgia app back up and running then alright. I do want to finish on the point that both you and Thaddy deviated from what I was saying, that the UI/UX leaves much to be desired and that I feel that it hurts the project with the general attitude towards this being derision and hostility (which got proven immediately). It could have been distilled into a much smaller thing and me saying 'hey, site looks a bit dated' and Lazarus has some outdated defaults. (No not related to docking)

My experience being that when given feedback or criticism to FOSS, that when they say "ok patch it" or "no we'll keep it this way gtfo" tends to be the style of communique. Greybeard running a regexp or a CTRL+F on inline variables and sidestepping this completely turning the conversation into something else is what I _somewhat_ expected but now it's definitely clear to me why the motivation gets for new contributors nil'd. It took Bart to actually understand and ask but as said, still using FPC but not (directly) advertising it as Free Pascal might be the better approach. Improving Castle Engine tooling/docs will be time better spent. It'll just bitrot away on here and much more appreciated over there

I do think if you want to make very Castle Engine specific modifications as changing the dialect default, a fork is the way to go yes. If it is such a big deal for you, it might even be worth it.

I think it's better to work around it or improve it downstream than fork a compiler, that never ends well or becomes obsolete within a year anyway. FPC itself isnt broken by design, it's the general culture of writing {$Objdelfreepascal}.

As I said in my previous message "my way or the highway" is not a constructive attitude for  a new contributor. A bit more flexible thinking about ways to reach goals might be in order. Stay away from contented subjects like language dialect.

So avoid staring down core members that have to weigh various uses of the project and try to force them to make some landslide decision.

My way or the highway is not something I said. The way I was interpreted sent this off course, despite me pretty clear about what I think drives contributors away. It didn't take long before that exact thing happened. Perhaps assuming everyone who makes observations or posits solutions is not demanding _you_ to do something but _cares_ about the project and therefore could simply be asked to fix it is a possibility; but any discussion about it went out the window real quick. I understand that's not git{hub,lab} culture where it's demand, demands and more demands but alas.

I am not sure if I can make something in Scratch for you that's useful, never used it.

Thaddy is also not core, so does not speak to the project. 

I myself, though a developer, also don't speak for the project in an absolute, definitive way. You can always ask a different developer for a 2nd opinion.

_BUT_ I only try to avoid raising false expectations, and I don't like it when threads about change are left hanging  without any developer answer, met by universal silence. Yes, I do realise that being the messenger of bad news doesn't always make me popular, but at least give me some credit for it.

Doesn't matter if it's core dev or not if a core dev later comes in with the same line of thinking. Seems like he represents core enough at that point.

Also I take objection to phrases like:

Plus in the time it took you to reply you could also have made a change

The changes you propose (without even giving a hint on how to achieve this) are not something you can accomplish in say 30 minutes.
This is just insulting the team.

You should take objection with more than just me in this thread. I suggest you re-read what was cherrypicked from what I wrote and what the response is. I'll admit to calling marcov out from the beginning was not the most diplomatic move though would it have changed the discourse? I don't think so, keep in mind that my post follows Simone's, read his too. Perhaps you're right about the if hungry, dont post part.

No clue why marcov declares me to be a blackmailer or an anti, editing that in seems emotion driven after the fact. Overall I get the sceptiscism, as said before, maintainers get countless of suggestions and fatigue does set in when dealing with that. I don't think we can sail over land together *shrug*

[kupferstecher]

Feature request: FINALLY section in Procedures and Functions:

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

1. Procedure Foo;
2. var sl: TStringList;
3. begin
4.   sl:= TStringList.Create;
5.   //Do sth.
6.   if xy then EXIT;
7.  
8. finally
9.   sl.Free;
10. end;

Yes, the same can be done with try..finally, but doing it with try..finally feels a bit like an "abuse" of exception-functionality and the additionally needed TRY and END makes the function look more messy. I think an explicit Finally section for functions would be used by many freepascalers.

[cdbc]

Hi
@kupferstecher:

Feature request: FINALLY section in Procedures and Functions:

Use interfaces or managed records.
There's a nifty tool "TAuto" in this thread: https://forum.lazarus.freepascal.org/index.php/topic,66523.0.html
Regards Benny

[Ryan J]

Feature request: FINALLY section in Procedures and Functions:

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

1. Procedure Foo;
2. var sl: TStringList;
3. begin
4.   sl:= TStringList.Create;
5.   //Do sth.
6.   if xy then EXIT;
7.  
8. finally
9.   sl.Free;
10. end;

Yes, the same can be done with try..finally, but doing it with try..finally feels a bit like an "abuse" of exception-functionality and the additionally needed TRY and END makes the function look more messy. I think an explicit Finally section for functions would be used by many freepascalers.

100% agree. We've been using goto blocks for this like savages. All functions have a finalization section so this should be exposed to the programmer.

[440bx]

No need for goto(s) or finally(s) to implement that.   Do it like this:

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

1. Procedure Foo;
2. var sl: TStringList = nil; { first: initialize variables }
3.  
4. begin
5.   repeat { just a scope, not a loop }
6.     sl := TStringList.Create;
7.  
8.     //Do sth.
9.  
10.     if xy then break;  { don't exit, premature exits should be avoided }
11.    until TRUE; { won't execute again }
12.  
13.   if Assigned(sl) then sl.Free;  { get in the habit of setting pointers to nil when they are freed }
14.  
15.   { and free/release/close whatever else was acquired in the code, e.g:  }
16.  
17.   if Filehandle <> INVALID_HANDLE_VALUE then
18.   begin
19.     { presuming there is a handle that should be closed  }
20.  
21.     CloseHandle(FileHandle);
22.     Filehandle := INVALID_HANDLE_VALUE; { back to its initial value! }
23.   end;
24. end;

[Ryan J]

No need for goto(s) or finally(s) to implement that.   Do it like this:

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

1. Procedure Foo;
2. var sl: TStringList = nil; { first: initialize variables }
3.  
4. begin
5.   repeat { just a scope, not a loop }
6.     sl := TStringList.Create;
7.  
8.     //Do sth.
9.  
10.     if xy then break;  { don't exit, premature exits should be avoided }
11.    until TRUE; { won't execute again }
12.  
13.   if Assigned(sl) then sl.Free;  { get in the habit of setting pointers to nil when they are freed }
14.  
15.   { and free/release/close whatever else was acquired in the code, e.g:  }
16.  
17.   if Filehandle <> INVALID_HANDLE_VALUE then
18.   begin
19.     { presuming there is a handle that should be closed  }
20.  
21.     CloseHandle(FileHandle);
22.     Filehandle := INVALID_HANDLE_VALUE; { back to its initial value! }
23.   end;
24. end;

I like early return. Makes sense when reading the code that the function only needs to go that far. When you start doing this deferred release in code you're adding more steps to understand.

Languages like Zig and Swift adding a defer statement do the same thing and is another nice idea. We all do this pattern so the compiler should help us out more.

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

1. Procedure Foo;
2. var sl: TStringList;
3. begin
4.   sl:= TStringList.Create;
5.   defer sl.Free;
6.   //Do sth.
7.   if xy then EXIT;
8. end;