Version 1.1 of ai05s/ai05-0037-1.txt

Unformatted version of ai05s/ai05-0037-1.txt version 1.1
Other versions for file ai05s/ai05-0037-1.txt

!standard 4.3.3(29)          07-01-22 AI05-0037-1/01
!class binding interpretation 07-01-22
!status work item 07-01-22
!status received 07-01-21
!priority Medium
!difficulty Easy
!qualifier Omission
!subject Out of range <> associations in array aggregates
!summary
An association for an index value outside of the bounds determined for an array aggregate with an others choice raises Constraint_Error, regardless of whether it gives an expression or a <>.
!question
Consider:
type Arr is array (5..9) of Integer; procedure P (Arg : Arr);
P ((5 => 1, 10 => <>, others => 2));
4.3.3(29) says
For an array_aggregate with an others choice, a check is made that no expression is specified for an index value outside the bounds determined by the applicable index constraint.
This rule says nothing about an association that is given as <>, so this rule doesn't apply and "10 => <>" does not raise Constraint_Error.
In this case, what does it mean? There is no component with index 10 in this aggregate, so perhaps the association is just ignored.
!recommendation
(See Summary.)
!wording
Change 4.3.3(29) as follows:
For an array_aggregate with an others choice, a check is made that no expression {or <>} is specified for an index value outside the bounds determined by the applicable index constraint.
!discussion
It would be bizarre for the checking of indexes would be different depending on whether an expression or <> is used. It appears more likely that this rule was just missed when <> was added to the language.
Note that this cannot matter for positional array aggregates, as <> is not allowed in them other than in the others choice.
!corrigendum 4.3.3(29)
Replace the paragraph:
For an array_aggregate with an others choice, a check is made that no expression is specified for an index value outside the bounds determined by the applicable index constraint.
by:
For an array_aggregate with an others choice, a check is made that no expression or <> is specified for an index value outside the bounds determined by the applicable index constraint.
!ACATS test
Add a C-Test to ensure that this check is made.
!appendix

From: Randy Brukardt
Date: Sunday, January 21, 2001  12:08 AM

4.3.3(29) says 
  For an array_aggregate with an others choice, a check is made that
  no expression is specified for an index value outside the bounds
  determined by the applicable index constraint. 

Taken literally, that would mean that

    type Arr is array (5..9) of Integer;
    procedure P (Arg : Arr);

    P ((5 => 1, 10 => <>, others => 2));

is legal, because <> isn't an expression, and thus the rule doesn't apply.

This wouldn't be horrible, as <> would not do anything in this case. But
it's weirdly inconsistent. And this looks like a case where we failed to
notice that the wording needed changing, rather than any intended "feature".

So I suggest we change the wording to:

  For an array_aggregate with an others choice, a check is made that
  no expression or <> is specified for an index value outside the bounds
  determined by the applicable index constraint. 

(It would be nicer to take about associated components, but that gets weird
since there can hardly be any components outside of the range.)

Comments?

****************************************************************

From: Pascal Leroy
Date: Sunday, January 21, 2001  3:47 AM

Agreed.  In fact it would be good to scan the entire 4.3* sections for
occurrences of "expression" and see if they should be replaced by
"expression or <>".

****************************************************************

From: Randy Brukardt
Date: Monday, January 22, 2001   2:01 PM

Well, I did that when we wrote the AI, and I did it again writing the 
test objectives, and I just did it again. Not much else. Couple of points:

4.3.3(26) looks like it might need a change, but we don't allow <> in
positional array aggregates.

4.3.3(23) worried me a bit, but I concluded it is already OK. <> means the
component "initialized by default". If there are multiple associated components,
each one will be initialized by default (and if that means that each component
ends up with a different value, so be it). It doesn't say that one component
is initialized by default, and then others are copied from it.

4.3.1(20) also appears worrisome. But here it doesn't make sense to talk
about "for each associated component", because we're considering the value
of <> for each individual associated component. (see 4.3.1(19.1/2)). And each
component has its own default expression or its own default initialization.
After all, even the types of the components can be different.

It might make sense to add an AARM note to make that point clear (for both
4.3.1(20) and 4.3.3(23)), but I don't think any wording changes are needed.

Thus, I conclude that this is the only such glitch (at least until someone else
finds one).

****************************************************************

From: Tucker Taft
Date: Monday, January 22, 2001  2:22 PM

I'm convinced (and impressed).

****************************************************************

Questions? Ask the ACAA Technical Agent