> 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 

- 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?

        Ryan Joseph

fpc-devel maillist  -  fpc-devel@lists.freepascal.org

Reply via email to