3.10 Access Types

A
value of an access type (an access value) provides indirect access
to the object or subprogram it designates. Depending on its type,
an access value can designate either subprograms, objects created by
allocators (see 4.8), or more generally aliased
objects of an appropriate type.

Static Semantics

There
are two kinds of access types, access-to-object types, whose values
designate objects, and access-to-subprogram types, whose values
designate subprograms. Associated with an access-to-object
type is a storage pool; several access types may share the same
storage pool. All descendants of an access type share the same storage
pool. A storage pool is an area of storage used to
hold dynamically allocated objects (called pool elements) created
by allocators; storage pools are described further in 13.11,
“Storage Management”.

Access-to-object
types are further subdivided into pool-specific access types,
whose values can designate only the elements of their associated storage
pool, and general access types, whose values can designate the
elements of any storage pool, as well as aliased objects created by declarations
rather than allocators, and aliased subcomponents of other objects.

A view of an object is defined
to be aliased if it is defined by an object_declaration,
component_definition,
parameter_specification,
or extended_return_object_declaration
with the reserved word aliased, or by a renaming of an aliased
view. In addition, the dereference of an access-to-object value denotes
an aliased view, as does a view conversion (see 4.6)
of an aliased view. The current instance of an immutably limited type
(see 7.5) is defined to be aliased. Finally,
a formal parameter or generic formal object of a tagged type is defined
to be aliased. Aliased views are the ones that can be designated by an
access value.

An access_to_object_definition
defines an access-to-object type and its first subtype; the
subtype_indication
defines the designated subtype of the access type. If a general_access_modifier
appears, then the access type is a general access type. If
the modifier is the reserved word constant, then the type is an
access-to-constant type; a designated object cannot be updated
through a value of such a type. If the modifier is
the reserved word all, then the type is an access-to-variable
type; a designated object can be both read and updated through a
value of such a type. If no general_access_modifier
appears in the access_to_object_definition,
the access type is a pool-specific access-to-variable type.

An access_to_subprogram_definition
defines an access-to-subprogram type and its first subtype; the
parameter_profile
or parameter_and_result_profile
defines the designated profile of the access type. There
is a calling convention associated with the designated profile;
only subprograms with this calling convention can be designated by values
of the access type. By default, the calling convention is “protected”
if the reserved word protected appears, and “Ada”
otherwise. See Annex B for how to override this
default.

For each access type, there
is a null access value designating no entity at all, which can be obtained
by (implicitly) converting the literal null to the access type.
The null value of an access type is the default initial value of the
type. Nonnull values of an access-to-object type are obtained by evaluating
an allocator,
which returns an access value designating a newly created object (see
3.10.2), or in the case of a general access-to-object
type, evaluating an attribute_reference
for the Access or Unchecked_Access attribute of an aliased view of an
object. Nonnull values of an access-to-subprogram type are obtained by
evaluating an attribute_reference
for the Access attribute of a nonintrinsic subprogram.

All subtypes
of an access-to-subprogram type are constrained. The first subtype of
a type defined by an access_definition
or an access_to_object_definition
is unconstrained if the designated subtype is an unconstrained array
or discriminated subtype; otherwise, it is constrained.

Dynamic Semantics

A composite_constraint
is compatible with an unconstrained access subtype if it is compatible
with the designated subtype. A null_exclusion
is compatible with any access subtype that does not exclude null. An
access value satisfies a composite_constraint
of an access subtype if it equals the null value of its type or if it
designates an object whose value satisfies the constraint. An access
value satisfies an exclusion of the null value if it does not equal the
null value of its type.

The elaboration of an access_type_definition
creates the access type and its first subtype. For an access-to-object
type, this elaboration includes the elaboration of the subtype_indication,
which creates the designated subtype.

84 Each access-to-object type has an associated
storage pool; several access types can share the same pool. An object
can be created in the storage pool of an access type by an allocator
(see 4.8) for the access type. A storage pool
(roughly) corresponds to what some other languages call a “heap.”
See 13.11 for a discussion of pools.