Annotated Ada Reference ManualLegal Information
Contents   Index   References   Search   Previous   Next 

12.5.4 Formal Access Types

1/2
{AI95-00442-01} [The category determined for a formal access type is the category of all access types.] 
1.a/2
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

2
formal_access_type_definition ::= access_type_definition

Legality Rules

3
For a formal access-to-object type, the designated subtypes of the formal and actual types shall statically match. {statically matching (required) [partial]}
4/2
{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. 
4.a
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. 
4.a.1/1
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.
4.b/2
{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. 
5
For a formal access-to-subprogram subtype, the designated profiles of the formal and the actual shall be mode-conformant, and the calling convention of the actual shall be protected if and only if that of the formal is protected. {mode conformance (required)}
5.a
Reason: We considered requiring subtype conformance here, but mode conformance is more flexible, given that there is no way in general to specify the convention of the formal. 

Examples

6
Example of formal access types: 
7
--  the formal types of the generic package 
8
generic
   type Node is private;
   type Link is access Node;
package P is
   ...
end P;
9
--  can be matched by the actual types 
10
type Car;
type Car_Name is access Car;
11
type Car is
   record
      Pred, Succ : Car_Name;
      Number     : License_Number;
      Owner      : Person;
   end record;
12
--  in the following generic instantiation 
13
package R is new P(Node => Car, Link => Car_Name);

Incompatibilities With Ada 83

13.a
{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

13.b
{extensions to Ada 83} Formal access-to-subprogram subtypes and formal general access types are new concepts. 

Wording Changes from Ada 95

13.c/2
{AI95-00231-01} Added a matching rule for subtypes that exclude null.
13.d/2
{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).

Contents   Index   References   Search   Previous   Next 
Ada-Europe Sponsored by Ada-Europe