Version 1.1.1.1 of ais/ai-00171.txt

Unformatted version of ais/ai-00171.txt version 1.1.1.1
Other versions for file ais/ai-00171.txt

!standard 03.08 (18)          98-04-16 AI95-00171/02
!class binding interpretation 98-03-19
!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