>Well, it isn't a matter of "catching up" then since the developers have explicitly decided to not implement that feature in terms of language design grounds I

>Well, it isn't a matter of "catching up" then since the developers have explicitly decided to not implement that feature in terms of language design grounds I am very frustrated by their opinion And that is also for the uninitialized variables. With inline variable it would be much simpler to always initialize all variables. >I'm using FPC for almost two decades now and the only time i had FPC crash was when i fed it around 300MB of randomly generated code to see how it'd react - it was the 32bit binary too so that probably helped :-P. The more complex my project becomes, the more it crashes. When I made too many units, I got this https://bugs.freepascal.org/view.php?id=37478 https://bugs.freepascal.org/view.php?id=37478 and now it has been going on for years (with the related issue) And I use the trunk version (3.3.1). It is much less stable than the official releases. >Hm, perhaps though i've often done profiling in my apps and never noticed anything related to exceptions to enter the picture (i'm not using exceptions myself much though - especially not in any 'hot path'). The problem with longjmp exception handling is that it is slow, even if no exceptions are used Like this procedure abc; var s: String; begin s := '123'; end; becomes project1.lpr:15 begin 0000000000401240 55 push %rbp 0000000000401241 4889e5 mov %rsp,%rbp 0000000000401244 488d642490 lea -0x70(%rsp),%rsp 0000000000401249 48c745f800000000 movq $0x0,-0x8(%rbp) 0000000000401251 488d55e0 lea -0x20(%rbp),%rdx 0000000000401255 488d75a0 lea -0x60(%rbp),%rsi 0000000000401259 bf01000000 mov $0x1,%edi 000000000040125E e8dd340100 callq 0x414740 <fpc_pushexceptaddr> 0000000000401263 4889c7 mov %rax,%rdi 0000000000401266 e8b50b0000 callq 0x401e20 <fpc_setjmp> 000000000040126B 4863d0 movslq %eax,%rdx 000000000040126E 48895598 mov %rdx,-0x68(%rbp) 0000000000401272 85c0 test %eax,%eax 0000000000401274 7510 jne 0x401286 <ABC+70> project1.lpr:16 s := '123'; 0000000000401276 488d7df8 lea -0x8(%rbp),%rdi 000000000040127A 488d35971d0900 lea 0x91d97(%rip),%rsi # 0x493018 <.Ld1$strlab+24> 0000000000401281 e8fa9c0000 callq 0x40af80 <fpc_ansistr_assign> 0000000000401286 e825380100 callq 0x414ab0 <fpc_popaddrstack> project1.lpr:17 end; 000000000040128B 488d7df8 lea -0x8(%rbp),%rdi 000000000040128F e88c9c0000 callq 0x40af20 <fpc_ansistr_decr_ref> 0000000000401294 488b4598 mov -0x68(%rbp),%rax 0000000000401298 4885c0 test %rax,%rax 000000000040129B 740f je 0x4012ac <ABC+108> 000000000040129D e8be390100 callq 0x414c60 <fpc_reraise> 00000000004012A2 48c7459800000000 movq $0x0,-0x68(%rbp) 00000000004012AA ebda jmp 0x401286 <ABC+70> 00000000004012AC 4889ec mov %rbp,%rsp 00000000004012AF 5d pop %rbp 00000000004012B0 c3 retq That one, innocently looking function includes 4 different functions calls for exception handling, although there are zero exceptions involved. Any function that has automatic memory handling, has to do: Register itself for exception handling at the beginning; unregister itself at the end; catch any exception and then forward it to the next registered exception handler >There have been a bunch of changes very recently and in fact they introduced even more warnings :-P They are making it worse every year. >I usually just either initialize the variable to "default" Sometimes not even that works. Especially with nested functions accessing variables of the outer function. If I had a say, there would be inline variables with mandatory initialization. Any variable not initialized at its declaration, should be a compile time error. >Well, that isn't an issue with Lazarus either, though you should have told them that Lazarus does have a command-line project builder called lazbuild so it can also act as a building tool. They google Lazarus, see it says "IDE", and then there is no point in talking to them anymore >(e.g. personally i am not, i tend to stick with whatever comes with the language since external stuff may stop be developed - and Free Pascal and Lazarus come with a ton of packages out of the box anyway) Me, too. But that is really bad. The RTL is coupled with the compiler, so you cannot really update it without updating FPC. Like the JSON parser does not work properly. They fix it (or I did it), and with a package manager you could update it. Or with an external library you could update that. But with FPC, you need to update FPC. But you cannot, because there is no release, for years. So you need to update to trunk and compile FPC yourself. But then you get an unstable, untested version, which is going to break a lot of unrelated code. Today I actually looked at another JSON parser. It is probably better than FPC's, but I am not going to use it, because it is too much trouble to install it. I looked at its code, and one of the first classes they implement in the JSON parser unit is a string builder. In 2021, string builders really should have been a solved problem. Implementing string builders is a big waste of time. FPC has a builtin string builder, but it is too slow, it is basically unusable. I also wrote a string builder. It is around 40 times faster than FPC's. (I actually profiled it recently. Mine has about the same performance as the default Java one. I started using Pascal, because I thought a native language would be faster than a byte code language. But apparently not. Inlining the char append method is important. Without inlining, the Java version was twice as fast. On the other hand, I reimplemented append in amd64 assembly. It is 5% faster without inlining than the inlined version. Now with an active open-source community, we could write one assembly version for each platform. That would give maximal performance. But I do not want to maintain it. 5% speed is not worth the risk of having a bug on some platform. I do not have time to test x86 and arm versions. I need one version that works the same everywhere. So I removed my assembly version again ) They could have just used my string builder in the JSON parser instead developing a new one. But they probably do not know about it. And they will probably think it is too much trouble to install it. So people keep reimplementing the same things again and again, and the ecosystem does not get anywhere