Interest in standard smart pointers for Ada 2020

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

I wonder if there would be interest in standardizing some usual smart 
pointers for the next revision. I will try to state the problems. I hope 
you'll point any misunderstandings on my part.

Ada has the particular limited and indefinite types, typically absent in 
other languages. However, their constraints often get in the way of 
comfort (all the cases I will list have workarounds, it's only tiresome 
and unnecessary noise):

* You cannot have indefinite record members, unless you make the record 
indefinite as well by providing a constraint. This basically moves the 
problem elsewhere (to the containing record, which may have no reason to 
be indefinite). Furthermore, some types do not have public constraints 
(e.g., to prevent declaration without initialization), so the previous 
solution wouldn't work. Also for class-wide members?

*** Ada.Containers.Indefinite_Holders is aimed at this use case, but it 
is only for by-value semantics, so if you don't want to pay that penalty 
for some reason (large types) you're out of luck.

* You cannot have a limited type (obviously) as a member of an unlimited 
type. You're then forced to resort to low-level accesses or custom 
wrappers to pass around those members.

* Delayed initialization of limited types, specially in combination with 
indefinite-ness will require some access type use.

* Delayed initialization of indefinite types, when you don't want to/can 
have a default discriminant (I remember a recent discussion about 
limited-size indefinites).

* Any other use cases I'm forgetting about right now?

Arguably (I'm unsure about this) in most cases problems could be avoided 
with careful design? I don't know, but I do know that there are smart 
pointer Ada libraries around, and I have rolled my own more often than 
not, and when I try to go the unconstrained way all around, sooner or 
later I have to backpedal.

If we look at the cousin C++, the standard pointers there are:

> unique_ptr [1]

> Allows exactly one owner of the underlying pointer. Use as the default choice for POCO unless you know for certain that you require a shared_ptr. Can be moved to a new owner, but not copied or shared.

> shared_ptr [2]

> Reference-counted smart pointer. Use when you want to assign one raw pointer to multiple owners, for example, when you return a copy of a pointer from a container but want to keep the original. The raw pointer is not deleted until all shared_ptr owners have gone out of scope or have otherwise given up ownership.

> weak_ptr [3]

> Special-case smart pointer for use in conjunction with shared_ptr. A weak_ptr provides access to an object that is owned by one or more shared_ptr instances, but does not participate in reference counting. Use when you want to observe an object, but do not require it to remain alive. Required in some cases to break circular references between shared_ptr instances.

I'd argue for having these, and also thread-safe implementations (that I 
guess would be heavier, requiring protected internals). I'd be willing 
to work on this too, if there is interest.

Alex.

[1] http://en.cppreference.com/w/cpp/memory/unique_ptr
[2] http://en.cppreference.com/w/cpp/memory/shared_ptr
[3] http://en.cppreference.com/w/cpp/memory/weak_ptr