Version 1.6 of ai12s/ai12-0445-1.txt
!standard 3.2(8) 22-05-25 AI12-0445-1/05
!standard 3.4.1(6/2)
!standard 3.10.2(20)
!standard 5.5.3(21/5)
!standard 5.5.3(27/5)
!standard 5.5.3(28/5)
!standard 5.5.3(29/5)
!standard 6.1.2(18/5)
!standard 7.6.1(16/2)
!standard 9.6.1(82/2)
!standard 9.8(20/3)
!standard 10.1.1(24)
!standard 10.1.4(2)
!standard 11.1(6)
!standard 11.4.2(26/3)
!standard 12.5.1(1/3)
!standard 13.1(7/2)
!standard 13.3(37/2)
!standard 13.3(55)
!standard 13.3(58.13/5)
!standard 13.6(1/3)
!standard 13.6(2/5)
!standard 13.11(21.6/3)
!standard 13.11(22)
!standard 13.11.2(9/3)
!standard 13.11.3(5.2/4)
!standard 13.11.4(19/3)
!standard 13.13.2(56/3)
!standard 13.13.2(56.1/3)
!standard A.1(51)
!standard A.4.2(1)
!standard A.4.4(1)
!standard A.4.5(1)
!standard A.5.2(29/3)
!standard A.5.2(40.1/1)
!standard A.6(1/2)
!standard A.10.4(1)
!standard A.10.6(7)
!standard A.13(1)
!standard A.18.9(74.2/5)
!standard A.18.9(74.8/5)
!standard A.18.9(74.9/5)
!standard A.18.32(16/5)
!standard B.1(3)
!standard B.3.2(2)
!standard C.3(9)
!standard D.9(12)
!standard D.9(13)
!standard D.15(1/3)
!standard G(4)
!class presentation 22-04-28
!status Amendment 1-2012 22-05-05
!status WG9 Approved 22-06-22
!status ARG Approved 14-0-0 22-05-05
!status work item 22-04-28
!status received 22-02-18
!priority Critical
!difficulty Medium
!subject Rewordings of normative material
!summary
A large number of paragraphs need to be reworded.
!question
ISO comment #20 says:
Verbal forms used to express provisions in the text do not always comply
with the rules specified in the ISO/IEC Directives, Part 2. Do not use
verbal forms ("could", "might", "need") that are not defined in the
ISO/IEC Directives, Part 2.
The ISO "House Style" gives further information on this, essentially saying
that they do not care whether the Standard reads well, they are more concerned
with preciseness and lack of ambiguity.
As such, we need to remove any occurrences of those words from any normative
text, and for some things that is complex.
!recommendation
Update the wording as described below.
!wording
Modify 3.2(8):
A /subtype/ of a given type is a combination of the type, a constraint on
values of the type, and certain attributes specific to the subtype. The
given type is called the /type of the subtype/. Similarly, the associated
constraint is called the /constraint of the subtype/. The set of values of
a subtype consists of the values of its type that satisfy its constraint
and any exclusion of the null value. Such values /belong/ to the subtype.
{The other values of the type are /outside/ the subtype.}
[We use "outside" in various notes (see AI12-0442-1), and it is already
(dubiously) used in some Implementation Permissions (3.5.4(24) and
3.5.6(7/5)) - Editor.]
Modify 3.4.1(6/2):
Universal types are defined for (and belong to) the integer, real, fixed
point, and access classes, and are referred to in this {document}[standard] as
respectively, universal_integer, universal_real, universal_fixed, and
universal_access. These are analogous to class-wide types for these
language-defined elementary classes. As with class-wide types, if a formal
parameter is of a universal type, then an actual parameter of any type in
the corresponding class is acceptable. In addition, a value of a universal
type (including an integer or real numeric_literal, or the literal null)
is “universal” in that it is acceptable where some particular type in the
class is expected (see 8.6).
[This is not the correct form for a self-reference to the RM. Prior to 2018,
it should have been "this International Standard", but now "this document"
is sufficient. Use the macro @intlstdname here so we don't have to change
it next time they change their mind on this.- Editor.]
Modify 3.10.2(20):
* For determining whether one level is statically deeper than another
when within a generic package body, the generic package is presumed to
be instantiated at the same level as where it was declared; runtime
checks are {required}[needed] in the case of more deeply nested
instantiations.
[Replace "needed" - Editor.]
Modify 5.5.3(21/5):
Specifying the Parallel_Iterator aspect to be True for a
callable entity indicates that the entity {is allowed to}[might] invoke
the loop body procedure from multiple distinct logical threads of
control. The Parallel_Iterator aspect for a subprogram shall
be statically False if the subprogram allows exit.
["Might" is clearly better that "can" here, so we need a more substantial
rewording. - Editor.]
Modify 5.5.3(27/5):
For the execution of a loop_statement with an iteration_scheme that has a
procedural_iterator, the procedure denoted by the name or prefix of the
iterator_procedure_call (the iterating procedure) is invoked, passing an
access value designating the loop body procedure as a parameter. The iterating
procedure then calls the loop body procedure zero or more times and returns,
whereupon the loop_statement is complete. If the parallel reserved word is
present, the iterating procedure {is allowed to}[might] invoke the loop body
procedure from multiple distinct logical threads of control. The
aspect_specification, if any, is elaborated prior to the invocation of
the iterating procedure.
[See previous item. - Editor.]
Modify 5.5.3(28/5):
If the callable entity identified in the iterator_procedure_call allows
exit, then it is a bounded error for a call of the loop body procedure to be
performed from within an abort-deferred operation (see 9.8), unless the entire
loop_statement was within the same abort-deferred operation. If detected,
Program_Error is raised at the point of the call; otherwise, a transfer of
control from the sequence_of_statements of the loop_statement {will}[might]
not {necessarily} terminate the loop_statement, and the loop body procedure
{can}[might] be called again.
["might not" needs to be replaced by other wording, "cannot" does not have the
same meaning at all - Editor.]
Modify 5.5.3(29/5):
If a loop_statement with the procedural_iterator as its
iteration_scheme (see 5.5) does not begin with the reserved word parallel, it
is a bounded error if the loop body procedure is invoked from a different
logical thread of control than the one that initiates the loop_statement. If
detected, Program_Error is raised; otherwise, conflicts associated with
concurrent executions of the loop body procedure can occur without being
detected by the applicable conflict check policy (see 9.10.1). Furthermore,
propagating an exception or making an attempt to exit in the presence of
multiple threads of control {will}[might] not {necessarily} terminate the
loop_statement, deadlock {can}[might] occur, or the loop body procedure
{can}[might] be called again.
[See previous paragraph for comments - Editor.]
Modify 6.1.2(18/5):
The Global aspect for a callable entity defines the global variables that
{can}[might] be referenced as part of a call on the entity, including any
assertion expressions that apply to the call (even if not enabled),
{such as}[including] preconditions, postconditions, predicates, and type
invariants.
["including" is used twice here, I recommend changing the second one as
marked. It's annoying to re-read wording 'cause one sees mistakes never
before seen. - Editor.]
Modify 7.6.1(16/2):
* For an Adjust invoked as part of assignment operations other than those
invoked as part of an assignment_statement, [other]{some of the}
adjustments due to be performed [might or might not]{can} be performed,
and then Program_Error is raised. During its propagation, finalization
[might or might not]{may} be applied to objects whose Adjust failed. For
an Adjust invoked as part of an assignment_statement, any other adjustments
due to be performed are performed, and then Program_Error is raised.
["might or might not" is doubly bad. "can or cannot" doesn't make much sense.
I thought of using "it is not specified whether other adjustments due to be
performed are actually performed", but that's pretty long (and one would have
to do something similar for the next sentence). Tucker suggested the above
for the first part, but missed the second "might or might not". I wonder if
"may" is better than "can" here (this is normative, so we can use
"may") - Editor.]
Modify 9.6.1(82/2):
Returns a string form of the Date relative to the given Time_Zone.
The format is "Year-Month-Day Hour:Minute:Second", where the Year
is a 4-digit value, and all others are 2-digit values, of the functions
defined in Calendar and Calendar.Formatting, including a leading zero, if
{necessary}[needed]. The separators between the values are a minus,
another minus, a colon, and a single space between the Day and Hour. If
Include_Time_Fraction is True, the integer part of Sub_Seconds*100 is
suffixed to the string as a point followed by a 2-digit value.
[Replace "needed" - Editor.]
Modify 9.8(20/3):
An attempt to execute an asynchronous_select as part of the execution of
an abort-deferred operation is a bounded error. Similarly, an attempt to
create a task that depends on a master that is included entirely within the
execution of an abort-deferred operation is a bounded error. In both cases,
Program_Error is raised if the error is detected by the implementation;
otherwise, the operations proceed as they would outside an abort-deferred
operation, except that an abort of the abortable_part or the created task
{does not necessarily}[might or might not] have an effect.
["might or might not" is doubly bad, "can or cannot" is doesn't have the
right meaning, so I tried the above rewording - Editor.]
Modify 10.1.1(24):
* The semantic dependences (see below) are the ones {necessary}[needed]
to check the compile-time rules across compilation unit boundaries; a
compilation unit depends semantically on the other compilation units
{necessary}[needed] to determine its legality. The visibility rules are
based on the semantic dependences.
[Replace "needed" - Editor.]
Modify 10.1.4(2):
The declarative_items of the environment are library_items appearing in an
order such that there are no forward semantic dependences. Each included
subunit occurs in place of the corresponding stub. The visibility rules
apply as if the environment were the outermost declarative region, except
that with_clauses are {necessary}[needed] to make declarations of library
units visible (see 10.1.2).
[Replace "needed" - Editor.]
Modify 11.1(6):
The execution of any construct raises Storage_Error if there is
insufficient storage for that execution. The amount of storage
{necessary}[needed] for the execution of constructs is unspecified.
[Replace "needed" - Editor.]
Modify 11.4.2(26/3):
If the result of a function call in an assertion is not {used}[needed] to
determine the value of the assertion expression, an implementation is
permitted to omit the function call. This permission applies even if the
function has side effects.
[Replace "needed" - Editor.]
Modify 11.6(6/3):
* If an exception is raised due to the failure of a language-defined
check, then upon reaching the corresponding exception_handler (or the
termination of the task, if none), the external interactions that have
occurred {have to}[need] reflect only that the exception was raised
somewhere within the execution of the sequence_of_statements with the
handler (or the task_body), possibly earlier (or later if the interactions
are independent of the result of the checked operation) than that defined
by the canonical semantics, but not within the execution of some
abort-deferred operation or independent subprogram that does not
dynamically enclose the execution of the construct whose check failed.
An independent subprogram is one that is defined outside the library
unit containing the construct whose check failed, and for which the
Inline aspect is False. Any assignment that occurred outside of such
abort-deferred operations or independent subprograms can be disrupted
by the raising of the exception, causing the object or its parts to
become abnormal, and certain subsequent uses of the object to be
erroneous, as explained in 13.9.1.
[Replace "need" - Editor.]
Modify 12.5.1(1/3):
In its most general form, the category determined for a formal private
type is all types, but the category can be restricted to only nonlimited
types or to only tagged types. Similarly, the category for a formal
incomplete type is all types but the category can be restricted to only
tagged types; unlike other formal types, the actual type [does not need
to be able to be]{can be incompletely defined, and not ready to be} frozen
(see 13.14). The category determined for a formal derived type is the
derivation class rooted at the ancestor type.
[Replace "need to" - Editor.]
Modify 13.1(7/2):
The representation of an object consists of a certain number of bits (the
size of the object). For an object of an elementary type, these are the
bits that are normally read or updated by the machine code when loading,
storing, or operating-on the value of the object. For an object of a
composite type, these are the bits reserved for this object, and include
bits occupied by subcomponents of the object. If the size of an object is
greater than that of its subtype, the additional bits are padding bits.
For an elementary object, these padding bits are normally read and updated
along with the others. For a composite object, {it is unspecified whether}
padding bits {are}[might not be] read or updated in any given composite
operation[, depending on the implementation].
[Have to replace "might not", but "cannot" is wrong and "may not" is not
allowed. - Editor]
Modify 13.3(37/2):
The recommended level of support for the Size attribute of objects is the
same as for subtypes (see below), except that only a confirming Size clause
{is required to}[need] be supported for an aliased elementary object.
[Replace "need". Could use a form of "should" here instead, maybe - Editor.]
Modify 13.3(55):
* The Size (if not specified) of a static discrete or fixed point subtype
should be the number of bits {necessary}[needed] to represent each value
belonging to the subtype using an unbiased representation, leaving
space for a sign bit only if the subtype contains negative values. If
such a subtype is a first subtype, then an implementation should
support a specified Size for it that reflects this representation.
[Replace "needed" - Editor.]
Modify 13.3(58.13/5):
* If S is some other subtype, only confirming specifications of
Object_Size [need]{are required to} be supported.
[Replace "need". Could use a form of "should" here instead, maybe - Editor.]
Modify 13.6(1/3):
A type_conversion (see 4.6) can be used to convert between two different
representations of the same array or record. To convert an array from one
representation to another, two array types [need to be declared] with
matching component subtypes[,] and convertible index types{ are required}.
If one type has Pack specified and the other does not, then explicit
conversion can be used to pack or unpack an array.
[Replace "need to" - Editor.]
Modify 13.6(2/5):
To convert an untagged record from one representation to another, two
record types with a common ancestor type [need to be declared]{are
required}. Distinct representations can then be specified for the record
types, and explicit conversion between the types can be used to effect a
change in representation.
[Replace "need to" - Editor.]
Modify 13.11(21.6/3):
The number of calls to Allocate [needed]{that will be used} to implement
an allocator for any particular type is unspecified. The number of calls
to Deallocate [needed]{that will be used} to implement an instance of
Unchecked_Deallocation (see 13.11.2) for any particular object is the same
as the number of Allocate calls for that object.
[Replace "needed" - Editor.]
Modify 13.11(22):
An implementation shall document the set of values that a user-defined
Allocate procedure [needs]{has} to accept for the Alignment parameter. An
implementation shall document how the standard storage pool is chosen, and
how storage is allocated by standard storage pools.
[Replace "needs". "Has" should be OK here, as this is already a requirement - Editor.]
Modify 13.11.2(9/3):
c) Free(X), when X is not equal to null first performs finalization of
the object designated by X (and any coextensions of the object - see
3.10.2), as described in 7.6.1. It then deallocates the storage
occupied by the object designated by X (and any coextensions). If the
storage pool is a user-defined object, then the storage is deallocated
by calling Deallocate as described in 13.11. There is one exception:
if the object being freed contains tasks, {it is unspecified whether}
the object {is}[might not be] deallocated.
[Have to replace "might not", but "cannot" is wrong and "may not" is not
allowed. - Editor]
Modify 13.11.3(5.2/4):
Otherwise, the expected type for the Default_Storage_Pool aspect is
Root_Storage_Pool'Class and the aspect_definition shall be a name that
denotes a variable. This aspect overrides any Default_Storage_Pool pragma
that {applies}[might apply] to the generic unit; if the aspect is not
specified, the default pool of the instance is that defined for the
generic unit.
[We don't need "might" here, as we already have "any" to say that there doesn't have
to be one. So we can just use "applies". - Editor]
Modify 13.11.4(19/3):
A subpool object is an object of a type descended from Root_Subpool.
Typically, subpool objects are managed by the containing storage pool; only
the handles [need]{have to} be exposed to clients of the storage pool.
Subpool objects are designated by subpool handles, and are the run-time
representation of a subpool.
[Replace "need" - Editor.]
Modify 13.13.2(56/3):
The number of calls performed by the predefined implementation of the
stream-oriented attributes on the Read and Write operations of the stream
type is unspecified. An implementation may take advantage of this
permission to perform internal buffering. However, all the calls on the
Read and Write operations of the stream type [needed]{used} to implement
an explicit invocation of a stream-oriented attribute shall take place
before this invocation returns. An explicit invocation is one appearing
explicitly in the program text, possibly through a generic instantiation
(see 12.3).
[Replace "needed" - Editor.]
Modify 13.13.2(56.1/3):
If T is a discriminated type and its discriminants have defaults, then
in two cases an execution of the default implementation of S'Read is not
required to create an anonymous object of type T: If the discriminant
values that are read in are equal to the corresponding discriminant values
of Item, then {creation of a new} [no] object of type T [need be created]
{may be bypassed} and Item may be used instead. If they are not equal and
Item is a constrained variable, then Constraint_Error may be raised at that
point, before any further values are read from the stream and before the
object of type T is created.
[Replace "need be" - Editor.]
Modify A.1(51):
An implementation may provide additional predefined integer types and
additional predefined floating point types. [Not]{Some or} all of these
types [need have names]{may be anonymous}.
Modify A.4.2(1):
The package Strings.Maps defines the types, operations, and other entities
{necessary}[needed] for character sets and character-to-character mappings.
[Replace "needed" - Editor.]
Modify A.4.4(1):
The language-defined package Strings.Bounded provides a generic package
each of whose instances yields a private type Bounded_String and a set of
operations. An object of a particular Bounded_String type represents a
String whose low bound is 1 and whose length can vary conceptually between
0 and a maximum size established at the generic instantiation. The
subprograms for fixed-length string handling are either overloaded
directly for Bounded_String, or are modified as {necessary}[needed] to
reflect the variability in length. Additionally, since the Bounded_String
type is private, appropriate constructor and selector operations are
provided.
[Replace "needed" - Editor.]
Modify A.4.5(1):
The language-defined package Strings.Unbounded provides a private type
Unbounded_String and a set of operations. An object of type Unbounded_String
represents a String whose low bound is 1 and whose length can vary
conceptually between 0 and Natural'Last. The subprograms for fixed-length
string handling are either overloaded directly for Unbounded_String, or are
modified as {necessary}[needed] to reflect the flexibility in length. Since
the Unbounded_String type is private, relevant constructor and selector
operations are provided.
[Replace "needed" - Editor.]
Modify A.5.2(29/3):
An object of the private type State can be used to hold the internal
state of a generator. Such objects are only {necessary}[needed] if the
application is designed to save and restore generator states or to examine
or manufacture them. The implicit initial value of type State corresponds
to the implicit initial value of all generators.
[Replace "needed" - Editor.]
Modify A.5.2(40.1/1):
It is a bounded error to invoke Value with a string that is not the
image of any generator state. If the error is detected, Constraint_Error or
Program_Error is raised. Otherwise, a call to Reset with the resulting state
will produce a generator such that calls to Random with this generator will
produce a sequence of values of the appropriate subtype, but which {are}[might]
not {necessarily}[be] random in character. That is, the sequence of values
{do not necessarily}[might not] fulfill the implementation requirements of this
subclause.
[The usual fixes for "might not" don't work here. "Cannot" is too definite (we
don't know that the sequence is bad, just that it might be). We fall back on
the "necessarily" crutch. Tucker had a suggestion that did not replace the
first "might", so it wasn't used - Editor.]
Modify A.6(1/2):
Input-output is provided through language-defined packages, each of which
is a child of the root package Ada. The generic packages Sequential_IO and
Direct_IO define input-output operations applicable to files containing
elements of a given type. The generic package Storage_IO supports reading
from and writing to an in-memory buffer. Additional operations for text
input-output are supplied in the packages Text_IO, Wide_Text_IO, and
Wide_Wide_Text_IO. Heterogeneous input-output is provided through the child
packages Streams.Stream_IO and Text_IO.Text_Streams (see also 13.13). The
package IO_Exceptions defines the exceptions [needed]{used} by the
predefined input-output packages.
[Replace "needed" - Editor.]
Modify A.10.4(1):
The subprograms described in this subclause are concerned with the line
and page structure of a file of mode Out_File or Append_File. They operate
either on the file given as the first parameter, or, in the absence of
such a file parameter, on the current default output file. They provide
for output of text with a specified maximum line length or page length.
In these cases, line and page terminators are output implicitly and
automatically when {necessary}[needed]. When line and page lengths are
unbounded (that is, when they have the conventional value zero), as in the
case of a newly opened file, new lines and new pages are only started when
explicitly called for.
[Replace "needed" - Editor.]
Modify A.10.6(7):
Any Put procedure, for an item of a numeric or an enumeration type,
outputs the value of the item as a numeric literal, identifier, or
character literal, as appropriate. This is preceded by leading spaces if
required by the Format parameters Width or Fore (as described in later
subclauses), and then a minus sign for a negative value; for an
enumeration type, the spaces follow instead of leading. The format given
for a Put procedure is overridden if it is insufficiently wide, by using
the minimum {necessary}[needed] width.
[Replace "needed" - Editor.]
Modify A.13(1):
The package IO_Exceptions defines the exceptions [needed]{used} by the
predefined input-output packages.
Modify A.18.9(74.2/5):
type Set (Base : not null access {Ordered}[Hashed]_Sets.Set) is
tagged limited private
with Constant_Indexing => Constant_Reference,
Default_Iterator => Iterate,
Iterator_Element => Element_Type,
Stable_Properties => (Length),
Global => null,
Default_Initial_Condition => Length (Set) = 0,
Preelaborable_Initialization;
[This is the ordered set package, so we have to refer to Ordered_Sets
here - Editor.]
Modify A.18.9(74.8/5):
procedure Assign (Target : in out {Ordered}[Hashed]_Sets.Set;
Source : in Set)
with Post => Length (Source) = Length (Target);
[This is the ordered set package, so we have to refer to Ordered_Sets
here - Editor.]
Modify A.18.9(74.9/5):
function Copy (Source : {Ordered}[Hashed]_Sets.Set) return Set
with Post => Length (Copy'Result) = Length (Source);
[This is the ordered set package, so we have to refer to Ordered_Sets
here - Editor.]
Modify A.18.32(16/5):
The Implementation Advice about the Move and Swap operations is deleted
for bounded holders; these operations can copy elements as
{necessary}[needed].
[Replace "needed" - Editor.]
Modify B.1(3):
A pragma Linker_Options is used to specify the system linker parameters
{necessary}[needed] when a given compilation unit is included in a
partition.
[Replace "needed" - Editor.]
Modify B.3.2(2):
The generic allows two styles of usage: one in which the array is
terminated by a special terminator element; and another in which the
programmer [needs to keep]{keeps} track of the length.
[Replace "needs to" - Editor.]
Modify C.3(9):
The implementation shall provide a mechanism to determine the minimum
stack space that is {necessary}[needed] for each interrupt handler and to
reserve that space for the execution of the handler. This space should
accommodate nested invocations of the handler where the system permits
this.
[Replace "needed" - Editor.]
Modify D.9(12):
* An upper bound on the lateness of a delay_relative_statement, for a
positive value of the delay expression, in a situation where the task
has sufficient priority to preempt the processor as soon as it becomes
ready, and [does not need to wait]{can proceed without waiting} for any
other execution resources. The upper bound is expressed as a function of
the value of the delay expression. The lateness is obtained by
subtracting the value of the delay expression from the actual duration.
The actual duration is measured from a point immediately before a task
executes the delay_statement to a point immediately after the task
resumes execution following this statement.
[Replace "need to" - Editor.]
Modify D.9(13):
* An upper bound on the lateness of a delay_until_statement, in a
situation where the value of the requested expiration time is after
the time the task begins executing the statement, the task has
sufficient priority to preempt the processor as soon as it becomes
ready, and it [does not need to wait]{can proceed without waiting} for
any other execution resources. The upper bound is expressed as a
function of the difference between the requested expiration time and
the clock value at the time the statement begins execution. The lateness
of a delay_until_statement is obtained by subtracting the requested
expiration time from the real time that the task resumes execution
following this statement.
[Replace "need to" - Editor.]
Modify D.15(1/3):
This subclause describes a language-defined package to allow user-defined
protected procedures to be executed at a specified time without the
[need for]{use of} a task or a delay statement.
[Replace "need for" - Editor.]
Modify G(4):
* a mode ("relaxed mode"), in which {there are} no accuracy or other numeric
performance requirements [need]{to} be satisfied, as for implementations not
conforming to the Numerics Annex;
[Replace "need" - Editor.]
[A number of paragraphs that contain forms of the word "need" and are not
uses of Ada technical terms but that we do not propose to changes can be
found at the start of the !appendix - Editor.]
!discussion
To summarize the ISO rules from the Directives part 2 (often referred to as the
drafting standard):
Requirements use "shall" preferably, or phrases involving forms of "require",
"has to", or "it is necessary". "Must" is not allowed (it can be
used for external requirements, such as government laws, but that usually
doesn't apply to us).
Recommendations use "should" preferably, or phrases involving forms of
"recommend" or "ought to".
Permissions should use "may" preferably, or phrases using forms of "permit" or
"allow". "Might" is not allowed in this context. Negative forms are not
allowed (no "may not"); permissions must be positive. A quote: "Rather than
using negative permissions, either rewrite the sentence to state what is
permitted, or rewrite as a requirement/recommendation not to do something."
Possibility should use "can", or phrases using forms of "able" or "possible".
ISO has taken this further and does not want to see "might", "could", or
"need" at all; they assume that they are being used in one of the above
contexts. I don't know where "need" comes from (other than the "House Style",
but that's not normative), the Directives never mentions it as a word
to avoid, and in fact it uses the word "needs" with the meaning of desires
repeatedly. But the Directives is clear that one should not use any
words other than the above to express requirements, recommendations, or
permissions.
We have a particular problem with "need not", used frequently to get around
not being able to say "may not". That is discussed and handled in
AI12-0444-1. [Editor's note: one case of "could cause" is also in AI12-0444-1,
as all of the related paragraphs use both "need not" and "could cause".]
Note that while some phrases are given meanings, other uses of the words seem
to be allowed by the Directives. For instance, "necessary" is used in many
contexts in the Directives that are not requirements.
We handle occurrences of "must" in AI12-0438-1, and simple changes where some
other word should be replaced by "can" in AI12-0439-1.
The remaining cases are handled in this AI.
---
The editor has created a file that contains just the normative text of the
Standard. In this file, we have the following number of occurrences:
must 11
might 68
could 16
need 215 (58 of these are "needs", mostly in "needs finalization")
(48 of these are "needed", which is a technical term
when used with compilation units. In order to convince
ISO this is OK, this term should be defined in the
"terms" (probably along with "mentioned")).
(74 of these are "need not", which should not be
used but has no easy replacement).
----
We might be able to argue that "need" is not mentioned in the drafting
document, but even so we ought to get rid of as many of those as possible.
There are nearly 200 paragraphs here that probably need fixing, and there is
not a one-size-fits all solution. Many of the occurrences of "could" and
"might" could be replaced by "can", but certainly not all.
We could consider making wording changes only for the ISO version (new
commands would be needed in the formatter to support that if is done a lot
- currently, we can only do that on a full paragraph basis or with a few
macros - but new commands should not be hard to define and implement).
!comment Only a few changes are defined with Corrigendum sections.
!corrigendum 5.5.3(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 6.1.2(0)
Insert new clause:
See the conflict file for the changes.
!corrigendum 7.6.1(16/2)
Replace the paragraph:
- For an Adjust invoked as part of assignment operations other than
those invoked as part of an assignment_statement, other adjustments due to
be performed might or might not be performed, and then Program_Error is raised.
During its propagation, finalization might or might not be applied to objects
whose Adjust failed. For an Adjust invoked as part of an
assignment_statement, any other adjustments due to be performed are
performed, and then Program_Error is raised.
by:
- For an Adjust invoked as part of assignment operations other than
those invoked as part of an assignment_statement, some of the adjustments
due to be performed can be performed, and then Program_Error is raised.
During its propagation, finalization may be applied to objects
whose Adjust failed. For an Adjust invoked as part of an
assignment_statement, any other adjustments due to be performed are
performed, and then Program_Error is raised.
!corrigendum 12.5.1(1/3)
Replace the paragraph:
In its most general form, the category determined for a formal private
type is all types, but the category can be restricted to only nonlimited
types or to only tagged types. Similarly, the category for a formal
incomplete type is all types but the category can be restricted to only
tagged types; unlike other formal types, the actual type does not need
to be able to be frozen (see 13.14). The category determined for a
formal derived type is the derivation class rooted at the ancestor type.
by:
In its most general form, the category determined for a formal private
type is all types, but the category can be restricted to only nonlimited
types or to only tagged types. Similarly, the category for a formal
incomplete type is all types but the category can be restricted to only
tagged types; unlike other formal types, the actual type can be
incompletely defined, and not ready to be frozen
(see 13.14). The category determined for a formal derived type is the
derivation class rooted at the ancestor type.
!corrigendum 13.1(7/2)
Replace the paragraph:
The representation of an object consists of a certain number of bits (the
size of the object). For an object of an elementary type, these are the
bits that are normally read or updated by the machine code when loading,
storing, or operating-on the value of the object. For an object of a
composite type, these are the bits reserved for this object, and include
bits occupied by subcomponents of the object. If the size of an object is
greater than that of its subtype, the additional bits are padding bits.
For an elementary object, these padding bits are normally read and updated
along with the others. For a composite object, padding bits might not be
read or updated in any given composite operation, depending on the implementation.
by:
The representation of an object consists of a certain number of bits (the
size of the object). For an object of an elementary type, these are the
bits that are normally read or updated by the machine code when loading,
storing, or operating-on the value of the object. For an object of a
composite type, these are the bits reserved for this object, and include
bits occupied by subcomponents of the object. If the size of an object is
greater than that of its subtype, the additional bits are padding bits.
For an elementary object, these padding bits are normally read and updated
along with the others. For a composite object, it is unspecified whether
padding bits are read or updated in any given composite operation.
!corrigendum 13.3(37/2)
Replace the paragraph:
The recommended level of support for the Size attribute of objects is the
same as for subtypes (see below), except that only a confirming Size clause
need be supported for an aliased elementary object.
by:
The recommended level of support for the Size attribute of objects is the
same as for subtypes (see below), except that only a confirming Size clause
is required to be supported for an aliased elementary object.
!corrigendum 13.3(55)
Replace the paragraph:
- The Size (if not specified) of a static discrete or fixed point
subtype should be the number of bits needed to represent each
value belonging to the subtype using an unbiased representation, leaving
space for a sign bit only if the subtype contains negative values. If
such a subtype is a first subtype, then an implementation should
support a specified Size for it that reflects this representation.
by:
- The Size (if not specified) of a static discrete or fixed point
subtype should be the number of bits necessary to represent each
value belonging to the subtype using an unbiased representation, leaving
space for a sign bit only if the subtype contains negative values. If
such a subtype is a first subtype, then an implementation should
support a specified Size for it that reflects this representation.
!corrigendum 13.3(58)
Insert after the paragraph:
NOTE 6 A component_clause or Component_Size clause can override a
specified Size. Aspect Pack cannot.
the new paragraphs:
Static Semantics
For every subtype S:
{{ Rest of this is in the conflict file }}
- If S is some other subtype, only confirming specifications of
Object_Size are required to be supported.
!corrigendum 13.6(1/3)
Replace the paragraph:
A type_conversion (see 4.6) can be used to convert between two different
representations of the same array or record. To convert an array from one
representation to another, two array types need to be declared with
matching component subtypes, and convertible index types.
If one type has Pack specified and the other does not, then explicit
conversion can be used to pack or unpack an array.
by:
A type_conversion (see 4.6) can be used to convert between two different
representations of the same array or record. To convert an array from one
representation to another, two array types with
matching component subtypes and convertible index types are required.
If one type has Pack specified and the other does not, then explicit
conversion can be used to pack or unpack an array.
!corrigendum 13.6(2/5)
Replace the paragraph:
To convert an untagged record from one representation to another, two
record types with a common ancestor type need to be declared.
Distinct representations can then be specified for the record
types, and explicit conversion between the types can be used to effect a
change in representation.
by:
To convert an untagged record from one representation to another, two
record types with a common ancestor type are
required. Distinct representations can then be specified for the record
types, and explicit conversion between the types can be used to effect a
change in representation.
!corrigendum 13.11(21.6/3)
Replace the paragraph:
The number of calls to Allocate needed to implement
an allocator for any particular type is unspecified. The number of calls
to Deallocate needed to implement an instance of
Unchecked_Deallocation (see 13.11.2) for any particular object is the same
as the number of Allocate calls for that object.
by:
The number of calls to Allocate that will be used to implement
an allocator for any particular type is unspecified. The number of calls
to Deallocate that will be used to implement an instance of
Unchecked_Deallocation (see 13.11.2) for any particular object is the same
as the number of Allocate calls for that object.
!corrigendum 13.11.2(9/3)
Replace the paragraph:
- 3.
- Free(X), when X is not equal to null first performs finalization of
the object designated by X (and any coextensions of the object — see
3.10.2), as described in 7.6.1. It then deallocates the storage
occupied by the object designated by X (and any coextensions). If
the storage pool is a user-defined object, then the storage is
deallocated by calling Deallocate as described in 13.11.
There is one exception: if the object being freed contains
tasks, the object might not be deallocated.
by:
- 3.
- Free(X), when X is not equal to null first performs finalization of
the object designated by X (and any coextensions of the object — see
3.10.2), as described in 7.6.1. It then deallocates the storage
occupied by the object designated by X (and any coextensions). If
the storage pool is a user-defined object, then the storage is
deallocated by calling Deallocate as described in 13.11.
There is one exception: if the object being freed contains
tasks, it is unspecified whether the object is deallocated.
!corrigedum 13.13.2(56/3)
Replace the paragraph:
The number of calls performed by the predefined implementation of the
stream-oriented attributes on the Read and Write operations of the stream
type is unspecified. An implementation may take advantage of this
permission to perform internal buffering. However, all the calls on the
Read and Write operations of the stream type needed to implement
an explicit invocation of a stream-oriented attribute shall take place
before this invocation returns. An explicit invocation is one appearing
explicitly in the program text, possibly through a generic instantiation
(see 12.3).
by:
The number of calls performed by the predefined implementation of the
stream-oriented attributes on the Read and Write operations of the stream
type is unspecified. An implementation may take advantage of this
permission to perform internal buffering. However, all the calls on the
Read and Write operations of the stream type used to implement
an explicit invocation of a stream-oriented attribute shall take place
before this invocation returns. An explicit invocation is one appearing
explicitly in the program text, possibly through a generic instantiation
(see 12.3).
!corrigendum 13.13.2(56.1/3)
Replace the paragraph:
If T is a discriminated type and its discriminants have defaults, then
in two cases an execution of the default implementation of S'Read is not
required to create an anonymous object of type T: If the discriminant
values that are read in are equal to the corresponding discriminant values
of Item, then no object of type T need be created
and Item may be used instead. If they are not equal and
Item is a constrained variable, then Constraint_Error may be raised at that
point, before any further values are read from the stream and before the
object of type T is created.
by:
If T is a discriminated type and its discriminants have defaults, then
in two cases an execution of the default implementation of S'Read is not
required to create an anonymous object of type T: If the discriminant
values that are read in are equal to the corresponding discriminant values
of Item, then creation of a new object of type T
may be bypassed and Item may be used instead. If they are not equal and
Item is a constrained variable, then Constraint_Error may be raised at that
point, before any further values are read from the stream and before the
object of type T is created.
!corrigendum A.1(51)
Replace the paragraph:
An implementation may provide additional predefined integer types and
additional predefined floating point types. Not all of these
types need have names.
by:
An implementation may provide additional predefined integer types and
additional predefined floating point types. Some or all of these
types may be anonymous.
!corrigendum A.5.2(40.1/1)
Replace the paragraph:
It is a bounded error to invoke Value with a string that is not the
image of any generator state. If the error is detected, Constraint_Error or
Program_Error is raised. Otherwise, a call to Reset with the resulting state
will produce a generator such that calls to Random with this generator will
produce a sequence of values of the appropriate subtype, but which might
not be random in character. That is, the sequence of values
might not fulfill the implementation requirements of this
subclause.
by:
It is a bounded error to invoke Value with a string that is not the
image of any generator state. If the error is detected, Constraint_Error or
Program_Error is raised. Otherwise, a call to Reset with the resulting state
will produce a generator such that calls to Random with this generator will
produce a sequence of values of the appropriate subtype, but which are
not necessarily random in character. That is, the sequence of values
do not necessarily fulfill the implementation requirements of this
subclause.
!corrigendum A.18.32(0)
Insert new clause:
Placeholder; see conflict file for results.
!corrigendum D.9(12)
Replace the paragraph:
- An upper bound on the lateness of a delay_relative_statement,
for a positive value of the delay expression, in a situation where the task
has sufficient priority to preempt the processor as soon as it becomes
ready, and does not need to wait for any other execution resources. The upper
bound is expressed as a function of the value of the delay expression. The
lateness is obtained by
subtracting the value of the delay expression from the actual duration.
The actual duration is measured from a point immediately before a task
executes the delay_statement to a point immediately after the task
resumes execution following this statement.
by:
- An upper bound on the lateness of a delay_relative_statement,
for a positive value of the delay expression, in a situation where the task
has sufficient priority to preempt the processor as soon as it becomes
ready, and can proceed without waiting for any other execution resources. The
upper bound is expressed as a function of the value of the delay expression.
The lateness is obtained by
subtracting the value of the delay expression from the actual duration.
The actual duration is measured from a point immediately before a task
executes the delay_statement to a point immediately after the task
resumes execution following this statement.
!corrigendum D.9(13)
Replace the paragraph:
- An upper bound on the lateness of a delay_until_statement, in a
situation where the value of the requested expiration time is after the time
the task begins executing the statement, the task has sufficient priority to
preempt the processor as soon as it becomes ready, and it does not need to
wait for any other execution resources. The upper bound is expressed as a
function of the difference between the requested expiration time and
the clock value at the time the statement begins execution. The lateness
of a delay_until_statement is obtained by subtracting the requested
expiration time from the real time that the task resumes execution
following this statement.
by:
- An upper bound on the lateness of a delay_until_statement, in a
situation where the value of the requested expiration time is after the time
the task begins executing the statement, the task has sufficient priority to
preempt the processor as soon as it becomes ready, and it can proceed without
waiting for any other execution resources. The upper bound is expressed as a
function of the difference between the requested expiration time and
the clock value at the time the statement begins execution. The lateness
of a delay_until_statement is obtained by subtracting the requested
expiration time from the real time that the task resumes execution
following this statement.
!corrigendum D.15(1/3)
Replace the paragraph:
This subclause describes a language-defined package to allow user-defined
protected procedures to be executed at a specified time without the
need for a task or a delay statement.
by:
This subclause describes a language-defined package to allow user-defined
protected procedures to be executed at a specified time without the
use of a task or a delay statement.
!corrigendum G(4)
Replace the paragraph:
- a mode ("relaxed mode"), in which no accuracy or other numeric
performance requirements need be satisfied, as for implementations not
conforming to the Numerics Annex;
by:
- a mode ("relaxed mode"), in which there are no accuracy or other numeric
performance requirements to be satisfied, as for implementations not
conforming to the Numerics Annex;
!ASIS
No ASIS effect.
!ACATS test
No ACATS test should be needed, no change in meaning is intended and these
are notes anyway.
!appendix
Here is wording involving forms of "need" that we won't try to fix:
[Note: There are also many technical uses of "need" that we are not changing,
and ISO appears to be primarily worried about "need to" and "need not", so
it's fairly unlikely that they will look at them in enough detail to raise
an objection.]
3.5.10 Operations of Fixed Point Types
4 S'Fore S'Fore yields the minimum number of characters needed before
the decimal point for the decimal representation of any value
of the subtype S, assuming that the representation does not
include an exponent, but includes a one-character prefix that
is either a minus sign or a space. (This minimum number does
not include superfluous zeros or underlines, and is at least
2.) The value of this attribute is of the type
universal_integer.
[Tucker felt that this should not be changed. He said: "Refuse to believe ISO
will object to this." Not having any idea myself, I've left it out - Editor.]
5 S'Aft S'Aft yields the number of decimal digits needed after the
decimal point to accommodate the delta of the subtype S,
unless the delta of the subtype S is greater than 0.1, in
which case the attribute yields the value one. (S'Aft is the
smallest positive integer N for which (10**N)*S'Delta is
greater than or equal to one.) The value of this attribute is
of the type universal_integer.
[See previous paragraph.]
A.10.9 Input-Output for Real Types
23 Outputs the value of the parameter Item as a decimal literal with
the format defined by Fore, Aft and Exp. If the value is negative,
or if Num is a floating point type where Num'Signed_Zeros is True
and the value is a negatively signed zero, then a minus sign is
included in the integer part. If Exp has the value zero, then the
integer part to be output has as many digits as are needed to
represent the integer part of the value of Item, overriding Fore
if necessary, or consists of the digit zero if the value of Item
has no integer part.
[Tucker felt that this should not be changed. He said: "This is consistent
with my earlier recommendation when talking about number of digits needed
for various representations." My usual suggestion would leave this wording
with too many "necessary"s, so no change was made - Editor.]
26 If Exp has the value zero, there is no exponent part. If Exp has a
value greater than zero, then the exponent part to be output has
as many digits as are needed to represent the exponent part of the
value of Item (for which a single digit integer part is used), and
includes an initial sign (plus or minus). If the exponent part to
be output has fewer than Exp characters, including the sign, then
leading zeros precede the digits, to make up the difference. For
the value 0.0 of Item, the exponent has the value zero.
[Tucker wanted to leave this unchanged in order to be consistent with the other
similar paragraphs that we are not changing - Editor.]
A.18.2 The Generic Package Containers.Vectors
115/3 If the capacity of Container is already greater than or equal to
Capacity, then Reserve_Capacity has no effect. Otherwise,
Reserve_Capacity allocates additional storage as necessary to
ensure that the length of the resulting vector can become at least
the value Capacity without requiring an additional call to
Reserve_Capacity, and is large enough to hold the current length
of Container. Reserve_Capacity then, as necessary, moves elements
into the new storage and deallocates any storage no longer needed.
Any exception raised during allocation is propagated and Container
is not modified.
[Tucker suggests not changing. We could have used a word like "required" there,
but that seems unnecessary - Editor.]
Annex H
(normative)
High Integrity Systems
1/2 This Annex addresses requirements for high integrity systems (including
safety-critical systems and security-critical systems). It provides facilities
and specifies documentation requirements that relate to several needs:
[I believe this use of the word "needs" is OK, as it appears several times in
the Directives themselves.]
****************************************************************
From: Randy Brukardt
Sent: Wednesday, May 11, 2022 5:27 PM
More questions that have arisen applying the ISO changes...
ISO comment #21 says:
For an individual document, the form “this document” shall be used when making
references within the document to itself. Use “this document” (not “This
International Standard”) to refer to ISO/IEC 8652 throughout the text.
----
For the most part, this is not interesting to the ARG as we already refer
differently for the RM and ISO versions. The vast majority of the references
that they don't like only appear in the ISO version (which I will change via
adjustments of the macros that determine the natural language used). However,
we have a few uses of "this Standard" and "the Standard" in the text. So far
as I can tell, those never were an allowed form.
... [Items belonging to AI12-0441-1 eliminated - see that AI for the full
text - Editor.] ...
In 3.4.1(6/2), we have "... are referred to in this standard as ..." (note the
lower case). This should be "in this document" (in all versions), and I propose
to put that into AI12-0445-1 with the other uncategorized changes.
****************************************************************
From: Randy Brukardt
Sent: Tuesday, May 24, 2022 12:41 AM
Steve noticed that there are three occurrences of Hashed_Sets in the
Ordered_Set Stable subpackage. These are obviously wrong, I've added them to
the AI12-0445-1 wording changes so that they'll be correct in Ada 2022. If
there is any complaint (I can't imagine why), please speak up now.
****************************************************************
From: John Barnes
Sent: Tuesday, May 24, 2022 2:05 AM
Gosh. Isn't that annoying!! I should have noticed that. Sorry.
****************************************************************
From: Tucker Taft
Sent: Tuesday, May 24, 2022 7:01 AM
Good catch!
****************************************************************
From: Randy Brukardt
Sent: Wednesday, May 25, 2022 12:44 AM
It would have been a better catch if I had found it when I looked for problems
like this last year. I fixed a substantial number of such problems at that
time, but I obviously missed this one.
Unfortunately, compiling these specs with any existing compiler is a real pain
and thus I only did it for a few of the specs. One generally had to remove most
of the new aspects and then provide some sort of dummy body to even get
started. And then one had to decide whether an error was from the compiler or
from the spec (it was about even at that time). It didn't matter much whose
compiler I used for the task, thus it mostly didn't get done. (Tucker did test
the syntax of all of these specs, so we did fix a bunch of those errors.) I
wouldn't be surprised if there are some conflict problems or other visibility
issues in some of these specs.
****************************************************************
From: Randy Brukardt
Sent: Saturday, June 11, 2022 2:01 AM
Following are some fixes to the approved changed wording of the various FDIS
AI. There also were a few typos in the AIs (stray brackets, missing words in
Editor's notes) that I won't bother to explain.
I'm not quite done applying the new wording, so there might be another item
or two on Monday, but I'm sending this now so that you can review it and
highlight any issues before I button this up.
[Editor's note: only issues relevant to this AI are shown here; others
are recorded in other relevant AIs.]
-----
The Note 6.1.2(44/5) says:
NOTE For an example of the use of these aspects and attributes, see the Vector
container definition in A.18.2.
But 6.1.2 doesn't contain any attributes anymore, so this should just say:
NOTE For an example of the use of these aspects, see the Vector container
definition in A.18.2.
I added this to AI12-0442-1.
In so doing, I noticed that 6.1.2(18/5) was in that AI, but that is not a
note or example -- it is in the wrong AI. So I moved that paragraph to
AI12-0445-1.
------------------
In AI12-0445-1, 10.1.1(24) contains two occurrences of "needed"; both should
be replaced as follows:
* The semantic dependences (see below) are the ones {necessary}[needed]
to check the compile-time rules across compilation unit boundaries; a
compilation unit depends semantically on the other compilation units
{necessary}[needed] to determine its legality. The visibility rules are
based on the semantic dependences.
This paragraph precedes the definition of a compilation unit being needed, and
moreover is really not talking about the same thing.
****************************************************************
From: Tucker Taft
Sent: Saturday, June 11, 2022 8:14 AM
All look good to me.
****************************************************************
Questions? Ask the ACAA Technical Agent