Version 1.3 of ai12s/ai12-0084-1.txt

Unformatted version of ai12s/ai12-0084-1.txt version 1.3
Other versions for file ai12s/ai12-0084-1.txt

!standard 4.3.3(23.1/2)          13-10-28 AI05-0084-1/01
!class binding interpretation 13-10-28
!status Corrigendum 2014 13-12-06
!status ARG Approved 9-0-1 13-11-15
!status work item 13-10-28
!status received 13-06-12
!priority Low
!difficulty Easy
!qualifier Omission
!subject Box expressions in array aggregates
!summary
The value of the Default_Component_Value aspect is used for the value of <> in an array aggregate, if it was specified for the array type.
!question
For box expressions in an array aggregate, 4.3.3(23.1/2) says
For an array_component_association with <>, the associated component(s) are initialized by default as for a stand-alone object of the component subtype (see 3.3.1).
In the case where the Default_Component_Value aspect of the array type has been specified, this rule ignores it.
This seems wrong. Should Default_Component_Value be taken into account? (Yes.)
!recommendation
(See Summary.)
!wording
Modify 4.3.3(23.1/2) as follows:
Each expression in an array_component_association defines the value for the associated component(s). For an array_component_association with <>, the associated component(s) are initialized {to the Default_Component_Value of the array type if this aspect has been specified for the array type; otherwise, they are initialized} by default as for a stand-alone object of the component subtype (see 3.3.1).
!discussion
It would be silly to ignore an explicitly specified default component value in an aggregate.
The intent was that the rule of 3.3.1(13/3) would be used when Default_Component_Value is specified, but that doesn't happen because the wording of 4.3.3(23.1/2) only talks about the component subtype (and not the subtype of the array as a whole).
Note that this rule is formally inconsistent with the published Ada 2012 standard (in that the initial value can be different than specified by that standard). This rule is better as it matches the understanding, the rule for record aggregates (where default expressions are used, of course), and it also matches the behavior of all known Ada 2012 implementations. (It still will be documented as an inconsistency, of course.)
!corrigendum 4.3.3(23.1/2)
Replace the paragraph:
Each expression in an array_component_association defines the value for the associated component(s). For an array_component_association with <>, the associated component(s) are initialized by default as for a stand-alone object of the component subtype (see 3.3.1).
by:
Each expression in an array_component_association defines the value for the associated component(s). For an array_component_association with <>, the associated component(s) are initialized to the Default_Component_Value of the array type if this aspect has been specified for the array type; otherwise, they are initialized by default as for a stand-alone object of the component subtype (see 3.3.1).
!ASIS
No changes needed.
!ACATS test
An ACATS C-Test is needed to ensure that the proper default value is used in array aggregates with <> components.
!appendix

From: Steve Baird
Sent: Wednesday, June 12, 2013  10:09 AM

The following (minor) issue came up in an internal AdaCore discussion.

For box expressions in an array aggregate, the rule is

    For an array_component_association with <>, the associated
    component(s) are initialized by default as for a stand-alone object
    of the component subtype (see 3.3.1).

In the case where the Default_Component_Value aspect of the array type has
been specified, this rule ignores it.

This is inconsistent with the corresponding rule for records.

   For a record_component_association with <>, if the
   component_declaration has a default_expression, that
   default_expression defines the value for the associated component(s);
   otherwise, the associated component(s) are initialized by default as
   for a stand-alone object of the component subtype (see 3.3.1).

I think (and Tuck and Gary have agreed) this was just due to an oversight.
Nobody noticed this interaction when Default_Component_Value was added to the
language.

To see how this makes a difference, consider the behavior of the following example:

    with Text_IO;
    use Text_IO;
    procedure P is
       type T is new Integer with Default_Value => 123;
       type T_For_Two is array (Boolean) of T
         with Default_Component_Value => 456;
       X : T_For_Two := (others => <>);
    begin
       Put_Line (T'Image (X (False)));
    end;

I suggest replacing the 4.3.3(23.1/2) wording quoted above with something
along the lines of

    For an array_component_association with <>, the associated
    component(s) are initialized to the Default_Component_Value
    of the array type if this aspect has been specified; otherwise,
    they are initialized by default as for a stand-alone object of
    the component subtype (see 3.3.1).

Would "each is initialized" be better than "they are initialized"?
Saying "they are initialized ... as for a stand-alone object" seems like a
singular/plural mismatch.

This is an incompatible change; I still think it is a good idea.

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

From: Robert Dewar
Sent: Wednesday, June 12, 2013  10:36 AM

> The following (minor) issue came up in an internal AdaCore discussion.
>
> For box expressions in an array aggregate, the rule is
>
>      For an array_component_association with <>, the associated
>      component(s) are initialized by default as for a stand-alone object
>      of the component subtype (see 3.3.1).
>
> In the case where the Default_Component_Value aspect of the array type 
> has been specified, this rule ignores it.

For me, the rule does not ignore it (because that would violate Dewar's rule
of not being able to deduce nonsense from the RM :-))

Clearly DCV should be taken into account!
(for interest, what does GNAT do now?)

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

From: Jean-Pierre Rosen
Sent: Wednesday, June 12, 2013  10:37 AM

> This is an incompatible change; I still think it is a good idea.

Not an incompatible change; an obvious fix to an omission. And since all
vendors that implement Ada2012 are ready to make that change...

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

Questions? Ask the ACAA Technical Agent