!standard 13.11(21)                                    22-11-30  AI12-0447-1/01
!standard 13.11.4(21/3)
!standard 13.11.4(31/3)
!class presentation 22-11-30
!status work item 15-06-04
!status received 15-04-28
!priority Low
!difficulty Easy
!subject More rewordings of notes
!summary

Reword some notes.

!question

The JTC1 Directives, Part 2, do not allow text that reads like a requirement or
recommendation in Notes or Examples.

!recommendation

(See Summary.)

!wording

[Editor's note: The ISO editors flagged the phrases noted in square brackets.
In some cases, I've included possible rewordings. We need to develop wording
for all.]

[Editor's note: I have not yet tried to find the paragraph numbers for these
notes. I'll do that before these are processed. The subclause number and note
number should be sufficient for finding them in Draft 34 of Ada 2022 RM.]

In 3.9:

NOTE 3   Class-wide types are defined to have unknown discriminants (see 6.7).
This means that objects of a class-wide type have to be explicitly initialized
(whether created by an object_declaration or an allocator), and that aggregates
have to be explicitly qualified with a specific type when their expected type
is class-wide.

[“have to be”, twice. The fact that the language requires these (elsewhere)
seems important, it’s not a statement of fact. Don't see any allowed rewording;
we've already clearly marked that we are talking about a consequence and they
still are not happy. Probably have to delete this one.]

In 3.9.1:

NOTE 3   A name that denotes a component (including a discriminant) of the 
parent type is not allowed within the record_extension_part. Similarly, a 
name that denotes a component defined within the record_extension_part is 
not allowed within the record_extension_part. It is permissible to use a 
name that denotes a discriminant of the record extension, providing there 
is a new known_discriminant_part in the enclosing type declaration. (The 
full rule is given in 6.8.) 

[“It is permissible”. Could we use “can” or “it is possible” here? This isn’t
talking about a permission anyway.]

NOTE 4   Each visible component of a record extension has to have a unique 
name, whether the component is (visibly) inherited from the parent type or 
declared in the record_extension_part (see 11.3). 

[“has to be”. The fact that the language requires this (elsewhere) seems 
important, it’s not a statement of fact.]

In 3.9.3:

NOTE 1   Abstractness is not inherited; to declare an abstract type, the 
reserved word abstract has to be used in the declaration of the type
extension. 

[“has to be”. The fact that this is necessary is the point, don’t see any 
allowed language. Probably have to delete this one from the ISO version
(this one was not previously reworded).]

In 3.10.1:

NOTE 1   Within a declarative_part, an incomplete_type_declaration and a 
corresponding full_type_declaration cannot be separated by an intervening
body. This is because a type has to be completely defined before it is 
frozen, and a body freezes all types declared prior to it in the same 
declarative_part (see 16.14).

[“has to be”. The fact that the language requires this (elsewhere) seems
important, it’s not a statement of fact.]

In 4.1.2:

NOTE 1   A slice is not permitted as the prefix of an Access 
attribute_reference, even if the components or the array as a whole are
aliased. See 6.10.2. 

[“is not permitted”. Perhaps impossibility would be better? “cannot be used 
as the prefix”.]

In 4.1.4:

NOTE 2   In general, the name in a prefix of an attribute_reference (or a
range_attribute_reference) has to be resolved without using any context. 
However, in the case of the Access attribute, the expected type for the 
attribute_reference has to be a single access type, and the resolution of
the name can use the fact that the type of the object or the profile of 
the callable entity denoted by the prefix has to match the designated type
or be type conformant with the designated profile of the access type. 

[“has to be”, three times. Again, the fact that the language requires this
seems important.]

In 4.3.1:

NOTE   For a record_aggregate with positional associations, expressions 
specifying discriminant values appear first since the known_discriminant_part
is given first in the declaration of the type; they have to be in the same
order as in the known_discriminant_part. 

[“have to be”. This is clearly talking about a language requirement
(given elsewhere).]

In 4.3.2:

NOTE 1   If all components of the value of the extension_aggregate are 
determined by the ancestor_part, then the record_component_association_list
is required to be simply null record.

[“is required to be”; this is talking about a requirement imposed (on 
programmers) by rules in 7.3.1. We could easily add that, but the “is 
required to be” (or some equivalent) would remain. (Saying it is a 
“statement of fact” makes no sense; the programmer surely could write
other things, they just wouldn’t be legal.) We may have to delete this one.]

In 9.7.1:

NOTE   A selective_accept is allowed to have several open delay_alternatives.
A selective_accept is allowed to have several open accept_alternatives for
the same entry.

[“is allowed to” (twice). “can” would appear to work here (certainly for the first one).]

In 10.2.1:

NOTE 1   A preelaborated library unit is allowed to have nonpreelaborable children. 
NOTE 2   A library unit that is declared pure is allowed to have impure children. 

[“is allowed to” (twice). “can” would appear to work here.]

In 12.1:

NOTE 3   A default_expression or default_name appearing in a 
generic_formal_part is not evaluated during elaboration of the
generic_formal_part; instead, it is evaluated when used. (The usual visibility
rules apply to any name used in a default: the denoted declaration therefore
has to be visible at the place of the expression.) 

[“has to be”. As with 3.9.3, this is the point, and it is unclear of any 
allowed wording could be used. We could try “must”, or just delete the note.]

In 12.5.2:

NOTE 2   If the formal has a discriminant_part, the actual can be either 
definite or indefinite. Otherwise, the actual has to be definite. 

[“has to be”. Probably should be rewritten in terms of rules given previously, or dropped.]

In 13.11.4:

NOTE 1   A user-defined storage pool type that supports subpools can be 
implemented by extending the Root_Storage_Pool_With_Subpools type, and overriding
the primitive subprograms Create_Subpool, Allocate_From_Subpool, and
Deallocate_Subpool. Create_Subpool is expected to call Set_Pool_Of_Subpool
before returning the subpool handle. To make use of such a pool, a user can
declare an object of the type extension, use it to define the Storage_Pool
attribute of one or more access types, and then call Create_Subpool to
obtain subpool handles associated with the pool.

[“use it” was highlighted here, without comment. “can” applies to all of these here, 
maybe we have to be explicit “can declare”, “can use it”, “can call”?? That seems 
like bad English, but maybe good Standard-speak?]

In C.3:

NOTE 1   The default treatment for an interrupt can be to keep the interrupt 
pending or to deliver it to an implementation-defined handler. Examples of 
actions that an implementation-defined handler is allowed to perform include
aborting the partition, ignoring (i.e. discarding occurrences of) the
interrupt, or queuing one or more occurrences of the interrupt for possible
later delivery when a user-defined handler is attached to that interrupt.

[“is allowed to”. This probably should simply say “can”.]

In D.3:

NOTE 3   The ceiling priority of a protected object has to be in the 
Interrupt_Priority range if one of its procedures is to be used as an
interrupt handler (see C.3).

[“has to be”. Probably should refer to “the rules in this subclause require”.]

In D.5.2:

NOTE 4   The rule for when Tasking_Error is raised for Set_Priority or 
Get_Priority is different from the rule for when Tasking_Error is raised on an 
entry call (see 12.5.3). In particular, querying the priority of a completed or
an abnormal task is allowed, so long as the task is not yet terminated, and
setting the priority of a task is allowed for any task state (including for
terminated tasks).

[“is allowed” (twice). Perhaps turn this around to use “can”?]

In H.3:

NOTE 1   The implementation is not allowed to perform “dead store elimination” 
on the last assignment to a variable prior to a point where the variable is 
inspectable. Thus an inspection point has the effect of an implicit read of 
each of its inspectable objects.

[“is not allowed”. Probably need to refer to “rules in this subclause” or something like that.]

NOTE 3   The identification of the mapping from source program objects to 
machine resources is allowed to be in the form of an annotated object listing,
in human-readable or tool-processable form. 

[“is allowed to be”. Probably just should use “can”.]

!discussion

The ISO editors flagged all of these phrases.

The ISO editors did not flag text that talks about rules given elsewhere. We
should be allowed to say something like "The rules of this subclause require"
or "The rules of 7.8 prevent" (although we should try to avoid words like
require when possible).

Most of these notes do not make sense as simple statements of fact, since the
point is that we (in this document) are requiring these facts. Otherwise, they
would appear mysterious.

!ASIS

No ASIS effect.

!ACATS test

These are just notes, no tests are needed.

!appendix

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