[fpc-devel] Smart pointers/nullable types - compromise solution

Maciej Izak hnb.code at gmail.com
Thu Jun 21 09:44:57 CEST 2018


I think that the most acceptable solution for all in core team and for
advanced users (here I mean Stefan Glienke ;) ) for smart pointers and
nullable types is usage of default property without indexer.

For example :

  TFoo = record
    { ... }
    property Some: Integer read GetSome write SetSome; default;

this solution seems better compromise than default field (which I
personally prefer). This will allows new proper handling of exceptions for
nullable types, IIRC this was mentioned by Stefan Glienke as the
main disadvantage of default fields, also probably all Jonas Maebe doubts
are not actual with "default property without indexers" (for example "var"
parameter problem for overloaded procedures).

usage of smart pointers and nullable types will introduce more extensive
usage of managed types (finally every nullable type and smart pointer is in
managed types category because "default property without indexers" almost
always means usage of management operators) which may means really
slowdown, but this can be solved (generally already is solved in my
FastRTTI branch) - in this context is worth to look into my other topic :

"[fpc-devel] Attn Sven: New flags related to management operators" (
http://lists.freepascal.org/pipermail/fpc-devel/2018-June/039109.html )

also might be worth to introduce modeswitch to allows "default field" which
should be disabled by default for all modes. In practice default field is
also very usable in many scenarios, for example as replacement for type
helpers or as some kind of aspects and many more.

the main questions are :

* FastRTTI should be introduced into NewPascal only or should be refactored
and used also in FPC trunk?
* What with TRecordInfoInitFlags? (very important for above, with FastRTTI
TRecordInfoInitFlags has not much sense)
* What with smart pointers/nullable types/ARC objects further work? Here
the same question : NewPascal only or FPC trunk too?

Best regards,
Maciej Izak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-devel/attachments/20180621/0362efa5/attachment.html>

More information about the fpc-devel mailing list