Well, the roadmap lists "Language enhancements" as the first thing in the list for this upcoming release, but I've not seen anything specific. They often start discussing more details as the public beta gets rolling.
A lot of stuff they list has resulted in some discussions with details being released. The language enhancements are almost always a surprise. But for them to actually mention it suggests they've got something more significant planned.
<RANT>
Delphi seems so far behind the curve when it comes to newer language features found in most contemporary languages that it has become silly.
I'm tired of people who fancy themselves as highly muscular defending the lack of a jack for this type of car because it just wouldn't be the same if you didn't have to lift the car yourself to change a tire. Those "other cars" need a jack, but people who use "this car" ... BAH! We don't need no stink'n jacks! Just work out more and bulk-up those muscles!
Ya, ya, ya ... and people wonder why the use of THIS type of vehicle keeps going down year after year. The vendor should put an effing jack in the trunk and anybody who doesn't want to use it can just forget it exists.
Makes you wonder about all of the macho-men who objected to the use of replacing cranks on cars to get the motor running with electric starters. Delphi would be the last auto maker left without electric starters, because it would be seen as "too much like a Ford" or some other vehicle!
There are around a dozen things that are found in most contemporary languages today that are missing from Delphi, and the only justification I'm aware of is because a lot of Dephi people like to scream, "we don't need no stink'n xyz or it would be too much like some other language!" Well, ya know what? All of those OTHER languages have GROWING USER BASES! Delpih keeps shrinking. Maybe saving time by having common-sense syntactic stuff found in most languages today is more important than some people think. Programmers DO LIKE TIME-SAVING FEATURES, ya know?
For example, I tried using IfThen in a few places this past week and it got me into trouble ... when are we going to get a trinary operator to avoid having both options evaluated? If you think it's too much like something in some other language, just don't use it. You're free to use as many lines of code to replace a simple expression as you like. Nobody is gonna stop you! If that's not enough, switch to assembly language. (Remember, high-level languages evolved to SIMPLIFY programming vs. what assembler requires!)
You can short-circuit multiple expression evaluations using logical operators (AND, OR) but that doesn't work for unassigned objects and in method calls that have side-effects, among others.
Many OOP languages are now allowing a '?' to be put after assignment statements on references to objects that may be null to allow them to only work if the references are non-NULL.
These are very common use cases that have evolved simple syntactic solutions in other languages to avoid multiple lines of code to address them otherwise. They're only cryptic to read if you never write code that uses them. (I rarely use things from the heap that require the ^ operator, so that stuff looks cryptic to me. But I'd never advocate that it be removed from the language for that reason!)
I'm just hopeful we might be seeing some of this stuff finally showing up in Delphi (10-20 years later than other languages).
I was looking at some of the code I've written in the past few days, and a lot of it is so highly idiomatic in given contexts that you'd think there would be a way of condensing it into simpler expressions without having to resort to stuffing it into subroutines or adding it to helper classes. That would only hide it away rather than simplify how it's expressed anyway. I have a feeling I'll be long gone before programming languages begin to incorporate features that let you reduce common idiomatic expressions into new syntactic structures other than subroutines. (Generics barely scratch the surface, and have a ton of limitations.)
A lot of times we can't even use subroutines to simplify things in Delphi because you cannot use property names in var and out parameters on method calls, so you can't create a generic routine to pass back values to properties. You have to write a routine that's tightly-coupled to the class so it can set the properties internally, making what it's doing far more opaque than is needed. Or you just need a separate assignment statement explicitly setting property values one by one
I was looking at some C++ recently ... I don't recognize any of the crap that I guess is now needed to get it to do what you need. it looks nothing like it did 20 years ago. I guess they call that "progress".
</RANT>