Contents Index Previous Next
3.2.2 Subtype Declarations
1
A subtype_declaration
declares a subtype of some previously declared type, as defined by a
subtype_indication.
Syntax
2
subtype_declaration
::=
subtype defining_identifier is subtype_indication;
3
subtype_indication
::= subtype_mark [
constraint]
4
subtype_mark
::= subtype_name
4.a
Ramification: Note that
name includes attribute_reference;
thus, S'Base can be used as a subtype_mark.
4.b
Reason: We considered changing
subtype_mark to subtype_name.
However, existing users are used to the word "mark," so we're
keeping it.
5
constraint
::= scalar_constraint |
composite_constraint
6
scalar_constraint
::=
range_constraint |
digits_constraint |
delta_constraint
7
composite_constraint
::=
index_constraint |
discriminant_constraint
Name Resolution Rules
8
A
subtype_mark
shall resolve to denote a subtype.
The type
determined
by a
subtype_mark is the type
of the subtype denoted by the
subtype_mark.
8.a
Ramification: Types are
never directly named; all subtype_marks
denote subtypes -- possibly an unconstrained (base) subtype, but never
the type. When we use the term anonymous type we really mean a
type with no namable subtypes.
Dynamic Semantics
9
The
elaboration of a
subtype_declaration
consists of the elaboration of the
subtype_indication.
The elaboration of a
subtype_indication
creates a new subtype. If the
subtype_indication
does not include a
constraint, the
new subtype has the same (possibly null) constraint as that denoted by
the
subtype_mark. The elaboration
of a
subtype_indication that includes
a
constraint proceeds as follows:
10
- The constraint is
first elaborated.
11
- A check is then
made that the constraint is compatible
with the subtype denoted by the subtype_mark.
11.a
Ramification: The checks
associated with constraint compatibility are all Range_Checks. Discriminant_Checks
and Index_Checks are associated only with checks that a value satisfies
a constraint.
12
The condition imposed by a
constraint
is the condition obtained after elaboration of the
constraint.
The rules defining compatibility are given for each
form of
constraint in the appropriate
subclause. These rules are such that if a
constraint
is
compatible with a subtype, then the condition imposed by the
constraint cannot contradict any
condition already imposed by the subtype on its values.
The
exception Constraint_Error is raised if any check of compatibility fails.
12.a
To be honest: The condition
imposed by a constraint is named
after it -- a range_constraint imposes
a range constraint, etc.
12.b
Ramification: A range_constraint
causes freezing of its type. Other constraints
do not.
13
4 A scalar_constraint
may be applied to a subtype of an appropriate scalar type (see 3.5,
3.5.9, and J.3),
even if the subtype is already constrained. On the other hand, a composite_constraint
may be applied to a composite subtype (or an access-to-composite subtype)
only if the composite subtype is unconstrained (see 3.6.1
and 3.7.1).
Examples
14
Examples of
subtype declarations:
15
subtype Rainbow is Color range Red .. Blue; -- see 3.2.1
subtype Red_Blue is Rainbow;
subtype Int is Integer;
subtype Small_Int is Integer range -10 .. 10;
subtype Up_To_K is Column range 1 .. K; -- see 3.2.1
subtype Square is Matrix(1 .. 10, 1 .. 10); -- see 3.6
subtype Male is Person(Sex => M); -- see 3.10.1
Incompatibilities With Ada 83
15.a
In Ada 95,
all range_constraints cause freezing
of their type. Hence, a type-related representation item for a scalar
type has to precede any range_constraints
whose type is the scalar type.
Wording Changes from Ada 83
15.b
Subtype_marks
allow only subtype names now, since types are never directly named. There
is no need for RM83-3.3.2(3), which says a subtype_mark
can denote both the type and the subtype; in Ada 95, you denote an unconstrained
(base) subtype if you want, but never the type.
15.c
The syntactic category type_mark
is now called subtype_mark, since
it always denotes a subtype.
Contents Index Previous Next Legal