Eigenstate: myrddin-dev mailing list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Exploring Types and Memory Management


Implicitly inserting destructors based on a trait may not be the best way
in my opinion. It would make it hard to see what code is actually being
run. I think it kind of hurts readability in the same way that operator
overloading can obscure control flow and make things harder to debug. Also
I think it is less flexible, and more annoying to use. Consider std.htab
using a hashable trait instead of functions and how annoying to use it will
be.

I would prefer if owned destruction were explicit, but statically checked.
Forgetting to 'destroy' or move an object would be a compile error, but the
programmer would still insert the lifetime ending marker and the code to
destroy the given object. This would be more like C, but much harder
to shoot yourself in the foot, while being more flexible as it does not
require boilerplate types for every different way of freeing an object.

With regard to GC, it would be interesting to combine an ownership system
for non memory objects, but keep memory garbage collected. I think the work
involved in adding a GC is beyond our current development capabilities in a
reasonable time frame.


Regions also seem interesting and I will need to read more about them.

Regards,

Andrew Chambers

References:
Exploring Types and Memory ManagementOri Bernstein <ori@xxxxxxxxxxxxxx>