Delphi Rio “new overall direction of removing ARC”
Posted by jpluimers on 2018/10/23
Finally: “new overall direction of removing ARC” for Delphi 10.3 Rio and later.
Via [WayBack] Delphi Rio – New IDE Configuration with Search Box – New compiler dialog – Improve code completion – Inline variables – Rafael Dipold – Google+
Hopefully zero-based strings are the next to go…
Related: [WayBack] Directions for ARC Memory Management in Delphi
–jeroen
PS: my comment below on block-local variables (or inline vars), since searching inside posts for me is easier than in comments:
I have ambivalent feelings about languages that have supported them for a long time.
On the one hand, I like the proximity principle a lot.
On the other hand, sometimes it indeed gets confusing, especially in code that repeats the same variable name in different scopes, which gets worse with short undescriptive variable names.For Delphi code it will likely be a long time before I start using them. Apart from the upcoming version to have update 1 or update 2 to flesh out the first round of big bugs, most of my code is library code used across various older, but their issues much better known, Delphi versions.
Another thing is that usually when I have the feeling “hey, a block local variable could come in useful here”, it is a sure sign to refactor out that block in a separate method anyway.
A final thing: tooling will take quite a while to get adjusted to inline var support. The built-in code formatter already fails to support many existing language features (or quirks depending on perspective), and the others ([WayBack] Code Formatter Expert – twm’s blog, the [WayBack] pld JEDI Code Format with a revival at [WayBack] GitHub – git-bee/jcf-cli: Jedi Code Formatter CLI; are there any others?) are even further behind in language features.
Given the lack of resources at Embarcadero, they likely have not put in the effort to create an exhaustive set of test cases for this new compiler feature. Though far less invasive as the generics and anonymous methods support, I expect this to take more than just some .x updates to become rock solid.
For my future self: [WayBack] PASCAL CODE BEAUTIFIER.
The Wiert Corner - irregular stream of stuff 
Alexandre Machado said
That’s a good move. Better to correct course now than keep going in the wrong direction. Most “mistakes” were introduced by previous management. Seems to me that current management at least understand that Delphi is not C#.
KMorwath said
Other many years wasted in another dead-end. Despite the many warnings and worries. While continuous U-turns never help a product – it shows lack of proper vision and management. Let’s see if they abandon fashion-driven development now, or will look for new ways to shoot in their foot. Inline vars don’t worry me too much, it’s mostly syntactic sugar since their allocation and deallocation I guess will still only happen at a function entry/exit, scope will be a compiler feature only. As type inference.
Zero based strings were a worse change because it could lead to subtle bugs and out-of-bound reads, or worse.
Just curious what the ARC groupies will tell now…
rvelthuis said
AFAIK, you can and always could make strings 1-based, i.e. turn off zero based strings without any disadvantages. So I don’t quite understand the resentment.
jpluimers said
The major problem is that for any of your code that needs to be cross platform, you have to add the permutations (in all test code too!) so it works in both 1-based and 0-based environments.
You have to, because your co-worker, but more likely you, will use that code without applying the intended define to go the other way around, or worse, turn it the other way around in a unit you depend on.
Eric said
This was the best news on Delphi in a long time for me… can’t wait until they remove it on Mobile… and please, no more 0-based strings!!
thaddy said
So in a few weeks time we hopefully have the “moving in the general direction of removing inline vars”?
rvelthuis said
Why? They sound like a very useful feature to me. And unlike ARC, it looks as if you don’t have to use them. So if you don’t like them, don’t use them.
thaddy said
Dentists – however capable at programming – have the time to debug such code because it is a hobby…. Professionals don’t have that time. One of the key features of the Pascal language is separating Declaration from Implementation.
Even in C family code – where this is allowed – we remove on the fly declarations because it is hard for team members to deduct where the hell var X is declared.
It is an utterly despicable “feature” and your team will hate it. Note you will hardly see this used in e.g. large scale FOSS C/C++ code too for that reason and for that reason only.
There is a big difference between a programmer and a product owner. The product owner says: don’t use that!
thaddy said
Note that the Delphi IDE code completion/refactoring already has a feature safe enough to handle that (with appropriate declaration) that allows it without breaking code since D2006: it will fill in the var section for you.
So I don’t see the point.
jpluimers said
Though this refactoring hardly makes the IDE unstable, it fails to work for me in the majority of cases. Luckily Model Maker Code Explorer has the same refactoring and almost always succeeds.
jpluimers said
I have ambivalent feelings about languages that have supported them for a long time.
On the one hand, I like the proximity principle a lot.
On the other hand, sometimes it indeed gets confusing, especially in code that repeats the same variable name in different scopes, which gets worse with short undescriptive variable names.
For Delphi code it will likely be a long time before I start using them. Apart from the upcoming version to have update 1 or update 2 to flesh out the first round of big bugs, most of my code is library code used across various older, but their issues much better known, Delphi versions.
Another thing is that usually when I have the feeling “hey, a block local variable could come in useful here”, it is a sure sign to refactor out that block in a separate method anyway.
A final thing: tooling will take quite a while to get adjusted to inline var support. The built-in code formatter already fails to support many existing language features (or quirks depending on perspective), and the others (GExperts, Jedi Code Formatter; are there any others?) are even further behind in language features.
Given the lack of resources at Embarcadero, they likely have not put in the effort to create an exhaustive set of test cases for this new compiler feature. Though far less invasive as the generics and anonymous methods support, I expect this to take more than just some .x updates to become rock solid.