VSoft Technologies Blogs

rss

VSoft Technologies Blogs - posts about our products and software development.

Delphi 10.3 Rio - Language Changes

Back in December 2016, I posted some ideas for some Delphi language enhancements. That post turned out to be somewhat controversial, I received some rather hostile emails about how I was trying to turn Delphi into C#. That certainly wasn't my intent, but rather to modernize Delphi, in a way that helps me write less, but more maintainable code. Nearly 2 years later, Delphi 10.3 Rio actually implements some of those features.

I'm not going to claim credit for the new language features, and the syntax suggestions I made were pretty obvious ones, but I like to think I perhaps spurred them on a bit ;) My blog post had over 12K views, so there was certainly plenty of interest in new language features, and from what I have seen out there on the interwebs they have for the most part been well received.

So lets take a look at which suggestions made the cut for 10.3 - referencing my original post.

Feature Implemented Comments
Local Variable Initialisation No  
Type Inference Yes! For inline variables only, Confuses code insight!
Inline variable declaration, with type inference and block scope Yes, Yes and Yes! Confuses code insight!
Loop variable inline declaration Yes! Confuses code insight!
Shortcut property declaration No  
Interface Helpers No  
Strings (and other non ordinals) in Case Statements No  
Ternary Operator No  
Try/Except/Finally No  
Named Arguments No   
Variable method arguments No  
Lambdas No  
Linq No Depends on lambdas and interface helpers.
Async/Await No  
Non reference counted interfaces No  
Attribute Constraints No  
Operator overloading on classes. No  
Improve Generic Constraint No  
Fix IEnumerable No  
Yield return - Iterator blocks No  
Partial classes No  
Allow Multiple Uses clauses No  
Allow non parameterized interfaces to have parameterized methods No  

 

So, 3 out of 23. To be honest, I was pleasantly surprised when I found out about them, given the pace of language change in the past. I'm hopeful this is just the start of things to come and we get to see Delphi evolve and catch up with other modern programming languages. I have a bunch of other language features I'd like to see, and received lots of suggestions from other users. 

We're still using Delphi XE7 for FinalBuilder 8, and I rarely change compiler versions during the life of a major product version. So I'll only get to use the new language features when I get fully stuck into FinalBuilder 9 & Automise 6. I'm in the process of getting Delphi 10.3 compatible versions of all the third party libraries (commercial and open source) - as and long time delphi user will know, that's always more difficult than it should be!  

Related Posts


  • Delphi Language Enhancements

    The Delphi/Object Pascal language really hasn't changed all that much in the last 20 years. This post describes some ideas to bring it into the current century.

  • Delphi Code Coverage with Continua CI

    Generate code coverage reports for your Delphi projects using Continua CI.

  • Building Delphi projects with Continua CI

    This post shows how to configure Continua CI to build Embarcadero Delphi projects

  • Advice for Delphi library authors

    We use many third-party Delphi libraries to build FinalBuilder and Automise, and that brings plenty of issues when upgrading compiler versions. I've been using Delphi since 1995, both as a user and as a component vendor, I have learned a thing or two about creating libraries that I would like to share.

  • Managing Delphi Version Info with FinalBuilder

    In this post, we'll take a look at the various options for managing and updating Version Info in Delphi projects using FinalBuilder.

  • Introducing DPM - a Package Manager for Delphi

    Back in Feb 2019, I blogged about the need for a Package Manager for Delphi. The blog post garnered lots of useful feedback and encouragement, but until recently I could never find a solid block of time to work on it. Over the last few weeks I've been working hard to get it to an mvp stage.
Delphi
Showing 5 Comments
Avatar
Marco van de Voort 6 years ago

IMHO if you fundamentally revise the typesystem, you should start a new language/project. The Delphi typesystem is quite complex, specially the string related conversions.

Doing some windowdressing like Embarcadero did is just about getting bulletpoints for marketing, it serves no real purposes, solves no real problems.

The people that don't want to go that way hate it, and it doesn't go deep enough for the people that really want to go that way. What you get is a compromise that nobody wants, just to justify the subscription tax another year.

Avatar
Joseph 6 years ago

So you're seeing about the same rate of progress I did... back in 2012 I created a list that had about 40 items on it to improve the language, library and IDE. Eventually about 1-2 items started showing up per new version, although none lately. Now I can cross "type inference" off at least. I'm not as hopeful that we're about to see the floodgates open to massive modernization and improvement of the language as you are though. Still, I was beginning to think type inference would never materialize. A free version and type inference now though... if they'd just give us a modern IDE now too, we might have the bare essentials in place to start attracting new users.

Avatar
Delphi Developer 6 years ago

Thank you so much for such a wonderful software developer tool as Final Builder! Its software release build and deployment automation capabilities makes life for software build shops so much more easy! Thanks from Moscow, Russia.

Avatar
Rudy Velthuis 6 years ago

Actually, non-refcounted interfaces do exist. Just declare them [unsafe]

Avatar
Arioch 6 years ago

Type inference is very required.
The lack of it made compatibility backdoor hack - record helpers - promoted into libraries core feature, starting with RTL.
And when i was porting VurtualTreeViee back to XE2 replacing hacked simole types with advanced records and implicits - Delphi prooved inadequate for source code compatibility. Even simple operator x in <…> could not work.
Just crazy.

Ternary operator is possible but is not required.
It is perfectly substituted with generic and inlined IfThen<T> function...
....if Delphi had normal type inference and lazy parameters - so again, type inference.

Crazy concept of "assignment compatibility" - an ugly hack-around patch-worked hybrid type system - could be obsoleted too.



Comments are closed.