Minutes of ARG Meeting 63Q
22, 24 September 2026
Tuesday Session:
Voting Members:
Steve Baird, Randy Brukardt, Jeff Cousins, Gary Dismukes, Christoph Grein, Niklas Holsti, Brad Moore, Justin Squirek, Tucker Taft, Tullio Vardanega, Richard Wai.
Non-voting Members:
Bob Duff.
Observers:
Ronan Desplanques [Left 10:59 EDT, returned 11:32 EDT]
Thursday Session:
Voting Members:
Steve Baird, Randy Brukardt, Jeff Cousins, Gary Dismukes, Christoph Grein [Left 12:06 EDT], Niklas Holsti, Brad Moore [Left sometime before 11:50 EDT because of connectivity while driving], Jean-Pierre Rosen [Left 12:07 EDT], Justin Squirek, Tucker Taft, Tullio Vardanega.
Non-voting Members:
Ed Fish.
Observers:
Ronan Desplanques [Left 10:59 EDT, returned 12:16 EDT]
The first session of the meeting convened on Tuesday, 22 September 2026 at 10:43 hours EDT and adjourned at 13:30 hours EDT. The second session of the meeting convened on Thursday, 24 July 2026 at 10:35 hours EDT and adjourned at 13:31 hours EDT. The meeting was held using Zoom. The meeting covered many of the AIs on the agenda as well as several Github issues.
Steve welcomes everyone to this meeting.
On Tuesday, Randy takes attendance. 11 voters, 1 non-voter, and 1 observer. (The observer missed an hour.) On Thursday, 11 voters, 1 non-voter, and 1 observer. (Three voters left at the break; the observer missed an hour.)
Jean-Pierre Rosen says he will miss Tuesday, and will leave early Thursday. Richard Wai says he will miss Thursday. Christoph Grein says he will leave early Thursday. Bob Duff reported late that he wouldn’t be able to attend on Thursday. Brad found out that he would have to be in a car crossing the Canadian Rockies during the meeting, and would miss part of the meeting because of spotty cell coverage in the mountain passes.
There were no comments on the minutes: Approve minutes: 11-0-0.
Our next electronic meeting is proposed for December 1-2nd. There are immediate objections to December 1st as that is the date of the WG 9 meeting. (Randy groans that he should have looked at his personal calendar before picking these dates off of a wall calendar.) We next try the 2nd and 3rd, there are no objections. So we decide on December 2-3rd, 10:30 EST, Zoom meeting.
Randy suggests that we put aside an hour to look at Github Issue. Tucker had indicated online that he had a couple that he wanted to know whether there was more general interest, and we also should not neglect the many other suggestions that we have gathered over the last couple of years. We agree to set aside the last hour of one of the sessions to do this.
Randy asks Brad what is happening with AI22-0163-1. Brad replies that he concentrated on AI22-0162-1, he will work on it next time. We don’t discuss any other of these items (many are old).
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 5 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.
Steve explains that this is not complete, he still needs to define what “known to succeed” means for accessibility checks.
Beyond that, there is not a lot of change here.
Steve needs the flow analysis part of AI22-0165-1 (which will be moved to a separate AI).
Keep alive: 10-0-1. Christoph abstains.
We are using the sixth alternative, so these are not going to be used.
No Action: 11-0-0.
AdaCore’s language development team is on board with the Pinned aspect idea, but suggests using one aspect per subprogram rather than per parameter.
The True/False thing was Tucker’s invention, he agrees that all is better. Randy had been concerned that it was part of the AdaCore proposal. Randy notes that null is weird, but it is rather unlikely that anyone would write that, as it is the usual existing case, and will remain the default for compatibility.
Tucker notes that we have defined a subset of primitive operations that are “derivable”. He notes that primitive is used in various ways not directly related to derivation and inheritance, so he didn’t want to change the meaning of that term.
Bob wonders why Tucker chose “derivable” rather than “inheritable”? Tucker explains that a parameter is not separately inherited, that’s for a full subprogram. This term can apply to individual parameters.
The rules like two tagged types not allowed for an operation don’t apply to pinned parameters/results. We wonder if a change to 3.9.2(12) is missing. We decide that the rule 3.9.2(12) doesn’t need to change since the definition of dispatching operation has changed.
Steve suggests that we require that the parameters are given in order. We agree this makes sense. Tucker words this rule.
Approves AI with changes: 10-0-1. Randy abstains.
We agree that the new alternative is better and simpler. So we will close this one.
No Action: 10-0-0.
In discussions on the original alternative, Tucker wondered that it might make more sense if bounding of space is orthogonal with whether an object is constrained. Eventually, Tucker decided to separate these into two separate aspects. He created this alternative to see if that is an improvement over the original proposal, and he thinks that this version is simpler than the original version.
Tuck notes that he plans to restructure the wording that defines the aspects. The current version defines the behavior for objects with the aspect definition, and the rest elsewhere. That’s confusing, as a reader can easily think that the object version is the entire definition (the editor admits he made this mistake). Either it all should be elsewhere, or all with the aspect. Tucker will choose one.
He also intends to move Storage_Bound to 13.11. There is a brief discussion of this idea; Randy notes that 13.11 is already fairly large and complex. Tucker says that he thinks this probably should be a new subsection under 13.11, not part of 13.11 itself.
Steve asks if the component accessibility checks also cover access-to-subprogram discriminants? Probably they ought to, but he should explore/explain the ramifications of that.
Tuck notes that access discriminants do not allow being unconstrained, so we are not allowing them to be changed on components or stand-alone objects. He was concerned that could open up a lot of additional cans of worms, and it doesn’t seem very important, so he is not proposing any additional functionality there. This means that the cases that need checks are mostly associated with class-wide types (since any extension, including ones that aren’t defined yet, can have access discriminants, even if the class-wide type does not have any).
Ed suggests renaming constant Unbounded to Unbounded_Storage, so it doesn’t conflict with other definitions, and so it is more readable when used with use clauses.
Niklas asks if there is a suggestion that bounded objects not use the heap. We have such advice for bounded containers, it would be a good idea to have something like that here. [Editor’s note: This probably only makes sense for bounded objects that have no unbounded components; objects with unbounded components need some sort of local heap (storage pool), so where the storage ultimately comes from is less important.]
Approve intent: 10-0-0.
We don’t have anything that needs discussion on this one. The AI remains with Tucker. We didn’t take any vote on this AI.
Brad explains the changes that were made.
The implementation permission is bad, because it adds a portability problem. If an implementation takes advantage of the permission, a pool extension following the original rules would raise Program_Error rather than working as expected. The point of having the Reclaimed flag is avoid that. We decide to remove the implementation permission.
Steve expresses discomfort with an in parameter that has to be False. He suggests that we provide a default implementation that sets an out parameter to False. Bob and Tucker say that they have written code like this, it happens when null subprograms are used (especially in interfaces, which this is effectively). In this case, the caller is the implementation, so no users are impacted by the requirement to pass in False. We agree to leave this as is.
Steve wonders if “extension” includes grandchildren”. Tucker suggests using “descendant” instead, and rewords the text.
We look briefly at the time line. It is suggested to turn this into an AARM note. (Does the timeline include Unchecked_Deallocate_All_Subpools? It should. – Editor)
Several other wording changes also were made. The term “specific” seems wrong here, it was changed to “individual” in several places. The last two items in the description of Deallocate_All_Subpools should be combined. “Object” is missing after “subpool” in a couple of places. Tucker made all of these corrections in the Google Docs version of the AI.
Approve AI with changes: 7-0-4. Abstain: Christoph, Tullio, Gary, Steve. There are a lot of abstentions, so we ask if there are any particular areas of discomfort. Steve wonders if the additional complexity if worth it. Tullio says he doesn’t understand it well enough to vote to approve it.
We are only working on the third alternative.
No action: 8-0-0.
Tucker is asked why this version does not mention Swap. He explains that Move is used regularly, and Swap is a very special case used rarely. Some of the issues with Swap were getting in the way of defining Move, so it should be done differently (if at all).
Tucker notes that Move now works on more than just optional objects. Move is now defined to work on any type with an implicit initial value. It now leaves behind the implicit initial value; Move does a shallow copy when possible.
Steve asks if you can use this on a private type that you can’t see what is going on inside of it. Yes, so long as it has an implicit initial value.
Randy was asked why he thinks this is unsafe. He says that anything that changes an object in place is unsafe relative to not changing an object. (Assignment itself it unsafe; if it can be avoided by creating a new object, that is preferable when it is practical.) This is more unsafe than assignment because it modifies two objects rather than just one. He has many examples of problems caused by modifying objects that were by-reference parameters. Tucker notes that this is a rather general issue not that specific to Move. Randy agrees, but Move makes things “more bad” which is the wrong direction for Ada.
Randy also notes that this definition of Move will often require an expensive deep copy, which is probably not what is intended (for instance, when the storage pools of the objects are different). The expense is worse as the operation will have to be able to do both shallow and deep copies, choosing one at runtime, because it isn’t possible in general to determine the storage pool of an object at compile-time (think in out parameters passed by reference, as large objects almost always are). The operation as defined is more complex than simple assignment (which is not simple at all!), not the cheap operation that is typically desired. [Editor’s note: Move typically is used because a deep copy is too expensive or not allowed at all (for limited types), otherwise simple assignment and a following change to the source is clearer. Having it do a deep copy anyway is not helpful in those cases.]
The Storage_Pool aspect and attribute has been extended to all objects. The wording isn’t very clear that the attribute has been extended. By extending it in this way, it becomes well-defined what it means for the pools of two objects to be the same. And by allowing the pool of an object to be specified to match some other object, we make it more likely that Move will use a shallow copy.
Move requires both the source and target to be variables.
Ed asks if limited types can be moved. That requires the storage pools to be the same, and other restrictions (as only shallow copies make sense in that case). Steve wonders about the setting of the source to the initial value, that seems suspiciously like an assignment. Tucker says it’s not, we always allow creating new limited objects.
Randy notes that every object has an Storage_Pool, including stand-alone objects declared in subprogram scopes. Those pools could possibly allocate memory from the stack frame or from a secondary stack (if an implementation uses such a thing), but they’re still pools.
Approve intent: 8-1-1. Randy opposes. He says that he believes that it should only work on types for which a shallow copy will work. If someone wants a deep copy, they should use regular assignment. Gary abstains.
Randy tries to explain the changes to the AI. He updated the wording so that we have essentially four checking states, and any individual construct can only be in one of those states.
He notes that he added No_Checks. He was considering whether there are any use case for the combination of Suppress and Static_Checks. It seems there might be, as Suppress is a permission and does not necessarily do anything. A unit which was proved outside of Ada (as with SPARK) to have no exceptions probably does not want any code remaining that raises exceptions. After explaining, Tucker suggests calling it No_Dynamic_Checks.
Steve notes that it really means nothing, as any check that would fail is erroneous, which could do anything (including raise an exception).
Someone suggests that Restriction No_Exceptions would handle the suggested use case. It seems to, but the definition doesn’t explain what happens if a check would have failed. That seems out of bounds for this discussion (we’re not fixing that here).
As such, the No_Checks doesn’t provide any additional functionality, so we don’t want it. We should have an AARM note pointing at No_Exceptions. [Editor’s note: Actually, this would be best written as a “Usage” note, as it is aimed at Ada users, not Ada implementers and language lawyers.]
The use of “relaxed” in the language design note isn’t quite right. The distinction is between “portable” and “smarter but not portable”.
Tucker would like to put Unsuppress and Dynamic_Checks together in the wording. He doesn’t like the implication that Dynamic_Checks is second class. Randy didn’t do that because we would end up with four phrases “pragma Unsuppress and Dynamic_Checks” (or maybe “or” in some cases), and that would make the other wording harder to read. Tucker volunteers to try to reword the paragraph to make it more readable.
We talk about splitting the AIs. Should we approve the base AI? We decide to look at it again after rewording (even though the changes will be minimal).
We will split into three AIs: (1) Static_Checks; (2) General rules for basic flow analysis; (3) Some specific checks (at least Null_Check, Index_Check, and Range_Check). Jeff asks if Discriminant_Checks are intended to be included as well. Yes, we may eventually want more checks as well. Randy will create the initial versions of these AIs, and then next time we can considering handing off some of them to others.
Approve intent: 9-0-2. Christoph, Brad abstain.
Steve explains the changes. The term “implicative aspect” is defined.
We look at the implications a bit, Tucker is eventually satisfied.
We remove the redundant statement from Global as it doesn’t seem relevant.
Christoph is concerned which “if” is referred to at the end of 8.3(12.3/5). The sentence is reworded.
Approve AI with changes: 11-0-0.
Tucker explains the AI. The basic idea is to allow any type to be recursive so long as the default value of the type is not recursive.
We look at the JSON example to explain how that would work in practice.
Steve asks about Component_Size in this JSON example. Tucker notes that we have a problem with Size for unconstrained and recursive types, but that issue seems associated with AI22-0148-2 and should be addressed there. And that would inform the value of Component_Size.
Steve asks if the Direct_IO restriction is enforced at compile-time, or runtime. Randy says Janus/Ada raises Use_Error in this case (when the type is not contiguously represented). This was a question he never asked the ARG because he didn’t necessarily want to know the answer (he might not like it).
Tucker thinks that Randy’s implementation would be OK. One could also put something in the private part of Direct_IO that would be rechecked such that it caused the instantiation to fail for a non-contiguous type. Randy notes that his experience with the ACATS is that compilers mostly implement the instance rechecking that is tested in the ACATS and little more. So it is unclear such a strategy would actually work in practice. In any case, but we should be more explicit as to what the intent is.
Tucker tries to update “current instance” to not have a subtype name be treated as an object in contexts where it cannot possibly be an object, specifically in a subtype_indication.
Randy wants some explicit notation of components that are recursive (not necessarily all of them, just one in each recursive chain); he doesn’t understand how a compiler could tell that an indirection is needed for mutually recursive types. Tucker claims that is possible without any explanation. [Editor’s note: While possible in the abstract, this looks like a combinatorial explosion, requiring examining all subcomponents to see if they are recursive, and doing that recursively on composite types. Plus such code would have to be careful to avoid going into an infinite recursion on other recursive types.]
Randy also notes that a user might want a shallow move, they need indirection for that to work. Niklas dubbed these “referential” components. Embedded users might want to avoid indirection as well, or control precisely where it occurs.
Ed suggests having ‘Type attribute to avoid recursive naming issues. We’ve looked at similar attributes before but they caused semantic troubles. Steve worries that such an attribute makes it possible to name anonymous types, which is new and potentially causes trouble.
Keep alive: 8-0-0.
Randy wonders if we should look at a more significant change. The notion of a constraint for a type with no discriminants at all, or worse, for unconstrained objects, is confusing.
Bob thinks that the changes would be widespread, and the problem isn’t sufficiently severe.
The discussion continues for a while, and then we spend more time designing and explaining a straw poll.
Straw poll: Word replacement: 8 More significant scan 4.
Straw poll on which word (vote for one): Null ; 1; Empty: 9; Nonexistent: 1.
Tucker suggests making a separate AI about the question of “constrained partial view”. Randy will take this as an action item.
Randy says that the AI as proposed is essentially the word replacement version. We wonder if we want to see it again (with an updated discussion). We decide to let the editor update the AI as suggested.
Approve AI with changes: 10-0-1. Richard abstains.
Tucker explains the proposed attribute.
Approve intent: 10-0-1. Justin abstains.
Justin explains that this is already provided by GNAT.
We turn to the questions raised by the various comments in the AI.
(1) All scalars or just enumerations? Randy notes that it could not be used with a generic formal type if it does not at least work for all discrete types (since we do not have an enumeration formal type). We agree that this needs to work for all scalars.
(2) Interaction with Discard_Names. We study the definition of Discard_Names. We conclude that it doesn’t affect this AI, as this AI is written relative to the definition of Value.
(3) Valid_Wide_Value, etc.? Yes, we want these, it would be bizarre not to have them. The names should be Valid_Wide_Value, and not Wide_Valid_Value. We also need versions for type Text (we defined Text_Image and Text_Value in AI22-0161-2).
Bob says “more proof that nothing is simple”.
Valid_Wide_Value is determined in terms of Wide_Value, not Valid_Wide_Wide_Value. We noticed that each of Value, Wide_Value, and Wide_Wide_Value are defined separately, not in terms of each other, for enumeration types. That was done to deal with characters in identifiers that are not representable as Characters (or Wide_Characters).
Approve intent: 11-0-0.
Randy explains how this previous proposal works.
Randy notes that conformance and static matching don’t quite work here, but that is the basic idea. We will need an enhanced version of conformance, or perhaps a different concept to use in static matching, for this to work as intended (as conformance and static matching do not work for different types).
[Randy notes after the meeting that he explained the problem with conformance incorrectly. He will attempt to explain it correctly here. Ada requires that overriding dispatching routines be subtype conformant with the inherited dispatching routine that is overridden. Subtype conformance requires that the subtypes of each parameter of the inherited and overriding routines statically match. The proposal enhanced static matching to use conformance of class-wide predicate expressions to ensure that they match appropriately; this is necessary as overridden routines need explicitly declared subtypes in order to be declared. Expression conformance doesn’t quite work, not for the reason mentioned at the meeting (the types are the same, the two subtypes have the same type), but rather that conformance requires use of the same declarations. But the anonymous subtype created for the inherited routine (3.4 calls this the “corresponding subtype”) uses only inherited declarations for the calls in its predicate, while the new (locally explicitly defined) subtype may use overridden declarations (if there are any) for the calls in its predicate. Given the rules for tagged operations, these will ultimately call the same body, so they will have the same effect, but they technically do not conform. We fixed a related problem with conformance in AI22-0138-1, and a slight extension of that fix would allow conformance to work here. Ergo, this is not a significant problem.]
Tucker worries that this is rather a lot of work for the savings. He notes that we have stable properties for a similar goal. Randy notes that Stable_Properties eliminates redundant postconditions, this is for eliminating redundant preconditions (and postconditions for in out parameters).
The problem seems real (redundant preconditions) and worth a solution.
The suggestion is to post a summary of this proposal on the Github and explore for better solutions. Randy is given an action item to do that. [Tucker did so before Randy could, however – Editor.]
Keep Alive: 8-0-3. Jeff, Justin, Christoph abstain.
AdaCore has a proposal that is largely implemented. Tucker and others think it is important to have an AI; they believe that this is a valuable feature.
Randy notes that we have to have someone volunteer to write an AI, and Tucker is overloaded and should not take on any more large projects until some of the others are completed.
Tucker suggests that Ronan help Steve write up this AI.
Steve reluctantly agrees to take this AI.
Steve asks whether other loop contexts should also allow parallel execution? We look at the loop contexts that exist, and the only ones that don’t support parallel now are aggregates and quantified expressions.
Randy notes that if you have a quantified expression of (for example) Is_Sorted that applies to an array of 100_000 elements, you might very well want to do it in parallel.
Tucker says that a quantified expression is essentially a reduction, and those can be done in parallel. So the implementation shouldn’t be more difficult than a parallel reduction, which the language already has.
We ought allow all of these things, but isn’t particularly important.
If there is a champion that wants to do it (this was originally Brad’s issue, and he is not here), then we would consider it. Otherwise, we will leave it in limbo. The editor is directed to ask Brad whether he wants to write it up. [Editor’s reminder: AI12-0349-1 was created for this issue; it contains an extensive proposal section but no wording.]
No one is interested in the various ideas to merge representations and type declarations: it just doesn’t save enough.
Unordered enumerations are interesting, but they pose challenging compatibility and definitional problems (without ordering, one cannot have ranges either, which makes dealing with constraints problematic).
Randy says that the only thing he would do would be to eliminate the requirement to have the position numbers and representation numbers in the same order. That is limiting and only marginally helps the implementation. (Comparisons would have to use position numbers rather than representations, but all compilers have conversions between representations and position numbers, and probably already use those for range checks.)
Ed and Tucker both agree that would be worthwhile.
But there isn’t a lot a people asking for this, so it doesn’t seem important enough to do now.
The editor is directed to close, we didn’t consider this important at this time.
We think we should vote to close: 8-0-0.
Steve says the wording needs to be tightened up. Randy suggests he write up the tightening of the wording, since he seems to understand the issues.
Steve will create such an AI.
Tucker notes that his ideas here are based on Parasail (which has no pointers). There is value to being able to iterate over a recursive data structure. Without some sort of iteration mechanism, one has to write small, dedicated recursive functions to do operations like searching. That puts some of the code out of line, which increases the difficulty of understanding how it works.
Steve and Randy find for ... while together bizarre. Randy says he would have used exit in this sort of case. Steve says he would have just used if ... then null, since the iteration would stop if no do is executed. There is something weird about that as well; usually when you get to the end of a loop, you go back to the top, whether you have moved your location or not. We wonder if reaching the end of the loop without a do should even be allowed. Steve says it could raise Program_Error if that happens. [Editor’s note: That can be justified by saying that an infinite loop of this kind is an obvious bug, and the way we report runtime detection of bugs in Ada is to raise Program_Error. If we did that, then an explicit exit or while would be needed.]
Tucker says that do loop is essentially continue as used in some other languages, but he didn’t want to use a new reserved word.
Randy notes that an of iterator could be used for this, but that would require writing a small subprogram to advance the element. Tucker’s purpose here was to avoid writing small recursive subprograms, so turning that into a small non-recursive subprogram doesn’t seem to have gained much.
We direct Tucker to explore this further and create an AI.