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/2
{
AI95-00231-01}
subtype_indication ::= [null_exclusion] 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.
{determines (a type
by a subtype_mark)} 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
{elaboration
(subtype_declaration) [partial]} The elaboration
of a
subtype_declaration consists of the elaboration
of the
subtype_indication.
{elaboration
(subtype_indication) [partial]} 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
- {Range_Check
[partial]} {check,
language-defined (Range_Check)} 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.
{compatibility (constraint with a subtype)
[distributed]} 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.
{Constraint_Error
(raised by failure of run-time check)} 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/2
{
AI-00433-01}
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
subtype Binop_Ref is not null Binop_Ptr; -- see 3.10Incompatibilities With Ada 83
15.a
{
incompatibilities with Ada 83}
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.
Extensions to Ada 95
15.d/2
{
AI95-00231-01}
{extensions to Ada 95} An
optional null_exclusion can be used in a subtype_indication.
This is described in 3.10
Sponsored by Ada-Europe