Version 1.1 of ai12s/ai12-0447-1.txt

!standard 13.11(21) 22-11-30 AI12-0447-1/01

Reword some notes.

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

[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”.]

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.

No ASIS effect.

These are just notes, no tests are needed.

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