CVS difference for ai12s/ai12-0444-1.txt
--- ai12s/ai12-0444-1.txt 2022/04/29 05:48:48 1.1
+++ ai12s/ai12-0444-1.txt 2022/05/04 00:03:04 1.2
@@ -1,12 +1,79 @@
-!standard 1.1.5(8) 22-04-27 AI12-0444-1/01
+!standard 1.1.5(8) 22-05-02 AI12-0444-1/02
+!standard 1.1.5(10)
+!standard 2.1(4/5)
+!standard 3.5.4(5)
+!standard 3.5.4(24)
+!standard 3.5.4(25)
!standard 3.5.4(26)
!standard 3.5.6(7/5)
!standard 3.5.6(8/5)
+!standard 3.5.7(5)
+!standard 3.5.7(16)
+!standard 3.6(15)
+!standard 3.9.3(6/4)
+!standard 6.1.2(41/5)
+!standard 6.3(4)
+!standard 7.4(8/3)
+!standard 7.6(19/3)
+!standard 7.6(21/3)
+!standard 9.5.3(22)
+!standard 9.5.3(23/4)
!standard 9.5.3(25)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
-!standard xx.xx(xx)
+!standard 9.6(31)
+!standard 9.8(3)
+!standard 9.10.1(25/5)
+!standard 10.1.3(11)
+!standard 10.2.1(11.2/5)
+!standard 11.4.2(27/3)
+!standard 11.6(5)
+!standard 13.1(22/3)
+!standard 13.1(23/5)
+!standard 13.1(24/3)
+!standard 13.1(25/3)
+!standard 13.1(26/3)
+!standard 13.1(27/3)
+!standard 13.1(28/3)
+!standard 13.2(8/4)
+!standard 13.3(29/2)
+!standard 13.3(30/2)
+!standard 13.3(30.1/2)
+!standard 13.3(33.2/2)
+!standard 13.3(51.2/2)
+!standard 13.3(51.3/2)
+!standard 13.3(65)
+!standard 13.4(10)
+!standard 13.5.1(22)
+!standard 13.11(25.4/2)
+!standard 13.12.1(7/2)
+!standard 13.13.1(36/5)
+!standard A.4.12(1/5)
+!standard A.5.1(48)
+!standard A.10(8)
+!standard A.10.8(23)
+!standard A.10.9(36)
+!standard A.10.9(37)
+!standard A.13(16)
+!standard B.1(41/4)
+!standard B.3(62.1/3)
+!standard C.3.2(24/5)
+!standard C.7.2(28)
+!standard D.2.2(17/2)
+!standard D.2.2(18/2)
+!standard D.3(15/2)
+!standard D.4(15/2)
+!standard D.4.1(8/5)
+!standard D.11(10)
+!standard D.14(28/2)
+!standard E.1(13)
+!standard E.2.3(20/5)
+!standard E.5(27)
+!standard G.1.1(54)
+!standard G.1.2(46)
+!standard G.2(3)
+!standard G.3.1(87/2)
+!standard G.3.1(156/2)
+!standard G.3.1(157/2)
+!standard H.7.1(14/5)
!class presentation 22-04-27
!status work item 22-04-27
!status received 22-02-18
@@ -30,7 +97,7 @@
!recommendation
-Reword all wording including "need not", perferably into a positive statement.
+Reword all wording including "need not", preferably into a positive statement.
Non-normative material like notes and examples including "need not" are
handled in AI12-0442-1; a single case is found in AI12-0438-1 as the paragraph
also includes "must"; the rest are found here.
@@ -47,6 +114,31 @@
but in any case one possible effect of a bounded error is the raising
of the exception Program_Error.
+Modify 1.1.5(10):
+
+ In addition to bounded errors, the language rules define certain kinds
+ of errors as leading to erroneous execution. Like bounded errors, the
+ implementation {is not expected to}[need not] detect such errors
+ either prior to or during run time. Unlike bounded errors, there is no
+ language-specified bound on the possible effect of erroneous execution;
+ the effect is in general not predictable.
+
+Modify 2.1(4/5):
+
+ The coded representation for characters is implementation defined (it
+ {can}[need not] be a representation {that is not} defined within
+ ISO/IEC 10646:2017). A character whose relative code point in its plane
+ is 16#FFFE# or 16#FFFF# is not allowed anywhere in the text of a program.
+ The only characters allowed outside of comments are those in categories
+ other_format, format_effector, and graphic_character.
+
+Modify 3.5.4(5):
+
+ Each simple_expression in a signed_integer_type_definition is expected to
+ be of any integer type; they [need not be of the same]{can be of different
+ integer} type{s}. The expression in a modular_type_definition is likewise
+ expected to be of any integer type.
+
Modify 3.5.4(24):
For the execution of a predefined operation of a signed integer type, {it
@@ -63,6 +155,21 @@
required} if the result is outside the base range of the type,
{unless}[so long as] the correct result is produced.
+Modify 3.5.4(25):
+
+ An implementation may provide additional predefined signed integer types,
+ declared in the visible part of Standard, whose first subtypes have names
+ of the form Short_Integer, Long_Integer, Short_Short_Integer,
+ Long_Long_Integer, etc. Different predefined integer types are allowed to
+ have the same base range. However, the range of Integer should be no wider
+ than that of Long_Integer. Similarly, the range of Short_Integer (if
+ provided) should be no wider than Integer. Corresponding recommendations
+ apply to any other predefined integer types. [There need not be a named
+ integer type corresponding to each distinct]{An implementation may support}
+ base range{s} [supported by an implementation] for which there is no
+ corresponding named integer type}. The range of each first subtype should
+ be the base range of its type.
+
Modify 3.5.4(26):
An implementation may provide nonstandard integer types, descendants of
@@ -120,732 +227,654 @@
explicit_generic_actual_parameters for formal scalar types - see 12.5.2.
[See 3.5.4(26) for comments - Editor.]
-
-Modify 9.5.3(25):
-
- When an attempt is made to cancel an entry call, the implementation {does not
- have to}[need not] make the attempt using the thread of control of the task
- (or interrupt) that initiated the cancellation; in particular, it may use
- the thread of control of the caller itself to attempt the cancellation, even
- if this {can}[might] allow the entry call to be selected in the interim.
-
-["need not" is replaced by other wording. Also "might" is changed to
-"can". - Editor.]
-
-[*** TBD: A large number of remaining paragraphs that still need wording
-proposals are 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.
-
-Note that while some phrases are given meanings, other uses of the words seem
-be to be allowed by the Directives. For instance, "necessary" is used in many
-contexts in the Directives that are not requirements.
-
-We have a particular problem with "need not", used frequently to get around
-not being able to say "may not". But negative permissions aren't allowed at
-all, in any verbal form. (They have to be reworded positively, or integrated
-into the requirements if that's not possible.) This is a problem since many
-of our permissions are exceptions to rules stated elsewhere, and those have
-to be written negatively. We handle just this problem in this AI; other
-wording changes needed are handled in AI12-0438-1, AI12-0439-1, and AI12-0445-1.
-
---
-
-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).
-
-However, that would add complications to future maintenance (as we would need
-to somehow have both versions in any Corrigendum document, one for our use and
-one for the actual ISO Corrigendum). As such, we want to make any changes that
-do not clearly alter the meaning or harm the understandability of the text.
-
-!ASIS
-
-No ASIS effect.
-
-!ACATS test
-
-No ACATS test should be needed, no change in meaning is intended and these
-are notes anyway.
-
-!appendix
-
-Below here are wording changes for "need not", ..., that need complete rewrites:
-
-1.1.5
-
-10 In addition to bounded errors, the language rules define certain kinds
- of errors as leading to erroneous execution. Like bounded errors, the
- implementation {is not expected to}[need not] detect such errors
- either prior to or during
- run time. Unlike bounded errors, there is no language-specified bound
- on the possible effect of erroneous execution; the effect is in
- general not predictable.
-
-[No attempt to fix.]
-
-2.1 Character Set
-
-4/5 The coded representation for characters is implementation defined (it need
-not be a representation defined within ISO/IEC 10646:2017). A character whose
-relative code point in its plane is 16#FFFE# or 16#FFFF# is not allowed
-anywhere in the text of a program. The only characters allowed outside of
-comments are those in categories other_format, format_effector, and
-graphic_character.
-
-[No attempt to fix.]
-
-3.5.4 Integer Types
-
-5 Each simple_expression in a signed_integer_type_definition is expected to
-be of any integer type; they need not be of the same type. The expression in a
-modular_type_definition is likewise expected to be of any integer type.
-
-[No attempt to fix.]
-
-25 An implementation may provide additional predefined signed integer types,
-declared in the visible part of Standard, whose first subtypes have names of
-the form Short_Integer, Long_Integer, Short_Short_Integer, Long_Long_Integer,
-etc. Different predefined integer types are allowed to have the same base
-range. However, the range of Integer should be no wider than that of
-Long_Integer. Similarly, the range of Short_Integer (if provided) should be no
-wider than Integer. Corresponding recommendations apply to any other
-predefined integer types. There need not be a named integer type corresponding
-to each distinct base range supported by an implementation. The range of each
-first subtype should be the base range of its type.
-[No attempt to fix.]
+Modify 3.5.7(5):
-3.5.7 Floating Point Types
+ Each simple_expression of a real_range_specification is expected to be of
+ any real type; the types {can} [need not] be [the same]{different}.
-5 Each simple_expression of a real_range_specification is expected to be of
-any real type; the types need not be the same.
+Modify 3.5.7(16):
-[No attempt to fix.]
+ An implementation is allowed to provide additional predefined floating
+ point types, declared in the visible part of Standard, whose (unconstrained)
+ first subtypes have names of the form Short_Float, Long_Float,
+ Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
+ types are allowed to have the same base decimal precision. However, the
+ precision of Float should be no greater than that of Long_Float. Similarly,
+ the precision of Short_Float (if provided) should be no greater than Float.
+ Corresponding recommendations apply to any other predefined floating point
+ types. [There need not be a named floating point type corresponding to each
+ distinct]{An implementation may support} base decimal precision{s for which
+ there is no corresponding named floating point type} [supported by an
+ implementation].
+
+Modify 3.6(15):
+
+ An unconstrained_array_definition defines an array type with an
+ unconstrained first subtype. Each index_subtype_definition defines the
+ corresponding index subtype to be the subtype denoted by the subtype_mark.
+ The compound delimiter <> (called a box) of an index_subtype_definition
+ stands for an undefined range (different objects of the type [need
+ not]{can} have [the same] {different} bounds).
+
+Modify 3.9.3(6/4):
+
+ * Otherwise, the subprogram shall be overridden with a nonabstract
+ subprogram or, in the case of a private extension inheriting a
+ nonabstract function with a controlling result, have a full type that
+ is a null extension; for a type declared in the visible part of a
+ package, the overriding may be either in the visible or the private
+ part. Such a subprogram is said to require overriding. However, if the
+ type is a generic formal type, the subprogram {is allowed to be inherited
+ as is, without being} [need not be] overridden for the formal type itself;
+ a nonabstract version will necessarily be provided by the actual type.
+
+Modify 6.1.2(41/5):
+
+ An implementation [need not require that all]{can allow some} references
+ to a constant object [be]{which are not} accounted for by the Global or
+ Global'Class aspect when it is considered a variable in the above rules{,}
+ if the implementation can determine that the object is in fact immutable.
+
+Modify 6.3(4):
+
+ In contrast to other bodies, a subprogram_body {is allowed to be defined
+ without it being} [need not be] the completion of a previous declaration,
+ in which case the body declares the subprogram. If the body is a
+ completion, it shall be the completion of a subprogram_declaration or
+ generic_subprogram_declaration. The profile of a subprogram_body that
+ completes a declaration shall conform fully to that of the declaration.
+
+Modify 7.4(8/3):
+
+ A deferred constant declaration for which the Import aspect is True [need
+ not]{can} appear [in the visible part of a package_specification]{anywhere
+ that an object_declaration is allowed}, and has no full constant
+ declaration.
+
+Modify 7.6(19/3):
+
+ * If an object is assigned the value of that same object, the
+ implementation [need not do anything]{may omit the assignment}.
+
+Modify 7.6(21/3):
+
+ * The implementation [need not create]{may avoid creating} an anonymous
+ object if the value being assigned is the result of evaluating a name
+ denoting an object (the source object) whose storage cannot overlap with
+ the target. If the source object [might]{can} overlap with the target
+ object, then the implementation can avoid the need for an intermediary
+ anonymous object by exercising one of the above permissions and perform
+ the assignment one component at a time (for an overlapping array
+ assignment), or not at all (for an assignment where the target and the
+ source of the assignment are the same object).
+
+["need not", bonus "might" - Editor.]
+
+Modify 9.5.3(22):
+
+ An implementation may perform the sequence of steps of a protected action
+ using any thread of control; it [need not be]{can be a thread other than}
+ that of the task that started the protected action. If an entry_body
+ completes without requeuing, then the corresponding calling task may be
+ made ready without waiting for the entire protected action to complete.
+
+Modify 9.5.3(23/4):
+
+ When the entry of a protected object is checked to see whether it is
+ open, the implementation [need not reevaluate]{can bypass reevaluating}
+ the condition of the corresponding entry_barrier if no variable or
+ attribute referenced by the condition (directly or indirectly) has been
+ altered by the execution (or cancellation) of a call to an exclusive
+ protected operation of the object since the condition was last evaluated.
-16 An implementation is allowed to provide additional predefined floating
-point types, declared in the visible part of Standard, whose (unconstrained)
-first subtypes have names of the form Short_Float, Long_Float,
-Short_Short_Float, Long_Long_Float, etc. Different predefined floating point
-types are allowed to have the same base decimal precision. However, the
-precision of Float should be no greater than that of Long_Float. Similarly,
-the precision of Short_Float (if provided) should be no greater than Float.
-Corresponding recommendations apply to any other predefined floating point
-types. There need not be a named floating point type corresponding to each
-distinct base decimal precision supported by an implementation.
-
-[No attempt to fix.]
-
-3.6 Array Types
-
-15 An unconstrained_array_definition defines an array type with an
-unconstrained first subtype. Each index_subtype_definition defines the
-corresponding index subtype to be the subtype denoted by the subtype_mark. The
-compound delimiter <> (called a box) of an index_subtype_definition stands for
-an undefined range (different objects of the type need not have the same
-bounds).
-
-[No attempt to fix.]
-
-3.9.3 Abstract Types and Subprograms
-
-6/4 * Otherwise, the subprogram shall be overridden with a nonabstract
- subprogram or, in the case of a private extension inheriting a
- nonabstract function with a controlling result, have a full type that
- is a null extension; for a type declared in the visible part of a
- package, the overriding may be either in the visible or the private
- part. Such a subprogram is said to require overriding. However, if the
- type is a generic formal type, the subprogram {does not have to
- be}[need not] be overridden
- for the formal type itself; a nonabstract version will necessarily be
- provided by the actual type.
-
-[Note that negative Requirements are OK, only negative permissions are not allowed.]
-
-6.1.2 The Global and Global'Class Aspects
-
-41/5 An implementation need not require that all references to a constant
-object be accounted for by the Global or Global'Class aspect when it is
-considered a variable in the above rules if the implementation can determine
-that the object is in fact immutable.
-
-[No attempt to fix.]
-
-6.3 Subprogram Bodies
-
-4 In contrast to other bodies, a subprogram_body need not be the completion
-of a previous declaration, in which case the body declares the subprogram. If
-the body is a completion, it shall be the completion of a
-subprogram_declaration or generic_subprogram_declaration. The profile of a
-subprogram_body that completes a declaration shall conform fully to that of
-the declaration.
-
-[No attempt to fix.]
-
-7.4 Deferred Constants
-
-8/3 A deferred constant declaration for which the Import aspect is True need
-not appear in the visible part of a package_specification, and has no full
-constant declaration.
-
-[No attempt to fix.]
-
-7.6 Assignment and Finalization
-
-19/3 * If an object is assigned the value of that same object, the
- implementation need not do anything.
-
-[No attempt to fix.]
-
-21/3 * The implementation need not create an anonymous object if the value
- being assigned is the result of evaluating a name denoting an object
- (the source object) whose storage cannot overlap with the target. If
- the source object might overlap with the target object, then the
- implementation can avoid the need for an intermediary anonymous object
- by exercising one of the above permissions and perform the assignment
- one component at a time (for an overlapping array assignment), or not
- at all (for an assignment where the target and the source of the
- assignment are the same object).
-
-["need not", bonus "might". The "might" should be "can", especially as the
-previous line uses "cannot". But no idea for "need not".]
-
-9.5.3 Entry Calls
-
-22 An implementation may perform the sequence of steps of a protected action
-using any thread of control; it need not be that of the task that started the
-protected action. If an entry_body completes without requeuing, then the
-corresponding calling task may be made ready without waiting for the entire
-protected action to complete.
-
-[No attempt to fix.]
-
-23/4 When the entry of a protected object is checked to see whether it is
-open, the implementation need not reevaluate the condition of the
-corresponding entry_barrier if no variable or attribute referenced by the
-condition (directly or indirectly) has been altered by the execution (or
-cancellation) of a call to an exclusive protected operation of the object
-since the condition was last evaluated.
-
-[No attempt to fix.]
-
-9.6 Delay Statements, Duration, and Time
-
-31 The time base for delay_relative_statements should be monotonic; it need
-not be the same time base as used for Calendar.Clock.
-
-[No attempt to fix.]
-
-9.8 Abort of a Task - Abort of a Sequence of Statements
-
-3 Each task_name is expected to be of any task type; they need not all be of
-the same task type.
-
-[No attempt to fix.]
-
-9.10.1 Conflict Check Policies
-
-25/5 Specifying the Parallel_Calls aspect to be True for a
- subprogram indicates that the subprogram can be safely called
- in parallel. Conflict checks (if required by the
- Conflict_Check_Policy in effect) are made on the subprogram
- assuming that multiple concurrent calls exist. Such checks
- need not be repeated at each call of the subprogram in a
- parallel iteration context.
-
-[No attempt to fix.]
-
-10.1.3 Subunits of Compilation Units
+Modify 9.5.3(25):
-11 In contrast, a subprogram_body_stub need not be the completion of a
-previous declaration, in which case the _stub declares the subprogram. If the
-_stub is a completion, it shall be the completion of a
-subprogram_declaration or generic_subprogram_declaration. The profile of a
-subprogram_body_stub that completes a declaration shall conform fully to that
-of the declaration.
+ When an attempt is made to cancel an entry call, the implementation {can
+ use a}[need not make the attempt using the] thread of control {other than
+ that} of the task (or interrupt) that initiated the cancellation; in
+ particular, it may use the thread of control of the caller itself to
+ attempt the cancellation, even if this {can}[might] allow the entry call
+ to be selected in the interim.
-[No attempt to fix.]
+["need not" is replaced by other wording. Also "might" is changed to
+"can". - Editor.]
-10.2.1 Elaboration Control
+Modify 9.6(31):
-11.2/5 * The partial view of a private type or private extension, a
- protected type without entry_declarations, a generic formal private
- type, or a generic formal derived type, has preelaborable
- initialization if and only if the Preelaborable_Initialization aspect
- has been specified True for them. A protected type with
- entry_declarations or a task type never has preelaborable
- initialization. The Preelaborable_Initialization aspect of a partial
- view of a type may be specified as False, even if the full view of the
- type has preelaborable initialization. Similarly, a generic formal
- type need not be specified to have preelaborable initialization, even
- if the actual type in an instance has preelaborable initialization.
+ The time base for delay_relative_statements should be monotonic; it {can
+ be different than}[need not be] the [same] time base as used for
+ Calendar.Clock.
-[No attempt to fix.]
+Modify 9.8(3):
-11.4.2 Pragmas Assert and Assertion_Policy
+ Each task_name is expected to be of any task type; [they need not all be of
+ the same]{each can be of a different} task type.
-27/3 An implementation need not allow the specification of an assertion
-expression if the evaluation of the expression has a side effect such that an
-immediate reevaluation of the expression could produce a different value.
-Similarly, an implementation need not allow the specification of an assertion
-expression that is checked as part of a call on or return from a callable
-entity C, if the evaluation of the expression has a side effect such that the
-evaluation of some other assertion expression associated with the same call of
-(or return from) C could produce a different value than it would if the first
-expression had not been evaluated.
+Modify 9.10.1(25/5):
-[Multiple "need not allow"; two bonus "could"s too. No idea of a fix.]
+ Specifying the Parallel_Calls aspect to be True for a
+ subprogram indicates that the subprogram can be safely called
+ in parallel. Conflict checks (if required by the
+ Conflict_Check_Policy in effect) are made on the subprogram
+ assuming that multiple concurrent calls exist. Such checks
+ [need not be repeated at each]{can then be omitted on a} call of the
+ subprogram in a parallel iteration context.
-[No attempt to fix.]
+Modify 10.1.3(11):
-11.6 Exceptions and Optimization
+ In contrast, a subprogram_body_stub [need not be]{can be defined without
+ it being} the completion of a previous declaration, in which case the
+ _stub declares the subprogram. If the _stub is a completion, it shall be
+ the completion of a subprogram_declaration or
+ generic_subprogram_declaration. The profile of a subprogram_body_stub that
+ completes a declaration shall conform fully to that of the declaration.
-5 * An implementation need not always raise an exception when a
- language-defined check fails. Instead, the operation that failed the
- check can simply yield an undefined result. The exception need be
- raised by the implementation only if, in the absence of raising it,
- the value of this undefined result would have some effect on the
- external interactions of the program. In determining this, the
- implementation shall not presume that an undefined result has a value
- that belongs to its subtype, nor even to the base range of its type,
- if scalar. Having removed the raise of the exception, the canonical
- semantics will in general allow the implementation to omit the code
- for the check, and some or all of the operation itself.
+Modify 10.2.1(11.2/5):
-[No attempt to fix. Fix "need be", too.]
+ * The partial view of a private type or private extension, a
+ protected type without entry_declarations, a generic formal private
+ type, or a generic formal derived type, has preelaborable
+ initialization if and only if the Preelaborable_Initialization aspect
+ has been specified True for them. A protected type with
+ entry_declarations or a task type never has preelaborable
+ initialization. The Preelaborable_Initialization aspect of a partial
+ view of a type may be specified as False, even if the full view of the
+ type has preelaborable initialization. Similarly, a generic formal
+ type [need not]{may} be specified [to have preelaborable
+ initialization]{with Preelaborable_Initialization False}, even
+ if the actual type in an instance has preelaborable initialization.
-12.5.1 Formal Private and Derived Types
+Modify 11.4.2(27/3):
-15 For a generic formal type with an unknown_discriminant_part, the actual
-may, but need not, have discriminants, and may be definite or indefinite.
+ An implementation [need not allow]{may disallow} the specification of an
+ assertion expression if the evaluation of the expression has a side effect
+ such that an immediate reevaluation of the expression {can}[could] produce
+ a different value. Similarly, an implementation [need not allow]{may
+ disallow} the specification of an assertion expression that is checked as
+ part of a call on or return from a callable entity C, if the evaluation of
+ the expression has a side effect such that the evaluation of some other
+ assertion expression associated with the same call of (or return from) C
+ {can}[could] produce a different value than [it would if]{in the case when}
+ the first expression had not been evaluated.
-[No attempt to fix. "(but discriminants are not required)"??]
+[Multiple "need not allow"; two bonus "could"s too - Editor.]
-13.1 Operational and Representation Aspects
+Modify 11.6(5):
-22/3 * An implementation need not support the specification for a
- representation aspect that contains nonstatic expressions, unless each
- nonstatic expression is a name that statically denotes a constant
- declared before the entity.
+ * An implementation {can omit raising}[need not always raise] an exception
+ when a language-defined check fails. Instead, the operation that failed
+ the check can simply yield an undefined result. The exception {is
+ required to be}[need be] raised by the implementation only if, in the
+ absence of raising it, the value of this undefined result would have
+ some effect on the external interactions of the program. In determining
+ this, the implementation shall not presume that an undefined result has
+ a value that belongs to its subtype, nor even to the base range of its
+ type, if scalar. Having removed the raise of the exception, the canonical
+ semantics will in general allow the implementation to omit the code
+ for the check, and some or all of the operation itself.
-["need not support". No idea of a fix.]
+[Replace "need not" and "need be".]
-23/5 * An implementation need not support a specification for the
- Object_Size or Size for a given composite subtype, nor the size or
- storage place for an object (including a component) of a given
- composite subtype, unless the constraints on the subtype and its
- composite subcomponents (if any) are all static constraints.
+Modify 12.5.1(15):
-["need not support". No idea of a fix.]
+ For a generic formal type with an unknown_discriminant_part, the actual
+ may[, but need not,] have discriminants{, though that is not required},
+ and may be definite or indefinite.
-24/3 * An implementation need not support specifying a nonconfirming
- representation aspect value if it could cause an aliased object or an
- object of a by-reference type to be allocated at a nonaddressable
- location or, when the alignment attribute of the subtype of such an
- object is nonzero, at an address that is not an integral multiple of
- that alignment.
+Modify 13.1(22/3):
-["need not support", "could cause". No idea of a fix.]
+ * An implementation {is not required to}[need not] support the
+ specification for a representation aspect that contains nonstatic
+ expressions, unless each nonstatic expression is a name that
+ statically denotes a constant declared before the entity.
-25/3 * An implementation need not support specifying a nonconfirming
- representation aspect value if it could cause an aliased object of an
- elementary type to have a size other than that which would have been
- chosen by default.
+[We tried a large number of rewordings here; this was the easiest that seems
+that it might be OK. For the 13.1 wording, I had suggested "never" rather than
+"not", to emphasize that these are the most important rules and they apply
+even when the Recommended Level of Support is required. Tuck thought that was
+overkill.
-["need not support", "could cause". No idea of a fix.]
+Other ideas included "may disallow" and "support is optional" - Editor.]
-26/3 * An implementation need not support specifying a nonconfirming
- representation aspect value if it could cause an aliased object of a
- composite type, or an object whose type is by-reference, to have a
- size smaller than that which would have been chosen by default.
+Modify 13.1(23/5):
-["need not support", "could cause". No idea of a fix.]
+ * An implementation {is not required to}[need not] support a specification
+ for the Object_Size or Size for a given composite subtype, nor the size or
+ storage place for an object (including a component) of a given
+ composite subtype, unless the constraints on the subtype and its
+ composite subcomponents (if any) are all static constraints.
-27/3 * An implementation need not support specifying a nonconfirming
- subtype-specific representation aspect value for an indefinite or
- abstract subtype.
+Modify 13.1(24/3):
-["need not support". No idea of a fix.]
+ * An implementation {is not required to}[need not] support specifying a
+ nonconfirming representation aspect value if it [could]{can} cause an
+ aliased object or an object of a by-reference type to be allocated at
+ a nonaddressable location or, when the alignment attribute of the subtype
+ of such an object is nonzero, at an address that is not an integral
+ multiple of that alignment.
-28/3 For purposes of these rules, the determination of whether specifying a
-representation aspect value for a type could cause an object to have some
-property is based solely on the properties of the type itself, not on any
-available information about how the type is used. In particular, it presumes
-that minimally aligned objects of this type might be declared at some point.
+[Replace "need not support", "could cause" - Editor.]
-["could cause"; that is used sort of like a technical term, but it isn't
-a defined term and even if it was, it's not clear it would be allowed.
-"might" also occurs here.]
+Modify 13.1(25/3):
-13.2 Packed Types
+ * An implementation {is not required to}[need not] support specifying a
+ nonconfirming representation aspect value if it [could]{can} cause an
+ aliased object of an elementary type to have a size other than that
+ which would have been chosen by default.
-8/4 * For a packed record type, the components should be packed as tightly
- as possible subject to the above alignment requirements, the Sizes of
- the component subtypes, and any record_representation_clause that
- applies to the type; the implementation may, but need not, reorder
- components or cross aligned word boundaries to improve the packing. A
- component whose Size is greater than the word size may be allocated an
- integral number of words.
+[Replace "need not support", "could cause" - Editor.]
-[No attempt to fix.]
+Modify 13.1(26/3):
-13.3 Operational and Representation Attributes
+ * An implementation {is not required to}[need not] support specifying a
+ nonconfirming representation aspect value if it [could]{can} cause an
+ aliased object of a composite type, or an object whose type is
+ by-reference, to have a size smaller than that which would have been
+ chosen by default.
-29/2 * An implementation need not support an Alignment clause for a signed
- integer type specifying an Alignment greater than the largest
- Alignment value that is ever chosen by default by the implementation
- for any signed integer type. A corresponding limitation may be imposed
- for modular integer types, fixed point types, enumeration types,
- record types, and array types.
+[Replace "need not support", "could cause" - Editor.]
-["need not support". No idea of a fix.]
+Modify 13.1(27/3):
-30/2 * An implementation need not support a nonconfirming Alignment clause
- which could enable the creation of an object of an elementary type
- which cannot be easily loaded and stored by available machine
- instructions.
+ * An implementation {is not required to}[need not] support specifying a
+ nonconfirming subtype-specific representation aspect value for an
+ indefinite or abstract subtype.
-["need not support", "could enable". No idea of a fix.]
+Modify 13.1(28/3):
-30.1/2 * An implementation need not support an Alignment specified for a
- derived tagged type which is not a multiple of the Alignment of the
- parent type. An implementation need not support a nonconfirming
- Alignment specified for a derived untagged by-reference type.
+ For purposes of these rules, the determination of whether specifying a
+ representation aspect value for a type [could]{can} cause an object to have
+ some property is based solely on the properties of the type itself, not on
+ any available information about how the type is used. In particular, it
+ presumes that minimally aligned objects of this type [might]{can} be
+ declared at some point.
-["need not support". No idea of a fix.]
+[Replace "could cause"; that is used sort of like a technical term, but it isn't
+a defined term. "might" also occurs here. This paragraph was left with the
+related other paragraphs so that the fix was consistent (there is no "need not"
+in this paragraph) - Editor.]
-33.2/2 * An implementation need not support Alignments specified for objects
- of a by-reference type or for objects of types containing aliased
- subcomponents if the specified Alignment is not a multiple of the
- Alignment of the subtype of the object.
+Modify 13.2(8/4):
-[No attempt to fix.]
+ * For a packed record type, the components should be packed as tightly
+ as possible subject to the above alignment requirements, the Sizes of
+ the component subtypes, and any record_representation_clause that
+ applies to the type; the implementation [may, but need not,]{is allowed
+ to} reorder components or cross aligned word boundaries to improve the
+ packing. A component whose Size is greater than the word size may be
+ allocated an integral number of words.
-51.2/2 * An implementation need not support a Size clause for a signed
- integer type specifying a Size greater than that of the largest
- signed integer type supported by the implementation in the absence
- of a size clause (that is, when the size is chosen by default). A
- corresponding limitation may be imposed for modular integer types,
- fixed point types, enumeration types, record types, and array
- types.
+Modify 13.3(29/2):
-[No attempt to fix.]
+ * An implementation {is not required to}[need not] support an Alignment
+ clause for a signed integer type specifying an Alignment greater than
+ the largest Alignment value that is ever chosen by default by the
+ implementation for any signed integer type. A corresponding limitation
+ may be imposed for modular integer types, fixed point types, enumeration
+ types, record types, and array types.
-51.3/2 * A nonconfirming size clause for the first subtype of a derived
- untagged by-reference type need not be supported.
+Modify 13.3(30/2):
-[No attempt to fix.]
+ * An implementation {is not required to}[need not] support a nonconfirming
+ Alignment clause which {can cause}[could enable] the creation of an object
+ of an elementary type which cannot be easily loaded and stored by
+ available machine instructions.
-65 * An implementation need not support specified Component_Sizes that are
- less than the Size of the component subtype.
+[Replace "need not support", "could enable" - Editor.]
-[No attempt to fix.]
+Modify 13.3(30.1/2):
-13.4 Enumeration Representation Clauses
+ * An implementation {is not required to}[need not] support an Alignment
+ specified for a derived tagged type which is not a multiple of the
+ Alignment of the parent type. An implementation need not support a
+ nonconfirming Alignment specified for a derived untagged by-reference
+ type.
-10 * An implementation should support at least the internal codes in the
- range System.Min_Int .. System.Max_Int. An implementation need not
- support enumeration_representation_clauses for boolean types.
+Modify 13.3(33.2/2):
-[No attempt to fix.]
+ * An implementation {is not required to}[need not] support Alignments
+ specified for objects of a by-reference type or for objects of types
+ containing aliased subcomponents if the specified Alignment is not a
+ multiple of the Alignment of the subtype of the object.
-13.5.1 Record Representation Clauses
+Modify 13.3(51.2/2):
-22 * An implementation need not support a component_clause for a component
- of an extension part if the storage place is not after the storage
- places of all components of the parent type, whether or not those
- storage places had been specified.
+ * An implementation {is not required to}[need not] support a Size clause for
+ a signed integer type specifying a Size greater than that of the largest
+ signed integer type supported by the implementation in the absence
+ of a size clause (that is, when the size is chosen by default). A
+ corresponding limitation may be imposed for modular integer types,
+ fixed point types, enumeration types, record types, and array types.
-[No attempt to fix.]
+Modify 13.3(51.3/2):
-13.11 Storage Management
+ * A nonconfirming size clause for the first subtype of a derived
+ untagged by-reference type {is not required to}[need not] be supported.
-25.4/2 * Otherwise, a default storage pool should be created at the point
- where the anonymous access type is elaborated; such a storage pool
- need not support deallocation of individual objects.
+Modify 13.3(65):
-[No attempt to fix.]
+ * An implementation {is not required to}[need not] support specified
+ Component_Sizes that are less than the Size of the component subtype.
-13.12.1 Language-Defined Restrictions and Profiles
+Modify 13.4(10):
-7/2 The restriction_parameter_argument of a No_Dependence restriction shall be
-a name; the name shall have the form of a full expanded name of a library
-unit, but need not denote a unit present in the environment.
+ * An implementation should support at least the internal codes in the
+ range System.Min_Int .. System.Max_Int. An implementation {is not required
+ to}[need not] support enumeration_representation_clauses for boolean types.
-[No attempt to fix.]
+Modify 13.5.1(22):
-13.13.1 The Streams Subsystem
+ * An implementation {is not required to}[need not] support a component_clause
+ for a component of an extension part if the storage place is not after the
+ storage places of all components of the parent type, whether or not those
+ storage places had been specified.
-36/5 If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
-components of Stream_Element_Array need not be aliased.
+Modify 13.11(25.4/2):
-[No attempt to fix.]
+ * Otherwise, a default storage pool should be created at the point
+ where the anonymous access type is elaborated; such a storage pool
+ [need not support]{can have no mechanism for the} deallocation of
+ individual objects.
-A.4.12 Universal Text Buffers
+Modify 13.12.1(7/2):
-1/5 A universal text buffer can be used to save and retrieve text of any
-language-defined string type. The types used to save and retrieve the text
-need not be the same.
+ The restriction_parameter_argument of a No_Dependence restriction shall be
+ a name; the name shall have the form of a full expanded name of a library
+ unit, but [need not denote a]{can be a name that has no corresponding}
+ unit {currently} present in the environment.
-[No attempt to fix.]
+Modify 13.13.1(36/5):
-A.5.1 Elementary Functions
+ If Stream_Element'Size is not a multiple of System.Storage_Unit, then the
+ components of Stream_Element_Array [need]{will} not be aliased.
-48 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+[Tucker says: It really cannot be aliased if Stream_Element'Size is not a
+multiple of Storage_Unit - Editor.]
-[No attempt to fix.]
+Modify A.4.12(1/5):
-A.10 Text Input-Output
+ A universal text buffer can be used to save and retrieve text of any
+ language-defined string type. The types used to save and retrieve the text
+ [need not be the same]{can be different}.
-8 The actual nature of terminators is not defined by the language and hence
-depends on the implementation. Although terminators are recognized or
-generated by certain of the procedures that follow, they are not necessarily
-implemented as characters or as sequences of characters. Whether they are
-characters (and if so which ones) in any particular implementation need not
-concern a user who neither explicitly outputs nor explicitly inputs control
-characters. The effect of input (Get) or output (Put) of control characters
-(other than horizontal tabulation) is not specified by the language.
+Modify A.5.1(48):
-[No attempt to fix.]
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-A.10.8 Input-Output for Integer Types
+Modify A.10(8):
-23 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+ The actual nature of terminators is not defined by the language and hence
+ depends on the implementation. Although terminators are recognized or
+ generated by certain of the procedures that follow, they are not
+ necessarily implemented as characters or as sequences of characters.
+ Whether they are characters (and if so which ones) in any particular
+ implementation [need]{is} not {of} concern {to} a user who neither
+ explicitly outputs nor explicitly inputs control characters. The effect of
+ input (Get) or output (Put) of control characters (other than horizontal
+ tabulation) is not specified by the language.
-[No attempt to fix.]
+Modify A.10.8(23):
-A.10.9 Input-Output for Real Types
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-36 The implementation of Put need not produce an output value with greater
-accuracy than is supported for the base subtype. The additional accuracy, if
-any, of the value produced by Put when the number of requested digits in the
-integer and fractional parts exceeds the required accuracy is implementation
-defined.
+Modify A.10.9(36):
-[No attempt to fix.]
+ The implementation of Put [need not]{may} produce an output value with
+ {no} greater accuracy than {that which} is supported for the base subtype.
+ The additional accuracy, if any, of the value produced by Put when the
+ number of requested digits in the integer and fractional parts exceeds the
+ required accuracy is implementation defined.
-37 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+Modify A.10.9(37):
-[No attempt to fix.]
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-A.13 Exceptions in Input-Output
+Modify A.13(16):
-16 If the associated check is too complex, an implementation need not
-propagate Data_Error as part of a procedure Read (or the Read attribute) if
-the value read cannot be interpreted as a value of the required subtype.
+ {When}[If] the associated check is [too] complex, {it is optional to}[an
+ implementation need not] propagate Data_Error as part of a procedure Read
+ (or the Read attribute) {when}[if] the value read cannot be interpreted
+ is a value of the required subtype.]
-[No attempt to fix.]
+[Less radical alternative:
+ If the associated check is too complex, an implementation {does not have
+ to}[need not] propagate Data_Error as part of a procedure Read (or the
+ Read attribute) [if]{even though} the value read cannot be interpreted
+ as a value of the required subtype.
-B.1 Interfacing Aspects
+"does not have to" sounds rather close to a negative permission, as does most
+of the alternatives we tried. So the more substantial rewrite is
+preferred - Editor.]
-41/4 For each supported convention L other than Intrinsic, an implementation
-should support specifying the Import and Export aspects for objects of
-L-compatible types and for subprograms, and the Convention aspect for
-L-eligible types and for subprograms, presuming the other language has
-corresponding features. Specifying the Convention aspect need not be supported
-for scalar types, other than enumeration types whose internal codes fall
-within the range 0 .. 2**15-1.
+Modify B.1(41/4):
-[No attempt to fix.]
+ For each supported convention L other than Intrinsic, an implementation
+ should support specifying the Import and Export aspects for objects of
+ L-compatible types and for subprograms, and the Convention aspect for
+ L-eligible types and for subprograms, presuming the other language has
+ corresponding features. Specifying the Convention aspect [need
+ not]{should} be supported for [scalar types, other than] enumeration
+ types whose internal codes fall within the range 0 .. 2**15-1{, but no
+ recommendation is made for other scalar types}.
-B.3 Interfacing with C and C++
+Modify B.3(62.1/3):
-62.1/3 An implementation need not support specifying the Convention aspect
-with convention_identifier C in the following cases:
+ An implementation {is not required to}[need not] support specifying the
+ Convention aspect with convention_identifier C in the following cases:
-[No attempt to fix.]
+Modify C.3.2(24/5):
-C.3.2 The Package Interrupts
+ The implementation shall document, when the Ceiling_Locking policy (see
+ D.3) is in effect, the default ceiling priority assigned to a protected
+ object that contains a protected procedure that specifies either the
+ Attach_Handler or Interrupt_Handler aspects, but does not specify the
+ Interrupt_Priority aspect. This default [need not be the same]{can be
+ different} for [all]{different} interrupts.
-24/5 The implementation shall document, when the Ceiling_Locking policy (see
-D.3) is in effect, the default ceiling priority assigned to a protected object
-that contains a protected procedure that specifies either the Attach_Handler
-or Interrupt_Handler aspects, but does not specify the Interrupt_Priority
-aspect. This default need not be the same for all interrupts.
+Modify C.7.2(28):
-[No attempt to fix.]
+ An implementation [need not]{can avoid} actually [create]{creating} the
+ object corresponding to a task attribute until its value is set to
+ something other than that of Initial_Value, or until Reference is called
+ for the task attribute. Similarly, when the value of the attribute is
+ to be reinitialized to that of Initial_Value, the object may instead be
+ finalized and its storage reclaimed, to be recreated when needed later.
+ While the object does not exist, the function Value may simply return
+ Initial_Value, rather than implicitly creating the object.
-C.7.2 The Package Task_Attributes
+Modify D.2.2(17/2):
-28 An implementation need not actually create the object corresponding to a
-task attribute until its value is set to something other than that of
-Initial_Value, or until Reference is called for the task attribute. Similarly,
-when the value of the attribute is to be reinitialized to that of
-Initial_Value, the object may instead be finalized and its storage reclaimed,
-to be recreated when needed later. While the object does not exist, the
-function Value may simply return Initial_Value, rather than implicitly
-creating the object.
+ Implementations are allowed to define other task dispatching policies,
+ but {are not required to}[need not] support {specifying} more than one
+ task dispatching policy per partition.
-[No attempt to fix.]
+Modify D.2.2(18/2):
-D.2.2 Task Dispatching Pragmas
+ An implementation {is not required to}[need not] support pragma
+ Priority_Specific_Dispatching if it is infeasible to support it in the
+ target environment.
-17/2 Implementations are allowed to define other task dispatching policies,
-but need not support more than one task dispatching policy per partition.
+Modify D.3(15/2):
-[No attempt to fix.]
+ Implementations are allowed to define other locking policies, but {are
+ not required to}[need not] support {specifying} more than one locking
+ policy per partition.
-18/2 An implementation need not support pragma Priority_Specific_Dispatching
-if it is infeasible to support it in the target environment.
+Modify D.4(15/2):
-[No attempt to fix.]
+ Implementations are allowed to define other queuing policies, but {are
+ not required to}[need not] support {specifying} more than one queuing
+ policy per partition.
-D.3 Priority Ceiling Locking
+Modify D.4.1(8/5):
-15/2 Implementations are allowed to define other locking policies, but need
-not support more than one locking policy per partition.
+ Implementations are allowed to define other admission policies, but {are
+ not required to}[need not] support {specifying} more than one admission
+ policy per partition.
-[No attempt to fix.]
+Modify D.8(46):
-D.4 Entry Queuing Policies
+ Implementations targeted to machines with word size smaller than 32 bits
+ [need not support]{may omit support for} the full range and granularity of
+ the Time and Time_Span types.
-15/2 Implementations are allowed to define other queuing policies, but need
-not support more than one queuing policy per partition.
+[This and the ones like it below are Implementation Permissions, so they
+should be using some form of "may" - Editor.]
-[No attempt to fix.]
+Modify D.11(10):
-D.4.1 Admission Policies
+ An implementation [need not support]{may omit support for}
+ Asynchronous_Task_Control if it is infeasible to support it in the target
+ environment.
-8/5 Implementations are allowed to define other admission policies, but need
-not support more than one admission policy per partition.
+Modify D.14(28/2):
-[No attempt to fix.]
+ Implementations targeted to machines with word size smaller than 32 bits
+ [need not support]{may omit support for} the full range and granularity
+ of the CPU_Time type.
-D.8 Monotonic Time
+Modify E.1(13):
-46 Implementations targeted to machines with word size smaller than 32 bits
-need not support the full range and granularity of the Time and Time_Span
-types.
+ In an implementation, the partitions of a distributed program
+ [need not]{may} be loaded and elaborated [all at the same time]{at
+ different times}; they may be loaded and elaborated one at a time over an
+ extended period of time. An implementation may provide facilities to abort
+ and reload a partition during the execution of a distributed program.
-[No attempt to fix.]
+Modify E.2.3(20/5):
-D.11 Asynchronous Task Control
+ An implementation [need not support]{may omit support for} the
+ Remote_Call_Interface aspect [nor]{or} the All_Calls_Remote aspect.
+ Explicit message-based communication between active partitions can be
+ supported as an alternative to RPC.
-10 An implementation need not support Asynchronous_Task_Control if it is
-infeasible to support it in the target environment.
+Modify E.5(27):
-[No attempt to fix.]
+ A body for the package System.RPC {is not required to}[need not] be
+ supplied by the implementation.
-D.14 Execution Time
+Modify G.1.1(54):
-28/2 Implementations targeted to machines with word size smaller than 32 bits
-need not support the full range and granularity of the CPU_Time type.
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-[No attempt to fix.]
+Modify G.1.2(46):
-E.1 Partitions
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package with the appropriate predefined
+ nongeneric equivalent of Numerics.Generic_Complex_Types{, though that
+ is not required}; if they are, then the latter shall have been obtained
+ by actual instantiation of Numerics.Generic_Complex_Types.
-13 In an implementation, the partitions of a distributed program need not be
-loaded and elaborated all at the same time; they may be loaded and elaborated
-one at a time over an extended period of time. An implementation may provide
-facilities to abort and reload a partition during the execution of a
-distributed program.
+Modify G.2(3):
-[No attempt to fix.]
+ The two modes [need not actually be different]{can be one and the same}.
-E.2.3 Remote Call Interface Library Units
+Modify G.3.1(87/2):
-20/5 An implementation need not support the Remote_Call_Interface aspect nor
-the All_Calls_Remote aspect. Explicit message-based communication between
-active partitions can be supported as an alternative to RPC.
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-[No attempt to fix.]
+Modify G.3.1(156/2):
-E.5 Partition Communication Subsystem
+ The nongeneric equivalent packages [may, but need not,]{can} be actual
+ instantiations of the generic package for the appropriate predefined
+ type{, though that is not required}.
-27 A body for the package System.RPC need not be supplied by the
-implementation.
+Modify G.3.1(157/2):
-[No attempt to fix.]
+ Although many operations are defined in terms of operations from
+ numerics.generic_complex_types, they [need not]{can} be implemented by
+ [calling those operations provided that the]{other operations that have
+ the same} effect[ is the same].
-G.1.1 Complex Types
+Modify H.7.1(14/5):
-54 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+ The dispatching operation set is identified by a set of
+ dispatching_operation_specifiers. It indicates that the Nonblocking and
+ global effects of dispatching calls that match one of the specifiers{,
+ rather than being} [need not be] accounted for by the Nonblocking or global
+ aspect, [but] are instead to be accounted for by the invoker of the
+ operation. A dispatching call matches a dispatching_operation_specifier if
+ the name or prefix of the call statically denotes the same operation(s) as
+ that of the dispatching_operation_specifier, and at least one of the
+ objects controlling the call is denoted by, or designated by, a name that
+ statically names the same object as that denoted by the object_name of the
+ dispatching_operation_specifier.
-[No attempt to fix.]
+!discussion
-G.1.2 Complex Elementary Functions
+To summarize the ISO rules from the Directives part 2 (often referred to as the
+drafting standard):
-46 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package with the appropriate predefined
-nongeneric equivalent of Numerics.Generic_Complex_Types; if they are, then the
-latter shall have been obtained by actual instantiation of
-Numerics.Generic_Complex_Types.
+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).
-[No attempt to fix.]
+Recommendations use "should" preferably, or phrases involving forms of
+"recommend" or "ought to".
-G.2 Numeric Performance Requirements
+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."
-3 The two modes need not actually be different.
+Possibility should use "can", or phrases using forms of "able" or "possible".
-[No attempt to fix.]
+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.
-G.3.1 Real Vectors and Matrices
+Note that while some phrases are given meanings, other uses of the words seem
+be to be allowed by the Directives. For instance, "necessary" is used in many
+contexts in the Directives that are not requirements.
-87/2 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+We have a particular problem with "need not", used frequently to get around
+not being able to say "may not". But negative permissions aren't allowed at
+all, in any verbal form. (They have to be reworded positively, or integrated
+into the requirements if that's not possible.) This is a problem since many
+of our permissions are exceptions to rules stated elsewhere, and those have
+to be written negatively. We handle just this problem in this AI; other
+wording changes needed are handled in AI12-0438-1, AI12-0439-1, and AI12-0445-1.
-[No attempt to fix.]
+--
-156/2 The nongeneric equivalent packages may, but need not, be actual
-instantiations of the generic package for the appropriate predefined type.
+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).
-[No attempt to fix.]
+However, that would add complications to future maintenance (as we would need
+to somehow have both versions in any Corrigendum document, one for our use and
+one for the actual ISO Corrigendum). As such, we want to make any changes that
+do not clearly alter the meaning or harm the understandability of the text.
-157/2 Although many operations are defined in terms of operations from
-numerics.generic_complex_types, they need not be implemented by calling those
-operations provided that the effect is the same.
+!ASIS
-[No attempt to fix.]
+No ASIS effect.
-H.7.1 The Use_Formal and Dispatching Aspects
+!ACATS test
-14/5 The dispatching operation set is identified by a set of
-dispatching_operation_specifiers. It indicates that the Nonblocking and global
-effects of dispatching calls that match one of the specifiers need not be
-accounted for by the Nonblocking or global aspect, but are instead to be
-accounted for by the invoker of the operation. A dispatching call matches a
-dispatching_operation_specifier if the name or prefix of the call statically
-denotes the same operation(s) as that of the dispatching_operation_specifier,
-and at least one of the objects controlling the call is denoted by, or
-designated by, a name that statically names the same object as that denoted by
-the object_name of the dispatching_operation_specifier.
+No ACATS test should be needed, no change in meaning is intended and these
+are notes anyway.
-[No attempt to fix.]
+!appendix
****************************************************************
Questions? Ask the ACAA Technical Agent