12.5.4 Formal Access Types
{
AI95-00442-01}
[The category determined for a formal access type is the category of
all access types.]
Proof: {
AI95-00442-01}
This rule follows from the rule in
12.5 that
says that the category is determined by the one given in the name of
the syntax production. The effect of the rule is repeated here to give
a capsule summary of what this subclause is about.
Syntax
Legality Rules
For a formal access-to-object type, the designated
subtypes of the formal and actual types shall statically match.
{
AI95-00231-01}
If and only if the
general_access_modifier
constant applies to the formal, the actual shall be an access-to-constant
type. If the
general_access_modifier
all applies to the formal, then the actual shall be a general
access-to-variable type (see
3.10). If and
only if the formal subtype excludes null, the actual subtype shall exclude
null.
Ramification: If no _modifier
applies to the formal, then the actual type may be either a pool-specific
or a general access-to-variable type.
Reason: {
8652/0109}
{
AI95-00025-01}
Matching an access-to-variable to a formal access-to-constant type cannot
be allowed. If it were allowed, it would be possible to create an access-to-variable
value designating a constant.
{
AI95-00231-01}
We require that the “excludes null” property match, because
it would be difficult to write a correct generic for a formal access
type without knowing this property. Many typical algorithms and techniques
will not work for a subtype that excludes null (setting an unused component
to
null, default-initialized objects, and so on). Even Ada.Unchecked_Deallocation
would fail for a subtype that excludes null. Most generics would end
up with comments saying that they are not intended to work for subtypes
that exclude null. We would rather that this sort of requirement be reflected
in the contract of the generic.
{
AI05-0239-1}
{
AI05-0288-1}
For a formal access-to-subprogram subtype, the designated profiles of
the formal and the actual shall be subtype conformant.
Examples
Example of formal
access types:
-- the formal types of the generic package
generic
type Node is private;
type Link is access Node;
package P is
...
end P;
-- can be matched by the actual types
type Car;
type Car_Name is access Car;
type Car is
record
Pred, Succ : Car_Name;
Number : License_Number;
Owner : Person;
end record;
-- in the following generic instantiation
package R is new P(Node => Car, Link => Car_Name);
Incompatibilities With Ada 83
The check for matching of
designated subtypes is changed from a run-time check to a compile-time
check. The Ada 83 rule that “If the designated type is other than
a scalar type, then the designated subtypes shall be either both constrained
or both unconstrained” is removed, since it is subsumed by static
matching.
Extensions to Ada 83
Formal access-to-subprogram
subtypes and formal general access types are new concepts.
Wording Changes from Ada 95
{
AI95-00231-01}
Added a matching rule for subtypes that exclude null.
{
AI95-00442-01}
We change to “determines a category” as that is the new terminology
(it avoids confusion, since not all interesting properties form a class).
Incompatibilities With Ada 2005
{
AI05-0288-1}
Correction: Matching of formal access-to-subprogram
types now uses subtype conformance rather than mode conformance, which
is needed to plug a hole. This could cause some instantiations legal
in Ada 95 and Ada 2005 to be rejected in Ada 2012. We believe that formal
access-to-subprogram types occur rarely, and actuals that are not subtype
conformant are rarer still, so this should not happen often. (In addition,
one popular compiler has a bug that causes such instances to be rejected,
so no code compiled with that compiler could have an incompatibility.)
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
