How might ownership notions and/or new storage management approaches reduce the need for accessibility checking, while also simplifying alias analysis for parallel programming? There has been a fair amount of work on this, both in various AIs (AI12-0240-{1-6}, and in various other forums including: SPARK ownership model; bounded class-wide objects; ParaSail's ownership and region-based storage model – see Sections 3 and 5 of the ParaSail article, Guava version of Java – see notion of unshared "values"; Rust's ownership model, etc.
[Editor’s note: This is one of the “issues to revive from Ada 2022”, specifically from AI12-0240-5 (the last version worked on for Ada 2022).]
The notion of pointer or object "ownership" has a relatively long history (section 5 of the ParaSail article mentioned above includes a literature review), as a way to "tame" the complexities of aliasing inherent in the use of pointers. The Rust programming language has popularized the notion of a pointer "owning" the object it points at, with features that allow "borrowing" the ownership temporarily, often as part of parameter passing. SPARK has also adopted a pointer ownership model for the use of access types (in earlier SPARK versions access types were unsupported), similar to that of Rust and in part inspired by some of the work done on ParaSail.
The key property of ownership is that you know that a given pointer that gives update access to the object it points at, is the only reference to the object. On the other hand, having multiple references to an object that give read-only access is permitted, so long as there is no concurrently usable read-write reference.
The sequence of 2012 AIs numbered AI12-0240-1 .. AI12-0240-5 (which are all available via the link given above) propose various alternative ways to incorporate pointer ownership into Ada. The last of these, AI12-0240-5, is what the ARG voted to keep alive for further consideration after finalizing the Ada 2022 standard. This issue is the place to comment on that last AI, or on this topic in general.
Note that we included above a link to an "RFC" proposing a way to set an upper bound on the size of class-wide objects of a given type hierarchy, thereby allowing the programmer to treat class-wide objects as being of a "definite" subtype, so they can be (re)assigned to have different tags during their lifetime. This could be seen as a hint at a more general notion of allowing more general "mutable" objects, perhaps with an implicit level of indirection that is managed automatically, without any explicit pointers, allocators, deallocation, etc. This is the approach that ParaSail has taken, and it gives essentially all of the benefits of pointer ownership, while completely eliminating the explicit use of pointers. ParaSail introduces the notion of null values (as opposed to null pointers), to handle the case of default initializing a mutable structure like a tree or a class-wide object to an initially empty state, similar to a "holder" object. For efficient storage management, implicit local heaps are created so that exiting a scope can easily recover all the storage used for local mutable/growable objects. By specifying upper bounds on these implicit local heaps, the storage needed can be bounded, without having the programmer have to resort to separate bounds for each individual mutable type. In any case, these alternative approaches to storage management, with the attendant possibility of allowing direct use of unconstrained arrays and class-wide objects as mutable objects, is an alternative approach to ownership that should perhaps be considered.
How might ownership notions and/or new storage management approaches reduce the need for accessibility checking, while also simplifying alias analysis for parallel programming? There has been a fair amount of work on this, both in various AIs (AI12-0240-{1-6}, and in various other forums including: SPARK ownership model; bounded class-wide objects; ParaSail's ownership and region-based storage model – see Sections 3 and 5 of the ParaSail article, Guava version of Java – see notion of unshared "values"; Rust's ownership model, etc.
[Editor’s note: This is one of the “issues to revive from Ada 2022”, specifically from AI12-0240-5 (the last version worked on for Ada 2022).]
The notion of pointer or object "ownership" has a relatively long history (section 5 of the ParaSail article mentioned above includes a literature review), as a way to "tame" the complexities of aliasing inherent in the use of pointers. The Rust programming language has popularized the notion of a pointer "owning" the object it points at, with features that allow "borrowing" the ownership temporarily, often as part of parameter passing. SPARK has also adopted a pointer ownership model for the use of access types (in earlier SPARK versions access types were unsupported), similar to that of Rust and in part inspired by some of the work done on ParaSail.
The key property of ownership is that you know that a given pointer that gives update access to the object it points at, is the only reference to the object. On the other hand, having multiple references to an object that give read-only access is permitted, so long as there is no concurrently usable read-write reference.
The sequence of 2012 AIs numbered AI12-0240-1 .. AI12-0240-5 (which are all available via the link given above) propose various alternative ways to incorporate pointer ownership into Ada. The last of these, AI12-0240-5, is what the ARG voted to keep alive for further consideration after finalizing the Ada 2022 standard. This issue is the place to comment on that last AI, or on this topic in general.
Note that we included above a link to an "RFC" proposing a way to set an upper bound on the size of class-wide objects of a given type hierarchy, thereby allowing the programmer to treat class-wide objects as being of a "definite" subtype, so they can be (re)assigned to have different tags during their lifetime. This could be seen as a hint at a more general notion of allowing more general "mutable" objects, perhaps with an implicit level of indirection that is managed automatically, without any explicit pointers, allocators, deallocation, etc. This is the approach that ParaSail has taken, and it gives essentially all of the benefits of pointer ownership, while completely eliminating the explicit use of pointers. ParaSail introduces the notion of null values (as opposed to null pointers), to handle the case of default initializing a mutable structure like a tree or a class-wide object to an initially empty state, similar to a "holder" object. For efficient storage management, implicit local heaps are created so that exiting a scope can easily recover all the storage used for local mutable/growable objects. By specifying upper bounds on these implicit local heaps, the storage needed can be bounded, without having the programmer have to resort to separate bounds for each individual mutable type. In any case, these alternative approaches to storage management, with the attendant possibility of allowing direct use of unconstrained arrays and class-wide objects as mutable objects, is an alternative approach to ownership that should perhaps be considered.