Memory management

[OlaFosheimGrostad]

I haven't found anything specific on optimizations of memory management, but maybe I haven't looked in the right places? Where is Carbon heading when it comes to object destruction and avoiding unnecessary destruction cascades?

In particular, C++ destructors might be called even if the work the destructors perform is inconsequential when the whole use context is pulled down. E.g. think of a graph with a local allocator, arenas, execution contexts, graphics contexts or basically anything that contains many parts that trigger maintenance of some sort, related to and localized to the whole as the parts are being recycled.

The type system ought to help with separating concerns related to context-local destruction versus the release of external resources (relative to the context) in some way. For instance, a trivial example: if the program pulls down the entire graph, then it could bypass all graph-node destructors if they don't hold external resources and just release the node-allocation-pools.

Thoughts on how this can be done in a strongly typed manner?

[geoffromer]

I don't think we have a clear answer yet, but some of the ideas in p0257 may be relevant.

[vbregier]

If you want to separate your concerns in your example, split it into multiple classes, one for each concern. Each has its own destructor.

[OlaFosheimGrostad]

If you want to separate your concerns in your example, split it into multiple classes, one for each concern. Each has its own destructor.

I don't see how that could work. (The goal is to bypass destructors that do work that is superfluous because the context is no longer live.)