12.5.4 Formal Access Types
1/2
{
AI95-00442-01}
[The
category class
determined for a formal access type is the
category class
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
Legality Rules
3
For a formal access-to-object type, the designated
subtypes of the formal and actual types shall statically match.
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/3
{
AI05-0239-1}
For a formal access-to-subprogram subtype, the designated profiles of
the formal and the actual shall be
mode conformant mode-conformant,
and the calling convention of the actual shall be
protected if
and only if that of the formal is
protected.
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
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
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).
Ada 2005 and 2012 Editions sponsored in part by Ada-Europe
