!standard 1.3.1(6/5)                                        23-07-10  AI22-0033-1/03

!standard 1.3.3(1/5)

!class presentation 23-03-23

!status Corrigendum 1-2022  23-07-10

!status work item 23-07-14

!status ARG Approved  9-0-0  23-06-12

!status work item 23-03-23

!status received 23-03-23

!priority Very_Low

!difficulty Easy

!subject Additional terms and definitions


Define additional terms as needed.


A number of important terms are missing from the Terms and Definitions sections. We should add more, and possibly reorganize some that we already have.


(See Summary.)


Add after 1.3.1(6/5):

allocator.  expression that allocates[a][b] and initializes an object and yields an access value that designates it.

Add after 1.3.1(20/5):

declarative region.  portion of the program that includes the text of a construct together with the text where nested declarations can occur.

Add after 1.3.1(21/5):

denotes.  identifies an object, subprogram, declared entity, or attribute thereof[c][d].

derivation class.  set of a root type and all types derived from it.

Add after 1.3.1(26/5):

designates.  refers to an object or subprogram via an access value.

Add after 1.3.1(73/5):

statically denotes.  denotes (an attribute of) a declaration directly, or through a renaming.

statically names.  statically denotes an object, or a subcomponent of a statically denoted object where any selectors denote subcomponents that are not discriminant-dependent, and any indexing is statically within static bounds.

Add after 1.3.2(1/5):

homograph.  declaration with the same name and, if overloadable, a type conformant parameter (and result) profile.

overloaded.  property of a declaration whose name is shared with other declarations in the same declarative region.

Add after 1.3.3(1/5):

child unit.  library unit (logically) occurring within the declarative region of another  library unit.

Add after 1.3.3(15/5):

instantiation.  creation of an actual package or subprogram from a (template) generic unit.

Add after 1.3.3(23/5):

operative constituent. one of the expressions within an enclosing expression whose evaluation yields  the value  of that enclosing expression.

Add after 1.3.3(36/5):

subsystem. root library unit, together with its descendants.

[Author’s note: 10.1(4) uses the rather clumsy "children and grandchildren and so on", maybe considering that the term "descendants" is only applicable to types.  But 10.1.1(11 & 12) is quite happy talking about library units having descendants.]

Add before 1.3.5(1/5):

bounded error.  error that causes behavior that is not generally predictable but within specified bounds.

Add after 1.3.5(1/5):

erroneous execution.  unpredictable runtime behavior, without specified bounds, caused by an error that is not generally detectable.


We consider the Terms and Definitions section the place to define short, descriptive definitions. The lengthy, formal definitions are placed in the body of the Reference Manual as it would be impossible to meet the rules on writing definitions (see below) for the formal definitions. More on this can be found in the AARM Notes for subclause 1.3.

Terms and Definitions should be defined as required by the JTC1 Directives, Part 2. Some highlights for this purpose:


A number of candidate terms were noted during the FDIS updates. We did not add more of these at the last minute in fear of making trouble for ourselves; we limited ourselves to terms/definitions that needed to be fixed because of ISO comments.

Terms that are mentioned in existing definitions or notes but not defined:

Other important terms that probably ought to be defined include:[e][f]

and a number of visibility terms:

Other candidates can be found by skimming through the index (all defined terms should appear in the index).

If the "other constructs" category gets too large, it might make sense to splitting it into a "units" and "other constructs" categories.

!ACATS test

This is purely additional informative material, so no tests are needed.


From: Randy Brukardt

Sent: Friday, July 14, 2023  4:19 AM

I believe that AI22-0033-1 as approved is incomplete and several of the proposed definitions are problematic. My original idea was to treat the corrections as editorial reviews, but since some of the definitions ought to be reworded in my opinion, that is probably too much of a leap (especially with an AI for which there is no rush to complete, as it does not change anything that a compiler or user would do).

I'm asking here since Tucker's original reaction to my initial comments (see the AI in the Google Docs) was to essentially say that there is nothing wrong. As such, I don't know if there is enough support to reopen and thus am asking here.

Note that our formal procedure to reopen an AI is to ask for a letter ballot on the AI. I'd rather avoid that as there is significant administrative work with doing that (but I'm prepared to follow the procedure if people want that).

Anyway, following are my detailed objections to the AI as approved:

(1) The original intent was that this AI would remain open until we had defined all of the terms that seem important. Tucker had suggested several additional terms that he felt we should define, and I don't understand why those were dropped on the floor. At a minimum we should be making a conscious decision to not define suggested terms (and if that occurred, then remove the suggestions from the AI).

(2) The definition of "allocator" says that it "allocates" an object. That's not a very helpful statement by itself, as it is similar to saying that a "driver" "drives". During the meeting, my understanding was that the wording was going to be updated to say something about the object being allocated from a storage pool. (My notes and thus the minutes say that is the case.) Had I realized that that had not happened, I would have objected to approving the AI (I couldn't see the actual wording changes during the meeting, as my laptop was open to my meeting notes and having Zoom usefully open is impractical).

Tucker objected to my suggestion to use the defined term of "storage pool object", referencing a definition somewhere in Chapter 13. But the T&D clause has to be self-contained, it cannot use definitions from the main body of the Standard. The only term defined in the T&D is "storage pool object", and thus we either have to use that in the wording (I suggested a rewrite that would make that work) or we have to add a term "storage pool"

to the T&D. If Tucker wants to do that latter, then we certainly have to reopen the AI, and otherwise we need to redo the definition more on the lines I suggested. The way it currently reads does not help a reader.

(3) The definition for "denotes" is "identifies an object, subprogram, declared entity, or attribute thereof". I objected to the "thereof", since I have no idea what the "thereof" is supposed to refer to. Tucker replied that it had something to do with the attribute, which I truly do not understand

-- I surely have never heard of an "attribute thereof" in any context.

More generally, I don't believe that this definition is helping any reader whatsoever. The intent of the T&D clause (as we're interpreting it, since the requirements on definitions prevent them from being used in a formal way for any programming language -- the ban on recursion, the requirement of a single sentence, and the impossibility of using any terms defined elsewhere prevent any formal definitions as we understand them) is that the definitions are to help comprehension of RM text. I fail to see how this definition improves on the plain English meaning of the word (especially as we're not trying to have formal definitions here).

Finally, every definition is supposed to be substitutable for the term in question. The proposed definition does not work that way, certainly not in common uses such as the Legality Rule:

         A foobar shall denote an object.

Substituting the above definition gives:

         A foobar shall identify an object, subprogram, declared entity, or attribute thereof an object.

which is unreadable nonsense. We need a very different form of definition for verbs than we have generally used (and one which escapes me,

unfortunately) in order to meet the JTC1 requirements for these definitions.

(This problem most likely occurs for other existing definitions as well, not sure just how seriously to take that requirement.)

For all of these reasons, I believe that we need to reopen the AI and properly wordsmith these definitions. (This AI is exhibit A as to why we shouldn't spend more than a minute or two wordsmithing at a meeting - any wording subject to the Directives needs more careful thought than occurs in a hurry. Changing a verb, reordering some of the text, or similar simple changes make sense, anything more complex is as likely to have omitted something important.)


From: Tucker Taft

Sent: Friday, July 14, 2023  7:05 AM

I am fine with reopening the AI.  Creating a relatively complete and concise set of definitions that are consistent with the ISO rules will probably continue for a long period of time, so I suggest we create a spreadsheet or equivalent with words probably worth including, and then create a continuing series of AIs where each includes a group of definitions we have approved, leaving out any problematic ones for some future AI in the series.  If someone objects to a particular definition, we should just but it on the backlog and then approve the uncontroversial ones.  This way at least we will make some progress.


From: Jeff Cousins

Sent: Friday, July 14, 2023  4:06 PM

I’d be happy to re-open, I don’t think we had time to fully consider all of the updated definitions.  Though re 1), I thought that the mood at the meeting was that 0033 would just be the first of a number of AIs to add definitions.


From: Edward Fish

Sent: Sunday, July 16, 2023  6:21 PM

> (3) The definition for "denotes" is "identifies an object, subprogram,

> declared entity, or attribute thereof". I objected to the "thereof", since I

> have no idea what the "thereof" is supposed to refer to. Tucker replied that

> it had something to do with the attribute, which I truly do not understand

> -- I surely have never heard of an "attribute thereof" in any context.

I would read that "or attributes thereof" as referring to attributes of the object/subprogram/declared-entity. (Thus you could say that Add'Address is identifying the attribute "address" of the subprogram Add, thereby denoting it.)


From: Jeff Cousins

Sent: Monday, July 17, 2023 12:01 PM

That’s what I would have assumed, I was wondering whether Randy was concerned about not all “entities” having attributes, though “entity” seems too vague term for this to matter.


From: Randy Brukardt

Sent: Monday, July 17, 2023  2:05 PM

I didn't understand why one would want to say more than that it might identify an attribute -- this is not a formal definition and too much detail is more distracting than helpful. And I never made the connection that the "thereof" is supposed to associate with the other items in this list. It would have seemed that "attribute of a declared entity" would have worked as well if we wanted that level of detail (the prefix of an attribute cannot be anonynous).


But as I noted elsewhere, this definition doesn't work as a substitution, so we probably ought to reconsider the form anyway. Which makes this moot.


From: Jeff Cousins

Sent: Tuesday, July 18, 2023  11:51 AM

The definition of “statically names” sticks out like a sore thumb as being too long to readily be substitutable.  But I’m afraid I haven’t any suggestion for anything shorter that is still technically correct.


[a]Editorial review: The minutes say that Tucker wants this to "allocate from a storage pool". So where is the storage pool in this definition?? "Storage pool object" is a defined term. I think this should say "allocates from a storage pool object", or maybe something like "expression that creates an object by allocating it from a storage pool object, initializing it, and then yields an access value the designates the new object".

[b]"Storage pool" is defined in 13.11(1, 2/2).  "Storage pool object" is an awkward term, in my view.  Nowhere does the RM use the phrase "allocate from a storage pool object" as far as I know.

[c]Editorial review: Is this word necessary? The definition is supposed to be substitutable for the term, and this word would make any such text clunky. And it doesn't really seem to add anything.

[d]The term "thereof" is appropriate because a name denotes an attribute *of something*.

[e]Root type of a class-wide type

[f]subtype predicate?