Version 1.2 of acs/ac-00171.txt

Unformatted version of acs/ac-00171.txt version 1.2
Other versions for file acs/ac-00171.txt

!standard 4.9(14)          09-02-13 AC95-00171/01
!class confirmation 09-02-13
!status received no action 09-02-13
!status received 09-01-29
!subject Static expressions that will never be evaluated
!summary
!appendix

!topic Static expressions that will never be evaluated
!reference 4.9(33-37), 4.3.3
!from Adam Beneschan 09-01-29
!discussion

Consider this example:

    package Pack1 is

        Number_Of_Diners : constant := 6;

        type Ounces is new Float;
        type Portion_Array is array (Natural range <>) of Ounces;
        The_Whole_Pie : constant Ounces := 80.0;

        Portions : Portion_Array (1 .. Number_Of_Diners) :=
            (others => The_Whole_Pie / Ounces(Number_Of_Diners));

    end Pack1;

Nothing unusual there.  But if Number_Of_Diners is changed to 0, the program
will become illegal even though it couldn't possibly raise an exception at
runtime.  The rules in 4.9(33ff) say that the static expression

    The_Whole_Pie / Ounces(Number_Of_Diners)

is evaluated at compile-time, and is thus illegal since it fails Division_Check,
even though the dynamic semantics of array aggregates imply that the expression
will never be evaluated since there are no associated components.

Is this the intended result?  Should the first sentence of 4.9(33) be expanded,
maybe something like this?

    A static expression is evaluated at compile time except when it is
    part of the right operand of a static short-circuit control form
    whose value is determined by its left operand, or except when it
    is the expression of an array_component_association whose
    discrete_choice_list is statically known to denote zero
    components.

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

[Private comments on this idea:]

Do we really need more complication in this area? We do have a special
case for short circuits. But in this case, the problem is easily avoided
by using <> to initialize aggregate components when no value is expected
to be evaluated.

In the example given, setting Diners to 0 (statically) looks like a bug,
not something intended. Isn't a good thing that the bug is detected.

There are (Ada 83) ACATS tests with an aggregate of the form
  1..0 => do_something_stupid, and there is code to make sure
do_something_stupid is fully analyzed and diagnosed if need be. Why would
we change this behavior now?

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


Questions? Ask the ACAA Technical Agent