Specifing Pointer/Reference memory management strategy with class declaration.

[EdSaleh]

Hello,

I think it would be a great addition if we can specify class pointer and reference memory management strategy with the class declaration itself.

Example:

unique class A {}

Or

auto class A {}

this will enable all this 'A' instances to be of type unique or auto pointer, and as a result reference counted.

var a = new A(); (*A).value;

Also,

unique class *B {}

This will allow all instances to be derefed automatically when a variable is assigned to the instance. so you will be able to use value without accessing the pointer.

var b = new B(); b.value;

Thank you,

[geoffromer]

I think it would be a great addition if we can specify class pointer and reference memory management strategy with the class declaration itself.

Example:

unique class A {}

Or

auto class A {}

this will enable all this 'A' instances to be of type unique or auto pointer, and as a result reference counted.

var a = new A(); (*A).value;

Rather than have A's author pick one memory management strategy that all clients are forced to use, it seems like it would better to make it convenient and straightforward for clients to make this choice for themselves.

Also,

unique class *B {}

This will allow all instances to be derefed automatically when a variable is assigned to the instance. so you will be able to use value without accessing the pointer.

var b = new B(); b.value;

One of the most common reasons for allocating an object on the heap is because you want that object to outlive the scope where it's created, but this approach doesn't seem to give us a way to do that. There's no way to refer to the underlying unique pointer, so there's no way to move it.

[zygoloid]

My initial reaction is that we're unlikely to want to move forward with this approach. I think there are other ways to get the same kind of behavior, such as designing a type so that the only available factory functions all return heap-allocated instances that are owned by whatever kind of smart pointer is appropriate.

If you want to continue to explore this idea, I would like to understand more about the motivation and the intended use cases for this functionality. I agree with @geoffromer that allowing the clients of a class to select the memory management strategy seems like the right default, but people do ask how in C++ to require that a type's instances only live on the heap or only live on the stack sometimes. I'd also like some consideration of alternative ways to satisfy those use cases.

The auto-dereferencing pointer idea might create some confusion as to whether a particular value is a pointer or is the pointee. Beyond that, it would also be in conflict with our desire to make the performance cost of operations reasonably clear from the source syntax, by not differentiating between direct and indirect access. But I think that portion of this idea is separable from the rest.

I think this idea would need more exploration and elaboration before it could be fully considered, and isn't ready for a leads decision in its current form. A longer write-up in the form of a proposal might help, but it would need significant motivation to explain why this problem should be addressed with a language feature rather than via library design, or why addressing it any other way wouldn't be possible / practical / ergonomic. It would likely be a better use of time to discuss this in our discord to clarify the ideas and see what resonates with people.

[github-actions[bot]]

We triage inactive PRs and issues in order to make it easier to find active work. If this issue should remain active or becomes active again, please comment or remove the inactive label. The long term label can also be added for issues which are expected to take time. This issue is labeled inactive because the last activity was over 90 days ago.