3.7 Discriminants
1/2
{
AI95-00251-01}
{
AI95-00326-01}
[
{discriminant} {type
parameter: See discriminant} {parameter:
See also discriminant} A composite type
(other than an array
or interface type)
can have discriminants, which parameterize the type. A
known_discriminant_part
specifies the discriminants of a composite type. A discriminant of an
object is a component of the object, and is either of a discrete type
or an access type. An
unknown_discriminant_part
in the declaration of a
partial view of
a type specifies that the discriminants of the type are unknown for the
given view; all subtypes of such a
partial
view are indefinite subtypes.]
1.a/2
Glossary entry: {Discriminant}
A discriminant is a parameter for of
a composite type. It can control, for example, the bounds of a component
of the type if the component is that
type is an array type. A discriminant
for of a task
type can be used to pass data to a task of the type upon creation.
1.b/2
Discussion: {
AI95-00114-01}
{
unknown discriminants [partial]}
{
discriminants
(unknown) [partial]}
A
view
of a type, and all
of its subtypes
of the view, have
unknown discriminants when the number
or names of the discriminants, if any, are unknown at the point of the
type declaration
for the view. A
discriminant_part
of (<>) is used to indicate unknown discriminants.
Language Design Principles
1.c/2
{
AI95-00402-01}
When an access discriminant is initialized at the
time of object creation with an allocator of an anonymous type, the allocated
object and the object with the discriminant are tied together for their
lifetime. They should be allocated out of the same storage pool, and
then at the end of the lifetime of the enclosing object, finalized and
reclaimed together. In this case, the allocated object is called a coextension
(see 3.10.2). 1.d/2
Discussion: The
above principle when applied to a nonlimited type implies that such an
object may be copied only to a shorter-lived object, because attempting
to assign it to a longer-lived object would fail because the access discriminants
would not match. In a copy, the lifetime connection between the enclosing
object and the allocated object does not exist. The allocated object
is tied in the above sense only to the original object. Other copies
have only secondary references to it.
1.e/2
Note that when an allocator
appears as a constraint on an access discriminant in a subtype_indication
that is elaborated independently from object creation, no such connection
exists. For example, if a named constrained subtype is declared via "subtype
Constr is Rec(Acc_Discrim => new T);" or if such
an allocator
appears in the subtype_indication
for a component, the allocator is evaluated when the subtype_indication
is elaborated, and hence its lifetime is typically longer than the objects
or components that will later be subject to the constraint. In these
cases, the allocated object should not be reclaimed until the subtype_indication
goes out of scope.
Syntax
2
3
unknown_discriminant_part ::= (<>)
4
5/2
6
Name Resolution Rules
7
Legality Rules
8/2
8.a
Implementation Note: Discriminants on
array types were considered, but were omitted to ease (existing) implementations.
8.b
Discussion: Note that the above definition
for “discriminated type” does not include types declared
with an
unknown_discriminant_part.
This seems consistent with Ada 83, where such types (in a generic formal
part) would not be considered discriminated types. Furthermore, the full
type for a type with unknown discriminants need not even be composite,
much less have any discriminants.
8.b.1/1
9/2
9.a/2
This paragraph
was deleted.Reason: {
AI95-00230-01}
In an early version of Ada 9X, we allowed access
discriminants on nonlimited types, but this created unpleasant complexities.
It turned out to be simpler and more uniform to allow discriminants of
a named access type on any discriminated type, and keep access discriminants
just for limited types.
9.b
Note that discriminants of a named access type
are not considered “access discriminants.” Similarly, “access
parameter” only refers to a formal parameter defined by an
access_definition.
9.1/2
9.c/2
Reason: The all-or-none
rule is related to the rule that a discriminant constraint shall specify
values for all discriminants. One could imagine a different rule that
allowed a constraint to specify only some of the discriminants, with
the others provided by default. Having defaults for discriminants has
a special significance — it allows objects of the type to be unconstrained,
with the discriminants alterable as part of assigning to the object.
9.d/2
Defaults for discriminants
of tagged types are disallowed so that every object of a tagged type
is constrained, either by an explicit constraint, or by its initial discriminant
values. This substantially simplifies the semantic rules and the implementation
of inherited dispatching operations. For generic formal types, the restriction
simplifies the type matching rules. If one simply wants a "default"
value for the discriminants, a constrained subtype can be declared for
future use.
10/2
{
AI95-00230-01}
{
AI95-00402-01}
{
AI95-00419-01}
A
discriminant_specification
for an access discriminant
may have a default_expression shall
appear only in the declaration for a task or protected type, or
for a type
that is a descendant of an explicitly
limited record type with the reserved word
limited in its [(full)] definition or in that of one of its ancestors.
In addition to the places where Legality Rules normally apply (see
12.3),
this rule applies also in the private part of an instance of a generic
unit.
{generic contract issue [partial]}
10.a/2
Discussion: This rule implies that a
type can have
a default for an access discriminant
if the type is limited, but not if the only reason it's limited is because
of a limited component. Compare with the definition of limited type in
7.5.
Also, recall that
a “descendant’ includes the type itself, so an explicitly
limited record type can have defaults.
10.b/2
This paragraph
was deleted.Ramification: It
is a consequence of this rule that only a return-by-reference type can
have an access discriminant (see 6.5). This
is important to avoid dangling references to local variables.
10.c/2
Reason: {
AI95-00230-01}
We
also considered the following rules
for access discriminants:
10.d
- If a type has an access discriminant,
this automatically makes it limited, just like having a limited component
automatically makes a type limited. This was rejected because it decreases
program readability, and because it seemed error prone (two bugs in a
previous version of the RM9X were attributable to this rule).
10.e/2
- A type with an access discriminant
shall be limited. This is equivalent to the rule we actually chose for Ada 95, except that it allows a type to have an access discriminant
if it is limited just because of a limited component. For example, any
record containing a task would be allowed to have an access discriminant,
whereas the actual rule requires “limited record”.
This rule was also rejected due to readability concerns, and because
would interact badly with the rules for limited types that “become
nonlimited”.
10.f/2
- A type
may have an access discriminant if it is a limited partial view, or a
task, protected, or explicitly limited record type. This was the rule
chosen for Ada 95.
10.g/2
- Any type
may have an access discriminant. For nonlimited type, there is no special
accessibility for access discriminants; they're the same as any other
anonymous access component. For a limited type, they have the special
accessibility of Ada 95. However, this doesn't work because a limited
partial view can have a nonlimited full view -- giving the two views
different accessibility.
10.h/2
- Any type
may have an access discriminant, as above. However, special accessibility
rules only apply to types that are “really” limited (task,
protected, and explicitly limited records). However, this breaks privacy;
worse, Legality Rules depend on the definition of accessibility.
10.i/2
- Any type
may have an access discriminant, as above. Limited types have special
accessibility, while nonlimited types have normal accessibility. However,
a limited partial view with an access discriminant can only be completed
by a task, protected, or explicitly limited record type. That prevents
accessibility from changing. A runtime accessibility check is required
on generic formal types with access discriminants. However, changing
between limited and nonlimited types would have far-reaching consequences
for access discriminants — which is uncomfortable.
10.j/2
- Any type
may have an access discriminant. All types have special accessibility.
This was considered early during the Ada 9X process, but was dropped
for “unpleasant complexities”, which unfortunately aren't
recorded. It does seem that an accessibility check would be needed on
assignment of such a type, to avoid copying an object with a discriminant
pointing to a local object into a more global object (and thus creating
a dangling pointer).
10.k/2
- Any type
may have an access discriminant, but access discriminants cannot have
defaults. All types have special accessibility. This gets rid of the
problems on assignment (you couldn't change such a discriminant), but
it would be horribly incompatible with Ada 95.
10.l/2
- Any type
may have an access discriminant, but access discriminants may have defaults
only if they are a “really” limited type. This is the rule
chosen for Ada 2005, as it is not incompatible, and it doesn't require
weird accessibility checks.
11/2
11.a/2
Reason: The all-or-none
rule is related to the rule that a discriminant constraint shall specify
values for all discriminants. One could imagine a different rule that
allowed a constraint to specify only some of the discriminants, with
the others provided by default. Having defaults for discriminants has
a special significance — it allows objects of the type to be unconstrained,
with the discriminants alterable as part of assigning to the object.
11.b/2
Defaults for discriminants
of tagged types are disallowed so that every object of a tagged type
is constrained, either by an explicit constraint, or by its initial discriminant
values. This substantially simplifies the semantic rules and the implementation
of inherited dispatching operations. For generic formal types, the restriction
simplifies the type matching rules. If one simply wants a "default"
value for the discriminants, a constrained subtype can be declared for
future use.
12
13
- The parent subtype shall be constrained;
14
- If the parent type is not a tagged
type, then each discriminant of the derived type shall be used in the
constraint defining the parent subtype;
14.a
Implementation Note: This ensures that
the new discriminant can share storage with an existing discriminant.
15
- If a discriminant is used in the constraint
defining the parent subtype, the subtype of the discriminant shall be
statically compatible (see 4.9.1) with the
subtype of the corresponding parent discriminant.
15.a
Reason: This ensures that on conversion
(or extension via an extension aggregate) to a distantly related type,
if the discriminants satisfy the target type's requirements they satisfy
all the intermediate types' requirements as well.
15.b
Ramification: There is no requirement
that the new discriminant have the same (or any)
default_expression
as the parent's discriminant.
16
The type of the
default_expression,
if any, for an access discriminant shall be convertible to the anonymous
access type of the discriminant (see
4.6).
{convertible (required) [partial]}
16.a
Ramification: This requires convertibility
of the designated subtypes.
Static Semantics
17
18
[For a type defined by a
derived_type_definition,
each discriminant of the parent type is either inherited, constrained
to equal some new discriminant of the derived type, or constrained to
the value of an expression.]
{corresponding
discriminants} When inherited or constrained
to equal some new discriminant, the parent discriminant and the discriminant
of the derived type are said to
correspond. Two discriminants
also correspond if there is some common discriminant to which they both
correspond. A discriminant corresponds to itself as well.
{specified
discriminant} If a discriminant of a parent
type is constrained to a specific value by a
derived_type_definition,
then that discriminant is said to be
specified by that
derived_type_definition.
18.a
Ramification: The correspondence relationship
is transitive, symmetric, and reflexive. That is, if A corresponds to
B, and B corresponds to C, then A, B, and C each corresponds to A, B,
and C in all combinations.
19
{depend on a discriminant
(for a constraint or component_definition)} A
constraint
that appears within the definition of a discriminated type
depends
on a discriminant of the type if it names the discriminant as a bound
or discriminant value. A
component_definition
depends on a discriminant if its
constraint
depends on the discriminant, or on a discriminant that corresponds to
it.
19.a
Ramification: A
constraint
in a
task_body
is not considered to
depend on a discriminant of the task type,
even if it names it. It is only the
constraints
in the type definition itself that are considered dependents. Similarly
for protected types.
20
{depend
on a discriminant (for a component)} A
component
depends on a discriminant if:
21
21.a
Ramification: A component does
not
depend on a discriminant just because its
default_expression
refers to the discriminant.
22
- It is declared in a variant_part
that is governed by the discriminant; or
23
23.a
Reason: When the parent subtype depends
on a discriminant, the parent part of the derived type is treated like
a discriminant-dependent component.
23.b
Ramification: Because of this rule, we
don't really need to worry about “corresponding” discriminants,
since all the inherited components will be discriminant-dependent if
there is a new
known_discriminant_part
whose discriminants are used to constrain the old discriminants.
24
- It is a subcomponent of a component
that depends on the discriminant.
24.a
Reason: The concept of discriminant-dependent
(sub)components is primarily used in various rules that disallow renaming
or 'Access, or specify that certain discriminant-changing assignments
are erroneous. The goal is to allow implementations to move around or
change the size of discriminant-dependent subcomponents upon a discriminant-changing
assignment to an enclosing object. The above definition specifies that
all subcomponents of a discriminant-dependent component or parent part
are themselves discriminant-dependent, even though their presence or
size does not in fact depend on a discriminant. This is because it is
likely that they will move in a discriminant-changing assignment if they
are a component of one of several discriminant-dependent parts of the
same record.
25
Each value of a discriminated type includes a value
for each component of the type that does not depend on a discriminant[;
this includes the discriminants themselves]. The values of discriminants
determine which other component values are present in the value of the
discriminated type.
25.a
To be honest: Which values are present
might depend on discriminants of some ancestor type that are constrained
in an intervening
derived_type_definition.
That's why we say "values of discriminants" instead of "values
of
the discriminants" — a subtle point.
26
{known discriminants}
{discriminants (known)}
{constrained (subtype)}
{unconstrained (subtype)}
A type declared with a
known_discriminant_part
is said to have
known discriminants; its first subtype is unconstrained.
{unknown discriminants} {discriminants
(unknown)} A type declared with an
unknown_discriminant_part
is said to have
unknown discriminants. A type declared without
a
discriminant_part
has no discriminants, unless it is a derived type; if derived, such a
type has the same sort of discriminants (known, unknown, or none) as
its parent (or ancestor) type. A tagged class-wide type also has unknown
discriminants.
{class-wide type}
{indefinite subtype}
[Any subtype of a type with unknown discriminants
is an unconstrained and indefinite subtype (see
3.2
and
3.3).]
26.a/2
Discussion: {
AI95-00114-01}
An
unknown_discriminant_part
“(<>)” is only permitted in the declaration of a (generic
or nongeneric) private type, private extension,
incomplete
type, or formal derived type. Hence, only such types, descendants
thereof, and class-wide types can have unknown discriminants. An
unknown_discriminant_part
is used to indicate that the corresponding actual or full type might
have discriminants without defaults, or be an unconstrained array subtype.
Tagged class-wide types are also considered to have unknown discriminants
because discriminants can be added by type extensions, so the total number
of discriminants of any given value of a tagged class-wide type is not
known at compile time.
26.b/2
{
AI95-00287-01}
A subtype with unknown discriminants is indefinite, and hence an object
of such a subtype needs explicit initialization.
If the subtype is limited, no (stand-alone) objects can be declared since
initialization is not permitted (though formal parameters are permitted,
and objects of the actual/full type will generally be declarable).
A limited private type with unknown discriminants is “extremely”
limited;
objects of such a type
can be initialized only by subprograms (either procedures with a parameter
of the type, or a function returning the type) declared in the package.
Subprograms declared elsewhere can operate on and even return the type,
but they can only initialize the object by calling (ultimately) a subprogram
in the package declaring the type. Such a type is useful for keeping
complete control over object creation within the package declaring the
type.
26.c
A partial view of a type might have unknown
discriminants, while the full view of the same type might have known,
unknown, or no discriminants.,
Dynamic Semantics
27/2
{
AI95-00230-01}
{
AI95-00416-01}
For an access discriminant, its An
access_definition
is elaborated when the value of
the a
corresponding access discriminant is defined
:,
either by evaluation of its
default_expression, or by elaboration of a
discriminant_constraint,
or by an assignment that initializes the enclosing object..
[The elaboration of an access_definition
creates the anonymous access type. When the expression defining the access
discriminant is evaluated, it is converted to this anonymous access type
(see 4.6).] {implicit
subtype conversion (access discriminant) [partial]} 27.a/2
Ramification: {
AI95-00231-01}
{
AI95-00416-01}
The This conversion
of the expression
defining the access discriminant to the anonymous access type
raises
Program_Error Constraint_Error
if the initial value is null, or, for an object created
by an allocator of an access type T, if the initial value is an access
parameter that designates a view whose accessibility level is deeper
than that of T.
28
52 If a discriminated type has
default_expressions
for its discriminants, then unconstrained variables of the type are permitted,
and the values of the discriminants can be changed by an assignment to
such a variable. If defaults are not provided for the discriminants,
then all variables of the type are constrained, either by explicit constraint
or by their initial value; the values of the discriminants of such a
variable cannot be changed after initialization.
28.a
Discussion: This connection between discriminant
defaults and unconstrained variables can be a source of confusion. For
Ada 95, we considered various ways to break the connection between defaults
and unconstrainedness, but ultimately gave up for lack of a sufficiently
simple and intuitive alternative.
28.b
{
mutable}
An unconstrained
discriminated subtype with defaults is called a
mutable subtype,
and a variable of such a subtype is called a mutable variable, because
the discriminants of such a variable can change. There are no mutable
arrays (that is, the bounds of an array object can never change), because
there is no way in the language to define default values for the bounds.
Similarly, there are no mutable class-wide subtypes, because there is
no way to define the default tag, and defaults for discriminants are
not allowed in the tagged case. Mutable tags would also require a way
for the maximum possible size of such a class-wide subtype to be known.
(In some implementations, all mutable variables are allocated with the
maximum possible size. This approach is appropriate for real-time applications
where implicit use of the heap is inappropriate.)
29
53 The
default_expression
for a discriminant of a type is evaluated when an object of an unconstrained
subtype of the type is created.
30
54 Assignment to a discriminant of an object
(after its initialization) is not allowed, since the name of a discriminant
is a constant; neither
assignment_statements
nor assignments inherent in passing as an
in out or
out
parameter are allowed. Note however that the value of a discriminant
can be changed by assigning to the enclosing object, presuming it is
an unconstrained variable.
30.a/2
Discussion: {
AI95-00114-01}
An
unknown_discriminant_part
is permitted only in the declaration of a private type (including generic
formal private), private extension,
incomplete
type, or generic formal derived type. These are the things that
will have a corresponding completion or generic actual, which will either
define the discriminants, or say there are none. The (<>) indicates
that the actual/full subtype might be an indefinite subtype. An
unknown_discriminant_part
is not permitted in a normal untagged derived type declaration, because
there is no separate full type declaration for such a type. Note that
(<>) allows unconstrained array bounds; those are somewhat like
undefaulted discriminants.
30.b
For a derived type, either the discriminants
are inherited as is, or completely respecified in a new
discriminant_part.
In this latter case, each discriminant of the parent type shall be constrained,
either to a specific value, or to equal one of the new discriminants.
Constraining a parent type's discriminant to equal one of the new discriminants
is like a renaming of the discriminant, except that the subtype of the
new discriminant can be more restrictive than that of the parent's one.
In any case, the new discriminant can share storage with the parent's
discriminant.
31
55 A discriminant that is of a named access
type is not called an access discriminant; that term is used only for
discriminants defined by an
access_definition.
Examples
32
Examples of discriminated
types:
33
type Buffer(Size : Buffer_Size := 100)
is --
see 3.5.4
record
Pos : Buffer_Size := 0;
Value : String(1 .. Size);
end record;
34
type Matrix_Rec(Rows, Columns : Integer)
is
record
Mat : Matrix(1 .. Rows, 1 .. Columns); --
see 3.6
end record;
35
type Square(Side : Integer) is new
Matrix_Rec(Rows => Side, Columns => Side);
36
type Double_Square(Number : Integer) is
record
Left : Square(Number);
Right : Square(Number);
end record;
37/2
{
AI95-00433-01}
task type Worker(Prio : System.Priority; Buf : access Buffer) is
-- discriminants used to parameterize the task type (see 9.1)
pragma Priority(Prio); -- see D.1
entry Fill;
entry Drain;
end Worker; type Item(Number : Positive) is
record
Content : Integer;
-- no component depends on the discriminant
end record;Extensions to Ada 83
37.a
37.b/2
{
AI95-00251-01}
Discriminants are allowed on all composite types other than array
and interface types.
37.c
Discriminants may be of an access type.
Wording Changes from Ada 83
37.d
Extensions to Ada 95
37.e/2
{
AI95-00230-01}
{
AI95-00402-01}
{
AI95-00416-01}
Access discriminants (anonymous access types used
as a discriminant) can be used on any type allowing discriminants. Defaults
aren't allowed on discriminants of non-limited types, however, so that
accessibility problems don't happen on assignment.37.f/2
Wording Changes from Ada 95
37.g/2
37.h/2
{
AI95-00251-01}
Added wording to prevent interfaces from having
discriminants. We don't want interfaces to have any components.37.i/2
{
AI95-00254-01}
Removed wording which implied or required an access
discriminant to have an access-to-object type (anonymous access types
can now be access-to-subprogram types as well).37.j/2
{
AI95-00326-01}
Fixed the wording of the introduction to this clause
to reflect that both incomplete and partial views can have unknown discriminants.
That was always true, but for some reason this wording specified partial
views.37.k/2
{
AI95-00419-01}
Changed the wording to use the new term “explicitly
limited record”, which makes the intent much clearer (and eliminates
confusion with derived types that happen to contain the reserved word
limited.
Sponsored by Ada-Europe