!standard 4.3.3(29) 07-10-08 AI05-0037-1/02 !class binding interpretation 07-01-22 !status ARG Approved 10-0-0 07-06-03 !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 to 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) @drepl For an @fa with an @b choice, a check is made that no @fa is specified for an index value outside the bounds determined by the applicable index constraint. @dby For an @fa with an @b choice, a check is made that no @fa 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). ****************************************************************