Ada Conformity Assessment Authority |
Home |
Conformity Assessment | Test Suite |
ARG | Ada Standard |

A discriminant_constraint
specifies the values of the discriminants for a given discriminated type.

{*AI05-0299-1*}
The rules in this subclause are intentionally parallel to those given
in 4.3.1, “Record
Aggregates”.

{*AI12-0212-1*}
discriminant_association ::=

[*discriminant_*selector_name {'|' | *discriminant_*selector_name} =>] expression

[

A discriminant_association
is said to be *named* if it has one or more *discriminant_*selector_names;
it is otherwise said to be *positional*. In
a discriminant_constraint,
any positional associations shall precede any named associations.

Each selector_name
of a named discriminant_association
shall resolve to denote a discriminant of the subtype being constrained;
the discriminants so named are the *associated
discriminants* of the named association. For a
positional association, the *associated discriminant* is the one
whose discriminant_specification
occurred in the corresponding position in the known_discriminant_part
that defined the discriminants of the subtype being constrained.

The expected type for the expression
in a discriminant_association
is that of the associated discriminant(s).

{*8652/0008*}
{*AI95-00168-01*}
{*AI95-00363-01*}
{*AI05-0041-1*}
A discriminant_constraint
is only allowed in a subtype_indication
whose subtype_mark
denotes either an unconstrained discriminated subtype, or an unconstrained
access subtype whose designated subtype is an unconstrained discriminated
subtype. However, in the case of an access subtype, a discriminant_constraint
is legal only if any dereference of a value of the access type is known
to be constrained (see 3.3). In addition to
the places where Legality Rules normally apply (see 12.3),
these rules apply also in the private part of an instance of a generic
unit.

A named discriminant_association
with more than one selector_name
is allowed only if the named discriminants are all of the same type.
A discriminant_constraint
shall provide exactly one value for each discriminant of the subtype
being constrained.

A discriminant_constraint
is *compatible* with an unconstrained discriminated subtype if each
discriminant value belongs to the subtype of the corresponding discriminant.

A composite value *satisfies*
a discriminant constraint if and only if each discriminant of the composite
value has the value imposed by the discriminant constraint.

{*AI12-0439-1*}
For the elaboration of a discriminant_constraint,
the expressions
in the discriminant_associations
are evaluated in an arbitrary order and converted to the type of the
associated discriminant (which can might
raise Constraint_Error — see 4.6); the
expression
of a named association is evaluated (and converted) once for each associated
discriminant. The result of each evaluation and conversion
is the value imposed by the constraint for the associated discriminant.

NOTE The rules of the language ensure
that a discriminant of an object always has a value, either from explicit
or implicit initialization.

{*AI05-0299-1*}
*Examples (using types declared above in subclause 3.7):*

Large : Buffer(200); --* constrained, always 200 characters*

--* (explicit discriminant value)*

Message : Buffer; --* unconstrained, initially 100 characters*

--* (default discriminant value)*

Basis : Square(5); --* constrained, always 5 by 5*

Illegal : Square; --* illegal, a Square has to be constrained*

--

Message : Buffer; --

--

Basis : Square(5); --

Illegal : Square; --

Dependent compatibility
checks are no longer performed on subtype declaration. Instead they are
deferred until object creation (see 3.3.1).
This is upward compatible for a program that does not raise Constraint_Error.

Everything in RM83-3.7.2(7-12), which specifies
the initial values for discriminants, is now redundant with 3.3.1, 6.4.1,
8.5.1, and 12.4. Therefore, we don't repeat it here. Since the material
is largely intuitive, but nevertheless complicated to state formally,
it doesn't seem worth putting it in a "NOTE".

{*8652/0008*}
{*AI95-00168-01*}
{*AI95-00363-01*}
The Corrigendum added a restriction on discriminant_constraints
for general access subtypes. Such constraints are prohibited if the designated
type can be treated as constrained somewhere in the program. Ada 2005
goes further and prohibits such discriminant_constraints
if the designated type has (or might have, in the case of a formal type)
defaults for its discriminants. The use of general access subtypes is
rare, and this eliminates a boatload of problems that required many restrictions
on the use of aliased objects and components (now lifted). Similarly,
Ada 2005 prohibits discriminant_constraints
on any access type whose designated type has a partial view that is constrained.
Such a type will not be constrained in the heap to avoid privacy problems.
Again, the use of such subtypes is rare (they can only happen within
the package and its child units).

{*AI05-0041-1*}
**Correction:** Revised the rules on access subtypes having discriminant
constraints to depend on the “known to be constrained” rules.
This centralizes the rules so that future fixes need to be made in only
one place, as well as fixing bugs in obscure cases.

Ada 2005 and 2012 Editions sponsored in part by **Ada-Europe**