Version 1.2 of ais/ai-00171.txt
!standard 03.08 (18) 98-06-12 AI95-00171/03
!class binding interpretation 98-03-19
!status WG9 approved 98-06-12
!status ARG Approved 11-0-1 98-04-01
!status received 96-11-16
!priority Low
!difficulty Hard
!subject Elaboration of subtype_indications with per-object constraints
!summary 98-04-16
The elaboration of a subtype indication with a per-object constraint
occurs when an object of the enclosing type is created. This elaboration
consists of the evaluation of each per-object expression of the constraint,
followed by the usual actions associated with such elaboration, but using
the values for any expressions that are not part of a per-object expression
that were determined earlier when the type definition was elaborated.
For evaluating a named association applying to multiple components in a
per-object discriminant constraint, if the expression of the association
is not part of a per-object expression, then it must be evaluated once
for each associated component.
!question 98-03-19
When does the elaboration of a subtype indication with a per-object
constraint occur? What are the actions of such an elaboration?
When a component has a subtype_indication with a per-object constraint
and an object of the type containing the component is declared, the
subtype_indication containing the per-object constraint is apparently
never elaborated.
3.8(18) explains that subtype_indications with per-object constraints
are not elaborated, but that any expressions that are not part of a
per-object expression are evaluated. However, what to do with the
results of those evaluations never seems to be explained.
3.3.1(15-20) describes the process of elaborating an object_declaration.
In step 3, per-object expressions are evaluated, but there is no mention
of elaborating anything, although later paragraph 20 does seem to imply
that some sort of elaborations were supposed to have taken place in step 3.
The elaboration of per-object constraints is mentioned in (at least)
the following other places where objects are created:
4.3.1(19) creating record aggregates
4.8(10) creating heap objects via uninitialized allocators
9.4(14) creating a protected object
(This one is supposed to be redundant with, but in fact
appears to be inconsistent with 3.3.1.)
According to a strict reading, elaborating the per-object constraint would
appear to involve reevaluating the non-per-object expressions (since there
doesn't seem to be any separate definition of what happens when a per-object
constraint is elaborated), but not include any subtype compatibility checks
that would normally occur as part of subtype elaboration (since elaboration
of the subtype_indication containing the constraint isn't mentioned in these
paragraphs). What are the intended semantics?
!recommendation 98-03-19
Notwithstanding the rules given in 3.3.1(18), 4.3.1(19), and 4.8(10),
the elaboration of the subtype indication of a component definition with
a per-object constraint occurs when an object of the enclosing type is
created. This elaboration takes place on elaboration of an object
declaration, evaluation of an uninitialized allocator, and when
evaluating an aggregate of the type.
The elaboration consists of the evaluation of each per-object expression
of the component's constraint, followed by the conversion of the value
of each expression of the constraint to its appropriate expected type
and the performance of the compatibility check defined for the elaboration
of the subtype indication (see 3.2.2(11)). The values used for any
expressions that are not part of per-object expressions of the subtype's
constraint are those determined during the original elaboration of the
component definition as defined in 3.8(18). Such expressions are not
reevaluated during elaboration of the per-object constraint that occurs
as part of object creation, despite any RM rules that state when a
per-object constraint is elaborated (e.g, as part of evaluating an
allocator or aggregate).
Note further that the evaluation of expressions in a per-object constraint
defined in 3.8(18) was intended to take into account the case of named
associations for multiple components in a discriminant constraint. For
such an association, the expression must be evaluated once for each
associated component, as prescribed by 3.7.1(12).
!wording 98-04-01
Changes are required in 3.3.1(18), 4.3.1(19), 4.8(10), and 9.4(14)
to state that any subtype indications for components with a per-object
constraint are elaborated. The specific actions of elaborating such
subtype indications and their associated constraints, as described in the
recommendation, should be defined (perhaps in 3.8(18)). Also, 3.8(18)
needs to account for multiple evaluations of non-per-object expressions
in the case of named associations in a per-object discriminant constraint.
!discussion 98-04-01
There are two basic problems with the current RM wording regarding
the elaboration of components with a per-object constraint. The
first is that the rules don't explain what is done with the values
obtained from expressions that are not part of per-object expressions
(as defined in 3.8(18)) or whether such expression are reevaluated when
a per-object constraint is later elaborated during object creation.
The other problem is that the mention of elaboration of per-object
constraints in rules such as 4.3.1(19) and 4.8(10) fails to cover
the need for the subtype compatibility check that is normally performed
when elaborating a subtype indication.
The intent was clearly that the values of the expressions evaluated as
part of elaborating a component definition with a per-object constraint
(3.8(18)) should be used later when creating an object of the containing
type. It would not make sense to discard the values already determined
and to reevaluate the expressions (especially if they have side effects).
The description in the rules for allocator and aggregate evaluation
that states that a per-object constraint is elaborated should mention
that only the per-object expressions are evaluated at that point and
that the values for other expressions are those determined earlier
when the type was elaborated. (The description of the semantics
of elaborating per-object constraints should really be centralized
in a single place, such as 3.8(18).)
The rules for object declarations, allocator evaluation, and aggregate
evaluation all fail to require the subtype compatibility check that
occurs when a subtype indication is elaborated (and for object declarations
even the constraint elaboration is omitted). This check is certainly
needed in these cases as well. The fix for this oversight is to define
each of these rules to include the elaboration of the subtype indications
for components with per-object constraints (which also subsumes the
elaboration of the constraint itself).
One other minor gap is that the case of elaborating a named discriminant
association within a per-object constraint is not covered by that rule
in 3.8(18). The rule as given only describes a single evaluation for
each expression of the constraint, but the intent is that for a named
association the expression should be evaluated for each associated
component.
!appendix
!section 3.8(18)
!subject Elaboration of subtype_indications with per-object constraints
!reference RM95-3.8(18)
!from Vince Del Vecchio 96-10-30
!reference 1996-5737.a Vince Del Vecchio 1996-10-30>>
!discussion
When a component has a subtype_indication with a per-object constraint
and an object of the type containing the component is declared, the
subtype_indication containing the per-object constraint is apparently
never elaborated.
3.8(18) explains that subtype_indications with per-object constraints
are not elaborated, but that any included expressions are evaluated.
What to do with the results of those evaluations never seems to be
explained.
3.3.1(15-20) describes the process of elaborating an object_declaration.
In step 3, per-object expressions are evaluated, but there is no
mention of elaborating anything, although later paragraph 20
does seem to imply that some sort of elaborations were supposed to
have taken place in step 3.
What should really happen is a partial elaboration of the
subtype_indication should be performed, omitting pretty much any
evaluation, and using instead the already evaluated results (either
from 3.8(18) or from the per-object evaluations just performed).
However important part of the elaboration which do need to happen
include various checks (one due to a conversion in 3.7.1(12), then
the compatibility check of 3.2.2(11)), and actually creating the
subtype.
This is described somewhat in the AARM note 3.3.1(18.a), although that
is not binding.
The elaboration of per-object constraints is mentioned in (at least)
the following other places where objects are created:
4.3.1(19) creating record aggregates
4.8(10) creating heap objects via uninitialized allocators
9.4(14) creating a protected object
(This one is supposed to be redundant with, but in fact
appears to be inconsistent with 3.3.1.)
Strictly read, elaborating the per-object constraint would involve
reevaluating the non-per-object expressions (since there doesn't seem to
be any special definition of what happens when a per-object constraint
is elaborated), and not performing compatibility checks (since
elaboration of the subtype_indication containing the constraint doesn't
seem to be mentioned in these places). What is wanted is the same as in
3.8(18), to finish the elaboration of the subtype_indication containing
the constraint.
-Vince Del Vecchio
vdelvecc@inmet.com
****************************************************************
Questions? Ask the ACAA Technical Agent