Subtype Declarations

A subtype_declaration declares a subtype of some previously declared type, as defined by a subtype_indication.

Syntax

Ramification: Note that name includes attribute_reference; thus, S'Base can be used as a subtype_mark.

Reason: We considered changing subtype_mark to subtype_name. However, existing users are used to the word "mark," so we're keeping it.

Name Resolution Rules

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.

Ramification: {AI05-0005-1} 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 nameable subtypes.

Dynamic Semantics

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:

A check is then made that the constraint is compatible with the subtype denoted by the subtype_mark.

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.

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.

To be honest: The condition imposed by a constraint is named after it — a range_constraint imposes a range constraint, etc.

NOTE {AI12-0440-1} A scalar_constraint can 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 can 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

{AI95-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.10

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

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.

Extensions to Ada 95

{AI95-00231-01} An optional null_exclusion can be used in a subtype_indication. This is described in 3.10.

Extensions to Ada 2005

{AI05-0183-1} An optional aspect_specification can be used in a subtype_declaration. This is described in 13.1.1.

3.2.2 Subtype Declarations