Minutes of ARG Meeting 63K
6 October 2025
Voting Members:
Steve Baird, Randy Brukardt, Jeff Cousins, Gary Dismukes, Bob Duff, Ed Fish, Christoph Grein, Niklas Holsti, Brad Moore, Alejandro Mosteo, Justin Squirek [Leaves 10:51], Tucker Taft, Tullio Vardanega, Richard Wai [Arrive 10:45].
Non-voting Members:
None.
Observers:
None.
The meeting convened on Monday, 6 October 2025 at 10:36 hours EDT and adjourned at 13:31 hours EDT. The meeting was held using Zoom. The meeting covered all but one AI on the agenda.
Steve welcomes everyone to this meeting.
John Barnes and Jean-Pierre Rosen said that they will not attend. Richard Wai said that he will be 30 minutes late.
There were no comments on the minutes: Approve minutes: 13-0-0.
Our next electronic meeting is proposed for Monday, December 15. There is grumbling about having meetings on Mondays. We already had determined that Wednesdays don’t work. Tucker says anything after the 15th doesn’t work for him. He proposes Thursday, December 11th. There are no objections. So our next meeting is Thursday, December 11th., with the usual time (10:30-13:30 EST [-4 UTC]) and method (Zoom).
SC 22 approved the New Work Item for the Amendment, as well as an NWI for a revision (to be finished in 2027).
Randy hasn’t made much progress on the actual document, getting ready for this meeting had priority.
Tucker has provided this document to WG 9. He quickly goes through it. Steve thanks Tucker for doing this.
Randy asks Tucker about the update (or cancellation) of AI22-0119-1. He said that he forgot about it, he will look at that next time.
The combined unfinished old action items and new action items from the meeting are shown below.
The minutes cover detailed review of Ada 2022 AIs (AI22s). The AI22s are presented in numeric order, which is not necessarily the order in which they were discussed. Votes are recorded as “for”-“against”-“abstentions”. For instance, a vote of 6-1-2 would have had six votes for, one vote against, and two abstentions.
If a paragraph number is identified as coming from the working Ada 202y AARM, the number refers to the text in draft 4 of the Ada 202y AARM. Paragraph numbers in other drafts may vary. Other paragraph numbers come from the final Ada 2022 AARM; again the paragraph numbers in the many drafts may vary.
Tucker explains his changes. Brad suggests a minor fix, made in the Google Docs version.
Approve with changes: 13-0-0.
Tucker now has provided wording for this aspect when used on a function returning an aliased result.
Gary asks a couple of wording questions.
Gary can’t parse the first bullet. We wordsmith too long, eventually Randy calls time on it. Ed suggests swapping the parts, Tucker will try that offline.
Niklas asks what happens if some other task modifies the read_only object? Other rules of Ada make such things bad anyway (usually erroneous).
Steve wants to know about the renaming associated with generic in out objects. Usually these are handled in a similar way to renaming. Tucker agrees, but never considered that.
Niklas worries about the case when the read-only object is a protected object. He thinks you can return part of a private component of such an object (as an aliased return?), and it would be safe for another task to do that.
Tucker is directed to think about this case, and add more text about concurrent access.
Brad wonders if the aspect name should be more descriptive (“Read_Only_while_Result_Exists”). (We never have a conclusion to this, although several people expressed some support for the idea.)
Steve wonders about “portion of text”; he notes that evaluation of parameters doesn’t necessarily match the textual order. Someone says that they stay around until the end of the master construct, but Steve is worried about the start of the “portion of text”. Steve notes that if there are two function calls that are actual parameters, the first one that updates X and the second one that has Read_Only for X, we need the rule(s) to cover the first call. So the text portion needs to be wider than specified in this wording.
Approve intent: 11-1-1. Jeff is opposed (he is worried about concurrent access); Alejandro abstains.
After the discussion of the second alternative (see below), we came back to this AI.
Tucker will take this back, explain the Boolean flag implementation, add a rule for No_Coextensions, and give the AI a general clean-up.
Approve intent: 9-0-4. Randy, Gary, Ed, Jeff abstain.
Tucker rewrote this AI without answering the question (essentially leaving it Implementation-Defined).
Gary expresses discomfort with the implementation-defined result.
Randy complains that the implementation model is very heavy. Steve says that one could have the function return an extra bit as to whether an allocator is returned, rather than Tucker’s special list approach.
This is tying the lifetime of the discriminated object to the outer object. Tucker notes it is the same as being “owned” in the Rust sense.
Ed notes that if you allowed any sort of discriminants (that is, a discriminant of any type), then that is essentially a coextension (as it would be part of the object). Tucker notes that arbitrary kinds of discriminants would be difficult since they need to be checked in various places (including object creation).
Tucker claims that there is little compatibility impact of the Legality change. Tucker says that you can convert to a named type if you are not returning an allocator, and that would make it legal.
Tucker says he would prefer to have a definitive answer to this question; he’d rather the function did not create a coextension rather than be implementation-defined.
Straw vote: (Live with)
Always creates coextension: 7
Does not create coextension: 6
Implementation-defined coextension: 4
Straw vote: Choice:
Always create coextension: 5 (Tuck, Christoph, …) [I didn’t
get these all recorded before the hands were cleared.]
Does not create coextension: 3 (Randy, Jeff, Richard)
Abstain: 5.
This leans toward the original AI. We turn to that alternative AI.
Tucker recommends “Same_as_Actual” rather “Never_if_Appropriate_Actual”.
The need for the value “Same_as_Actual” is questioned. Randy says that it mainly stems from the need to only allow “Never” if the underlying type is actually unconstrained. He did that as writing Legality Rules is too difficult. For instance, “The conversion is illegal if the target subtype has Constraint => Never, and is discriminanted with defaults, or if the type is a formal private or derived type with ..., or ...”. That leads to needing to get the value from the actual, as a type like Integer can never have the “Never” value.
Steve wonders if separating solutions for the two problems would be simpler. Randy and Tucker think that would mostly double the amount of wording needed.
We look at examples of the use of this aspect.
Could the aspect be given directly on a formal parameter? Not with Ada as currently defined, which doesn’t allow predicates or constraints (ranges, discriminants), either. We would want to support all of that, and deal appropriately with the conformance challenges of that, rather than just hacking a single case. (That obviously is a separate AI, it would be quite complex and also useful beyond this case.)
Several people feel the solution still feels more complex than needed. Randy says that he has done all he can on this one. Tucker volunteers to try a redesign.
Keep Alive: 13-0-0.
Steve notes that we don't need this at all, because of Legality Rule 13.1.1(14/3), which makes the definition a legality check in an aspect_specification. That means the definition should be rechecked in a generic instantiation.
Tucker asks if the term “unspecifiable” is worthwhile. Is it valuable to have it?
Steve notes that it encapsulates the relatively unusual prohibition against full types. [Editor’s note: I wanted to say something about the term providing a place to discuss that the rule needs rechecking in the visible part of generic units, but not in the private part of such units. Rather than having to repeat that in each aspect, or leaving it to implementers to figure that out. But I was muted and the discussion moved on before I mentioned it.]
We decide that the intent is to define the term.
Approve intent: 12-0-1 Tucker abstains.
The AI goes back to Steve. It should not cause any semantic changes (as in the access type case). That case needs to be discussed separately.
Randy thinks the access type problem can be handled by allowing a proper definition of access indexings, should someone want those.
Tucker thinks that you always dereference in front of parens, and thus indexing doesn’t make sense for access types. Randy thinks that a private view should always be a more restrictive view of the full type. He says that’s fundamental to the idea of views – you never have views of the same type with different meaning for a single operation (and that is happening here). Randy continues that he always thought of these as separate types, and that would allow the sort of thing Tucker wants, but he has been repeatedly told that is the wrong model.
Someone [Editor’s note: I think this is a euphemism for “Randy”] should consider an AI.
Steve worries that this isn’t bulletproof: since the bounds could change for a discriminant-dependent array (if a whole object assignment changes the controlling discriminant).
Tucker suggests that we say that the object is something that can be renamed. We look for the appropriate wording, Randy finds it in 5.5.2(6.1/6). “an object for which renaming is allowed (see 8.5.1)”
Ed wonders why unconstrained and constrained types don’t statically match. Tucker notes that we want to allow implementations to have contiguous bounds and data, and that doesn’t work for slices. Allowing matching would break some implementations.
We could require some sort of very fat pointer, but that needs to be an option because of interfacing to C and other languages (which don’t use such pointers). That probably would need new aspects (and thus is out of bounds for this AI).
We change the description to the Range attribute, as Niklas worries that you could give the range backwards (that is, X’Last .. X’First should not match). We add an AARM Ramification to note that First and Last can be used instead of Range.
Approve AI with changes: 11-0-2. Ed, Richard abstain.
Randy wants to know if Tucker wants this to be a work item (so he creates an AI). He says that he will take this. Add this to his homework.
The idea is that one doesn’t need to look into the inside of Pure subprograms to decide if they can be removed. Tucker looks at the actual wording, and it is pretty clear that “other side” effects are not considered. So there is nothing to do here.
Someone mentions that the last sentence was added by AI22-0098-1, and it clearly answers the question. Randy notes that this text wasn't changed by the Corrigendum, it just was reformatted to be easier to read. [Editor's note: Specifically, the last sentence has been in every version of the permission since it was introduced in Ada 9x v. 5.0. But we accidentally left it out when we reformatted the permission in AI22-0023-1. It never was left out of the RM, as it was when I was applying the reformatting that I noticed that it had been omitted, and I immediately created a presentation item (which became AI22-0098-1) to replace it.]
Steve starts to worry about Pure procedures like Ada.Assertions.Assert (see 11.4.2). He says that it would appear that it needs to do nothing. Randy notes that the permission generally doesn’t allow eliminating the *first* call on a subprogram, only subsequent ones, so any problem would be limited. Still, the entire idea of Pure is that there are no side-effects, so a Pure procedure is very dubious. Perhaps Ada.Assertions shouldn’t be Pure? Or the permission should only apply to functions, since a procedure without a side-effect is essentially the null procedure. Steve will consider this topic (it has little to do with the actual issue here).
Tucker will write a response and close this issue.
This seems reasonable on its face. Tucker will take this one.