Bounds of nominal subtype of multidimensional array aggregate

[sttaft]

Steve Baird submitted the following comment on 22-Sep-2023:

At the June 2023 ARG meeting, I was tasked with writing an AARM note to accompany AI22-0067 (AI22-0067 has already been submitted for WG9 review). Randy suggests that this note could be included in AI22-0005-1, the AARM AI.

AI22-0067 adds a new paragraph after 4.3.3(31) having to do with the nominal subtype of an array aggregate. Immediately after this (already approved) change, add an AARM note:

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.

[ARG-Editor]

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.

[sttaft]

I suppose the key question is whether being more specific is useful in a context where nominal subtype is relevant at compile time. The hypothetical case statement that works on a multidimensional array type seems to be the case which prompted defining a nominal subtype for aggregates. To me it also seems fine to pick some arbitrary subaggregate. I guess I wonder whether the AARM note is needed at all.

[ARG-Editor]

Right, in the compile-time case, all of the subaggregates would need to have static bounds, and it doesn't seem to matter which one is chosen in that case: the hypothetical case statement is not executed if they don't match, and if they do match, they are indistinguishable. The unchecked union case isn't relevant for array aggregates (unions being records).

As far as the note goes, I never thought it was needed, and I don't think you did, either. It's the person that thinks this is important for some reason that needs to be convinced.

[swbaird]

I (now) like Randy's idea that the implementation simply gets to pick one of the candidates, but we don't specify which one since the choice doesn't really matter. I'd still rather see some mention of this in an AARM note, as opposed to saying nothing, since otherwise it looks like a hole (even if it isn't). I don't feel strongly about it.

[sttaft]

On Mon, Oct 2, 2023 at 2:23 PM swbaird @.***> wrote:

I (now) like Randy's idea that the implementation simply gets to pick one of the candidates, but we don't specify which one since the choice doesn't really matter

Agreed.

. I'd still rather see some mention of this in an AARM note, as opposed to saying nothing, since otherwise it looks like a hole (even if it isn't).

I agree that there is a danger that all those Steve Baird clones out there will be hammering on us with ARG GitHub issues if we don't add the note. ;-)

I don't feel strongly about it.

But strongly enough, it seems, so we should add the note!

— Reply to this email directly, view it on GitHub https://github.com/Ada-Rapporteur-Group/User-Community-Input/issues/70#issuecomment-1743523176, or unsubscribe https://github.com/notifications/unsubscribe-auth/AANZ4FMWIQPR5XQO56LXWQ3X5MBCRAVCNFSM6AAAAAA5NILNZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBTGUZDGMJXGY . You are receiving this because you authored the thread.

Take care, -Tuck

Message ID: @.*** com>

[ARG-Editor]

This thread has been added to AI22-0005-1, the AI to collect AARM changes. No further action here is required.