<div dir="ltr">Hi Sven,<div><br></div><div>I saw the new commits related to Management Operators (I mean new flags riifNonTrivialChild and riifParentHasNonTrivialChild) and I wonder what next.</div><div><br></div><div>When I was developing management operators (and FastRTTI related to speed up things) I had in mind extensive expansion for management types in many directions (nullable types, smart pointers and so one, FastRTTI is also related to all managed types not only to management operators) and optimizations to speed up things (in the final, generated code can be faster even few times than current code, here I mean code with standard managed types without any management operators).</div><div><br></div><div>The FastRTTI covers the needs of the optimization for constructors but also moves things much forward (it depends on use case: from my tests is never slower but always faster, for some cases even few times). </div><div><br></div><div>For example the new flags (riifNonTrivialChild and riifParentHasNonTrivialChild) works good only when none of record with "Initialize operator" is used as field, also worth to note that new solution will be much slower <span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">in the future<span> </span></span>than FastRTTI when users will decide to use more types backed by management operators (and the topic will back again...). </div><div><br></div><div>Current flags are temporary solution or final thing? I have few things to say</div><div><br></div><div>A. we have ready to use better/faster solution than riifNonTrivialChild riifParentHasNonTrivialChild<br></div><div>B. current solution probably means also waste of memory for 

<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">TRecordInfoInitFlags </span>when in the future someone decide to introduce other optimizations related to RTTI and managed types (similar to FastRTTI)</div><div>C. also is possible to use less invasive version of FastRTTI (for example can be used part related to Initialize operator only (this part is already exposed outside FastRTTI structures and is generated always even when fast RTTI is off) and the way for full FastRTTI will be opened without wast of space for new flags...</div><div>D. Do we really want to use temporary solution? I think no - 
<span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">we should looks forward.</span></div><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">E. FastRTTI is just beginning and can be expanded to more optimizations</span></div><div>F. if for some reasons you want to keep current solution (anyway IMO very unwelcome for future things) may be worth to rename TRecordInfoInitFlags because can be also used for other purposes not related to initialization only. For example all flags defined for FastRTTI can be moved into this flag... Anyway TRecordInfoInitFlags will be still less efficient than FastRTTI for 8 and 16 bit platforms...<br></div><div><br></div><div>-- <br><div class="gmail_signature"><div dir="ltr"><div>Best regards,<br>Maciej Izak</div></div></div>
</div></div>