Marco Tech Blog

November 21, 2018

Deferring Delphi Managed Records Support

Due to some standing issues, we decided to disable the managed records Delphi language feature in the coming 10.3 release and postpone it to 10.4

As you probably remember, I previously posted a 10.3 pre-release blog post on managed records in the Delphi language.

We had a great beta program for RAD Studio 10.3 and received a lot of very valuable feedback from partners and customers. Based on the feedback we received in the beta cycle, we decided to disable the managed records feature in the Delphi language for the 10.3 release. This was done to ensure we don't break existing customers’ code and third party vendors' code that make an advanced use of records.

Managed records have an effect on records parameters passing (to avoid additional useless copies of the data) and the ramifications of these changes risked affecting existing code. They also affect the use of RTTI for records. In light of compatibility with existing code and to further refine and improve the design of the feature, we felt it was better not to release it, and have more interactions with beta testers and partners with a longer development cycle.

Adding support for managed records will be on our roadmap for 10.4, along with additional language features already planned and under development.

Even without managed records, we have a number of great Delphi language enhancements in 10.3, including support for inline variable and constant declarations, variable block scope visibility and lifetime, variable type inference along with compiler quality work (also positively impacting Code Completion). We are sure you'll like what is coming in 10.3 for Delphi developers.

posted by marcocantu @ 11:00AM | 8 Comments [0 Pending]

8 Comments

Deferring Delphi Managed Records Support

 Given the choice, I'd much rather wait and have it
work properly out of the box in 10.4 than have it
released sooner but broken and have to wait for 10.4
for a fix. I think this applies to all features.

So if it's not ready, this is the smart move. Please
do this more.

Pre-announcing the feature might have been a little
premature, though.

Comment by Bruce McGee on November 21, 12:09

Deferring Delphi Managed Records Support

Good step! It was reasonable choice. 
We do not need mass ammount of new issues, Delphi
should slowly move forward with new features and focus
on fixing major issues.
Also don't forget about performance, processors are
not getting faster these days as previous, performance
optimization of RTL should be one of the priority.

Comment by Grizli on November 21, 14:50

Deferring Delphi Managed Records Support

To be honest - I never used these record features, always used objects.

But inline variable declaration was one of the things I defintly was 
craving for in Delphi while switching between Delphi, C# and Java in 
my daily work. 

I am really looking forward to 10.3 - hopefully it will be delivered in 
the next days?

Comment by Micha Schumann [http://itc-ms.de] on November 21, 16:34

Deferring Delphi Managed Records Support

Probably for the best.  It will give you a chance to revisit a few 
choices. 

Top of the list is the new "Assign" operator overload.  It is clunky 
and terribly specific.  It would be better if the implicit and explicit 
operator overloads just took the same type for both input and 
output instead.  Since this are already the implied assignment 
overloads, it would make more sense than creating a single 
special case for record assignment.

I am still interested in hearing how you would get around the 
smartpointer .value problem, because nothing in the beta really 
did that.

Someone suggested the "alias" syntax from other languages, but I 
suspect that the "default"  pattern already used for delphi 
properties might be the better way to go.

Such as 
TMyRecord=Record
  fValue : TStringList (* or some other type *);
  Property Value : TStringList Read fValue Default;

then any instance of TMyRecord could just accessed directly as 
fValue.

Marco, I would love to start a more direct discussion of why this 
is useful.  I mentioned before that I was looking at records smart 
pointers for something I am working on - basically done 
correctly, it allows us to bring operator overloading to the usage 
of interfaces.  And yes, I have code that would benefit from that.

Let me know if you want me to reach out directly to you about 
that.

Comment by Clinton Johnson on November 21, 22:19

Deferring Delphi Managed Records Support

 @Clinton Johnson

But... but...

Would you equally declare a class?

TMyRecord=Class
  fValue : TStringList (* or some other type *);
  Property Value : TStringList Read fValue Default;
end;

Probably now. You would care about visibility.
Then why you don't do the same for records?

TMyRecord=Record
STRICT PRIVATE
  fValue : TStringList (* or some other type *);
PUBLIC
  Property Value : TStringList Read fValue;
  class operator Implicit(const from: TMyRecord): TStrings; 
inline;
end;

class operator TMyRecord.Implicit(const from: TMyRecord): 
TStrings; 
begin Reuslt := Self.Value end;

Comment by Arioch on November 23, 16:34

Deferring Delphi Managed Records Support

 Very interesting feature. It is a pity that it was
withdrawn. She could in order to be at least on approval.

Comment by CandyMan on November 28, 23:00

Deferring Delphi Managed Records Support

 Assignment overloading of records was the only new feature that I 
was looking forward to.
And though I see what Clinton is saying, I still think that overloading 
the assignment operator as you intended is better due to versatility.
I would really like this to happen in a minor 10.3 release rather than 
wait another year, with the caveat that it's done properly.

Comment by Peter Thonell on December 9, 04:57

Deferring Delphi Managed Records Support

The feature is not disabled completley in Delphi 10.3.

I lost the last two days to search an error and to find 
a workaround after upgrading from Delphi 10.2.
See here: 
https://quality.embarcadero.com/browse/RSP-24207.

The error was caused by changes of the T*DynArray types
types in the RTL and Code which belongs to Managed
Managed Records.
The flawed code is surrounded with a Cond. Def
Def. "Managed_Code".
And the RTL changes are not documented in the Release Notes 
Release Notes of Delphi 10.3.
This Job was not well-done.

Comment by Thomas Grusche [http://blog.marcocantu.com/blog/2018-november-deferring-managed%20records.html] on April 9, 22:57

Post Your Comment

Click here for posting your feedback to this blog.

There are currently 0 pending (unapproved) messages.