> 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 - email@example.com https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel