Version 1.7 of ai22s/ai22-0005-1.txt

From: John Barnes
Sent: Tuesday, May 22, 2021 xx:xx PM

... [Placeholder for the moment.]

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

Editor's note (Nov 8, 2021): All of the items above this
marker have been included in the working version of the AARM.

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

From: Niklas Holsti
WG 9 Review issue #167 - May 21, 2021

In this "Ramification" [4.9(13.b) - Editor.], the last case, "when specifying
the value of a discriminant ...", is no longer exactly true, because a
nonstatic value is now allowed if the value has a static subtype that governs
the variant part, RM 4.3.1(17/5).

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

From: Randy Brukardt
WG 9 Review issue #167 - May 25, 2021

You are correct. Moreover, this note reads as if this is a complete list of 
places where static expressions are required. But there has been no
maintenance of this list in Ada 2005, Ada 2012, or Ada 202x, and it is almost
certainly missing some constructs. It would be better to reduce it to a few
interesting cases as examples, because no one is ever going to remember to
maintain a list like this, (Rather, the complete list should be in the index
as "static expression, required", but that's another can of worms at this late
date - trying to find all of the places would be a pain.)

Anyway, I replaced the entire note with:

The language requires a static expression in a number_declaration, a numeric 
type definition, certain representation items, and a number of other places.

If someone would like to develop a complete list of current places, I'd be 
happy to put index entries in for them all. In that case, I'd add to the above
" See 'static expression, required' in the index for a complete list of
places".

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

From: Tucker Taft
WG 9 Review issue #167 - May 27, 2021

I would defer the new index entry to the next revision. I would change
"places" to "contexts" in your new wording.

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

From: Randy Brukardt
WG 9 Review issue #167 - May 27, 2021

I've marked this "deferred" so we remember to add the missing index entries.

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

From: Randy Brukardt
In part from issue #19 - September 2, 2022

The profiles defined all should be indexed like "profiles, Ravenscar"
(similarly to restrictions).

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

From: Steve Baird
Sent: Wednesday, April 19, 2023 (privately)

Are we missing something in

    AARM Reason: For a function that has a parameter of T or access T, a blanket
    rule in 13.1.1 requires the function to be a primitive operation of T, the
    wording about the same declaration_list is redundant in that case.

? Perhaps something like

    AARM Reason: For a function that has a parameter of T or access T (so a blanket
    rule in 13.1.1 requires the function to be a primitive operation of T) the
    wording about the same declaration_list is redundant.

would be better.

This wording occurs twice in the AI.

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

From: Randy Brukardt
Sent: Friday, April 21, 2023 (privately)

How about:

   AARM Reason: For a function that has a parameter of T or access T, a blanket
   rule in 13.1.1 requires the function to be a primitive operation of T, so the
   wording about the same declaration_list is redundant in that case.

   [Editor's note: Fix both of the AARM notes in AI22-0002-1 (After
   AARM 4.1.6(3.b/3) and AARM 5.5.1(8.a/3)).]

I suspect this is what was meant to be written. The point is that the blanket
rule makes the wording redundant in this particular case. We have the case
first, the mention of the blanket rule, and finally the consequence.

One could imagine fully rewriting these notes to reorder the parts, but I haven't
found anything that works better.

Since AI22-0002-1 is WG 9 approved, I'll put this wording fix into AI22-0005-1
(the AARM note AI). No ARG action is needed.

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

From: Github issue #66, Tucker Taft
Sent: September 7, 2023

Section A.8.2, File Management, has useful descriptions of several operations
applicable to almost all kinds of files. But these appear nowhere in the Index
of the RM. That seems like an oversight.

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

From: Github issue #66, Randy Brukardt
Sent: September 28, 2023

This isn't really a "bug report", since the index is non-normative. Rather, it
is handled through the informal AARM update process. I've added this topic to
AI22-0005-1 where all of the AARM fixes live, and closed this topic.

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

From: Github issue #70, Steve Baird
Sent: September 28, 2023

We've currently got: [In AI22-0067-1 - Editor.]

   Add after 4.3.3(31):

      The nominal subtype of an array_aggregate (other than a subaggregate)
      is constrained by the values defined for its bounds and those of any
      subaggregates.

For AARM, add after that:

   To be honest:
      If an array_aggregate has more than one subaggregate corresponding to
      the same index, then the bounds of the first such subaggregate determine
      the constraint of the nominal subtype of the array_aggregate
      for that index.

Given the current language definition (and, in particular, the RM's uses of
"nominal subtype"), there does not appear to be any need to mention the
case where some but not all of the subaggregates corresponding to a given
index have static bounds. One could imagine something like "use static
bounds if they are available; otherwise take the bounds from the first
subaggregate" but this does not appear to be necessary.

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

From: Github issue #70, Randy Brukardt
Sent: September 29, 2023

The proposed note seems like unjustified overspecification to me. We know that
the bounds of all such subaggregates have to be the same, if not, Constraint_Error
will be raised. If that happens, nothing that depends upon the nominal subtype
can be executed. So, it doesn't matter which set of bounds is selected, and we
should let the implementation pick whatever is convenient for it. Ergo, I think
a better note would be something like:

   Ramification: If an array_aggregate has more than one subaggregate
   corresponding to the same index, then Constraint_Error will be raised unless
   all of the bounds of such subaggregates are the same. If Constraint_Error
   is raised, no code that could depend upon the details of the nominal subtype
   of the aggregate could be executed. Therefore, the implementation can use
   whichever such subaggregate is convenient to determine the bounds of the
   nominal subtype.

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