Re: Missing Index Value in Array Aggregate

[Adam Beneschan <adam@irvine.com>]

On Sep 26, 6:21 am, csamp...@inetworld.net (Charles H. Sampson) wrote:
>      The compiler used in my work allowed an aggregate for
> an array with an elaboration type index to omit one of the
> index values.  (There was no others choice.)  As a result,
> Constraint_Error was raised at library elaboration time,
> which is a nasty bug to run down in this environment.
>
>      I was getting ready to file a bug report, certain
> that this was a compile-time error rather than run-time,
> when I decided to take a close look at that old LRM.  I
> was surprised to find that the legality rules of 4.4.3

Should be 4.3.3

> appear to be designed to allow just that, particularly the
> second clause of paragraph 18.
>
>      Does anyone know what the purpose of this is?  I can
> see that there's an occasional need for it, as in the case
> of an aggregate for a formal parameter of an unconstrained
> array type.  It certainly seems to me that in the case of
> an aggregate for a constrained array object, catching this
> error at compile time in is line with Ada's concept of
> doing as much as possible at compile time.  Or am I wrong?
> Are there other paragraphs that do require this to be
> caught during compilation?

There can be nothing illegal about an aggregate such as

   (2 => 1010, 3 => 2020, 4 => 3030)

when taken by itself.  Any problems have to happen only when the
compiler knows what type is expected for the aggregate.  When the
expected type is determined, the aggregate can resolve to any one-
dimensional array type whose index and element types are some integer
type; if the expected type is something else, then the aggregate is
illegal.

Note, though, that array *types* don't have bounds on their indexes.
An array subtype is an array type plus (possibly) a constraint, where
the constraint puts bounds on the indexes.  Once the type of the above
aggregate is determined, the aggregate will have an (unnamed) subtype
of that type with a constraint of (2..4).  Then, depending on what you
do with that aggregate, the subtype will be *converted* to some other
subtype.  If you declare an object:

   type int4 is array(1..4) of integer;
   A : int4 := (2 => 1010, 3 => 2020, 4 => 3030);

the semantics involve a type conversion of the unnamed aggregate
subtype to "int4".  The rules for type conversions are spelled out in
4.6.  The result is that a Constraint_Error will be raised.

In general, type conversions raise Constraint_Error when the
constraint isn't satisfied; they don't make a program illegal.  This
is consistent, because of course a compiler can't always catch every
case where a type conversion can cause a Constraint_Error:

  type intx is array (I..J) of integer;
  A : intx := (2 => 1010, 3 => 2020, 4 => 3030);

where I and J are, say, procedure parameters.

Ada 83 was consistent about this.  In Ada 95, I believe that some
constraint violations can make a program illegal, when static
expressions are involved, but only if they occur in the *middle* of
evaluating a static expression (4.9(34)), not when a static expression
can be evaluated but is known to be outside the bounds of the subtype
it will be converted to.

In any event, though, when it comes to catching subtype constraint
violations, I don't think "doing as much as possible at compile time"
is part of the Ada philosophy, since it leads to inconsistencies, and
having clear and consistent rules is very important also.  That's just
my guess at an explanation for why this isn't illegal.

Our compiler, by the way, would probably have caught the aggregate you
tried to use (depending on the exact construct).  It would have
displayed a warning that an exception will be raised at runtime.  I
just tried GNAT, and it also displays a warning at least in the case I
tried.  Our compiler also has an option that will treat a program as
illegal if it encounters any such cases where an exception is known to
be raised, but then of course this isn't strictly Ada.

                        -- Adam