> On May 6, 2021, at 11:40 PM, Sven Barth <pascaldra...@googlemail.com> wrote:
>
> In my opinion the better solution is to continue the road that Maciej started
> and to implement that "default field" concept together with operator
> hoistening so that records with management operators can be used as
> containers. This is essentially the way it's done in C++ as well (e.g. we use
> that extensively at work), but it needs some questions solved for the default
> field functionality. This way the functionality is definitely optional and
> can be controlled per-instance instead of per-type. What it wouldn't solve
> however would be the assignment problems ("wrapped" to non-"wrapped"
> instance) though that could be probably be more or less solved by only
> allowing an explicit conversion to the non-"wrapped" instance.
If you remember I already started this but it got WAY out of hand and I had to
basically abandon all my work on it because it was such a mess. The problem was
we opened the possibility of default properties being used on any type (could
be used for nullable types even) and this was in my opinion a mistake (at least
for now).
I'm not 100% behind the default implements property Sven proposed for traits
but it shares most of the functionality with the default property so maybe we
should figure out how to constrain the default property and work on that angle.
If I do continue on to the traits this code will be shared anyways.
What I learned is that hoisting the following members is very easy to implement:
- Methods
- Fields
- Properties
and these are much more complicated and had a massive code footprint on the
compiler:
- Operators
- Assignments
- Array indexing
- Implicit conversions (like if, while statements etc... these where needed for
nullable types but not for ARC)
From my experience I would say we ONLY allow Methods/Properties and MAYBE
fields and then ignore all the other stuff. Default properties can ONLY be a
class type now. There is already an := operator the record can implement and it
works with management operators already. This covers 90% of the use cases for
memory management and doesn't introduce all sorts of unpredictable stuff.
What about that?
Regards,
Ryan Joseph
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
