Closed jensmaurer closed 3 years ago
jensmaurer
commented
3 years ago Preliminary course of action:
jensmaurer
commented
3 years ago List of "could or might" outside of notes/examples (100 instances):
algorithms.tex:138:and users might as well do \tcode{copy} followed by \tcode{sort}.} algorithms.tex:356:that could be formed by the invocation basic.tex:2641:A name is said to have \defn{linkage} when it might denote the same basic.tex:3782:behavior.\footnote{Some implementations might define that basic.tex:4219:The alignment required for a type might be different when it is used as the type basic.tex:4761:A class type (such as ``\tcode{class X}'') might be incomplete at one basic.tex:4764:of an array object might be an array of incomplete class type and basic.tex:4768:might be an array of unknown bound and therefore be incomplete at one basic.tex:5758:whatever the syntax of the expression that calls the function might be.% basic.tex:6427:might be initialized\iref{basic.start.static} and destroyed\iref{basic.start.term}. classes.tex:620:that could syntactically form a \grammarterm{constant-expression}. classes.tex:1990:with a parameter type that could be that of a classes.tex:2311:statement\iref{stmt.return} in a destructor might not directly return to the classes.tex:2699:tokens that could possibly form a \grammarterm{conversion-type-id}. classes.tex:3778:its internal representation might not otherwise require classes.tex:6600:In the following copy-initialization contexts, a move operation might be used instead of a copy operation: classes.tex:7209:Hence, even though a different one might actually be executed, compatibility.tex:380:could invoke a different operator. compatibility.tex:382:could become ambiguous. compatibility.tex:518:Code that depends on the return types might have different semantics in this International Standard. compatibility.tex:625:to compile. It might be revised to use \tcode{std::uncaught_exceptions} instead, compatibility.tex:632:The deprecated support relied on a limited convention that could not be compatibility.tex:661:The iterator encouraged use of algorithms that might throw exceptions, but did compatibility.tex:662:not return the number of elements successfully constructed that might need to compatibility.tex:698:trait had a surprising syntax that could not report the result of a regular compatibility.tex:759:Note that this might occur when the lvalue has a type given by a template compatibility.tex:915:and might not perform stack unwinding prior to such a call. compatibility.tex:943:that might otherwise be incompatible with existing programs. compatibility.tex:1104:Valid \CppXI{} code could declare a global placement allocation function and compatibility.tex:1112:might match a predefined usual (non-placement) compatibility.tex:1294:Certain integer literals larger than can be represented by \tcode{long} could compatibility.tex:1431:A valid \CppIII{} program could get a different result than this compatibility.tex:1845:which might expect to be able to modify its argument. compatibility.tex:2091:Furthermore, any use of the uninitialized object could be a compatibility.tex:2149:declarations could render the code confusing for users. compatibility.tex:2541:Leaving the choice of signedness to implementations could lead to compatibility.tex:2579:struct, the struct tag could be declared in the scope of the compatibility.tex:2591:struct could be exported to the scope of the enclosing struct. containers.tex:768:might define). containers.tex:2872:& \returns An upper bound on the number of buckets that \tcode{b} might declarations.tex:925:an invocation of the function or constructor could be an evaluated subexpression of a core declarations.tex:2389:the resolution is to consider any construct that could possibly declarations.tex:2417:The resolution is that any construct that could possibly be a declarations.tex:6088:which might mean defining them as deleted. declarations.tex:8854:a warning that an implementation might otherwise issue declarations.tex:9115:warning if a function marked \tcode{[[noreturn]]} might return. future.tex:208:could become deleted\iref{dcl.fct.def.delete}. iostreams.tex:3651:might fail by throwing an exception prematurely. iostreams.tex:3887:Failure may occur because the input sequence could not be backed up, or if for some iostreams.tex:3888:other reason the pointers could not be set consistent with the constraints. iostreams.tex:6141:which might throw an exception. iostreams.tex:9623:implementation might well provide an overriding definition for this function iostreams.tex:13772:The file exists but the type could not be determined \ lex.tex:61:occur, although in practice different phases might be folded together.} lex.tex:347:If the next character begins a sequence of characters that could be the prefix lex.tex:365:characters that could constitute a preprocessing token, even if that lex.tex:564:that resembles an escape sequence might result in an error, be interpreted as the lex.tex:1894:characters that could match that non-terminal. locales.tex:2085:that it could not convert \ locales.tex:3834:If it finds an abbreviation that is followed by characters that could numerics.tex:4121: if the \tcode{random_device} could not be initialized. numerics.tex:4164: if a random number could not be obtained. overloading.tex:735:denotes one or more functions that might be called. overloading.tex:988:user-defined operator function might be declared that implements overloading.tex:2164:might be at least as good as overloading.tex:4202:function or function template (it could be a friend preprocessor.tex:1023:at the point at which a preprocessing directive could begin, preprocessor.tex:1608:The behavior might cause translation to fail or cause the translator or preprocessor.tex:1790:\indextext{stdc_mb_might_neq_wc@\mname{STDC_MB_MIGHT_NEQ_WC}}% ranges.tex:1794:which could potentially reference a range regex.tex:872:expression could match the specified character sequence. \ statements.tex:1007:any deadlock around execution of the initializer. Deadlocks might strings.tex:3679:\tcode{strtoll}, or \tcode{strtoull} reports that no conversion could be strings.tex:3714:\tcode{strtold} reports that no conversion could be performed. Throws strings.tex:3783:\tcode{wcstoull} reports that no conversion could be performed. Throws strings.tex:3815:conversion could be performed. Throws \tcode{out_of_range} if \tcode{wcstof}, \tcode{wcstod}, or styles.tex:196: % A section heading might have set \everypar to apply a \clubpenalty styles.tex:297:% handle semicolons and closing braces (could be in \lstdefinelanguage as well) styles.tex:333: \lstsaved@closebrace % might invoke \lst@NewLine support.tex:4126:\footnote{That is, \tcode{a < b}, \tcode{a == b}, and \tcode{a > b} might all be \tcode{false}.} support.tex:5627:\footnote{Such initialization might occur because it is the first odr-use\iref{basic.def.odr} of that variable.}; or templates.tex:2574:and type and a member function template of the same name, which could be templates.tex:3361:template argument values.\footnote{There is no way in which they could be used.} templates.tex:3894:the use of a function template specialization might be ambiguous because templates.tex:6492:which could involve more than one template. threads.tex:641:\tcode{bad_alloc} if memory could not be allocated for the stop state. threads.tex:7216:could not be allocated. threads.tex:7343:could not be allocated. threads.tex:7535:\item \tcode{bad_alloc} if memory for the new shared state could not be allocated. time.tex:1061:done because the representation might be a class type with behavior which time.tex:9175:os << tp << " is ambiguous. It could be\n" time.tex:9264:and \tcode{offset - save} suggests what offset this \tcode{time_zone} might use time.tex:9270:There is no guarantee what \tcode{time_point} might return such a \tcode{sys_info} utilities.tex:4583:the \tcode{variant} object might not hold a value. utilities.tex:4667:the \tcode{variant} might not hold a value. utilities.tex:4708:the \tcode{variant} might not hold a value. utilities.tex:7530:safety.\footnote{\tcode{pointer_safety::preferred} might be returned to indicate utilities.tex:9874:constructor fails} exception when a resource other than memory could not be obtained. utilities.tex:9928:when a resource other than memory could not be obtained. utilities.tex:15895: that instantiation could yield a different result
jensmaurer
commented
3 years ago List of "should" or "may" in notes (228 instances):
algorithms.tex:207:Programmers for whom object identity is important should consider
algorithms.tex:264:Consequently, the algorithms may not
algorithms.tex:391:This implies that user-supplied function objects should not rely on
algorithms.tex:394:is important should consider using a wrapping iterator
algorithms.tex:416:may be interleaved on a single thread of execution,
algorithms.tex:502:This means that multiple function object invocations may be interleaved
algorithms.tex:3155:\tcode{f} may apply non-constant functions through the dereferenced iterator.
algorithms.tex:3190:\tcode{f} may apply non-constant functions through the dereferenced iterator.
algorithms.tex:3207:since parallelization may not permit efficient state accumulation.
algorithms.tex:3231:\tcode{f} may apply non-constant functions.
algorithms.tex:3283:\tcode{f} may apply non-constant functions through the dereferenced iterator.
algorithms.tex:3322:\tcode{f} may apply non-constant functions through the dereferenced iterator.
algorithms.tex:3357:\tcode{f} may apply non-constant functions.
algorithms.tex:4401:there may be a performance cost
algorithms.tex:5299:there may be a performance cost
algorithms.tex:5486: there may be a performance cost
algorithms.tex:7022:there may be a performance cost if \tcode{first}'s value type
algorithms.tex:9540:the behavior of \tcode{exclusive_scan} may be nondeterministic.
algorithms.tex:9667:the behavior of \tcode{inclusive_scan} may be nondeterministic.
algorithms.tex:9742:the behavior of \tcode{transform_exclusive_scan} may be nondeterministic.
algorithms.tex:9846:the behavior of \tcode{transform_inclusive_scan} may be nondeterministic.
atomics.tex:530:should not produce \tcode{r1 == r2 == 42}, since the store of 42 to \tcode{y} is only
atomics.tex:638:Operations that are lock-free should also be address-free. That is,
atomics.tex:640:communicate atomically. The implementation should not depend on any
atomics.tex:1603:not also statically initializable may be difficult to use.
atomics.tex:3445:the operations should also be address-free.
basic.tex:695:appearing in the type of \tcode{D} may result
basic.tex:698:may still denote different types in different translation units.
basic.tex:825:friend declarations\iref{class.friend} may introduce a (possibly not
basic.tex:827:that region. Local extern declarations\iref{basic.link} may introduce
basic.tex:2840:but may serve as the name of an enumeration with linkage\iref{dcl.enum}.
basic.tex:4549:This may introduce a dangling reference.
basic.tex:5820:In some cases, there may instead be undefined behavior. Much of this
basic.tex:5863:threads may observe modifications to different objects in inconsistent orders.
basic.tex:6192:may alias is also generally precluded, since this may violate the coherence
basic.tex:6199:shared memory location may not preserve the semantics of the \Cpp{} program as
basic.tex:6235: may prevent progress of a lock-free execution.
basic.tex:6249: may prevent forward progress,
basic.tex:6254: Implementations should ensure
basic.tex:6318:General-purpose implementations should provide these guarantees.
basic.tex:6357:For example, some kinds of synchronization between threads of execution may only
basic.tex:6388:forward progress guarantee delegation on $C$, this may also temporarily
basic.tex:6578: // may be statically initialized to \tcode{0.0} or
basic.tex:6581:double d1 = fd(); // may be initialized statically or dynamically to \tcode{1.0}
basic.tex:6679:Such points should be chosen in a way that allows the programmer to avoid deadlocks.
classes.tex:199:that may be at a zero offset in \tcode{X}.
classes.tex:875:a program. There may be more than one
classes.tex:1535:All forms of copy/move constructor may be declared for a class.
classes.tex:1656:expressions that otherwise would have invoked the move constructor may instead invoke
classes.tex:1821:More than one form of copy assignment operator may be declared for a class.
classes.tex:1896:than one form of move assignment operator may be declared for a class.
classes.tex:2575:A default constructor may be an explicit constructor; such a constructor
classes.tex:2605:it may be called for implicit type conversions.
classes.tex:3607:same type. A base class subobject may be of zero size\iref{class};
classes.tex:4221:a pure virtual function may override a virtual function which is not
classes.tex:5161:A friend declaration may be the
classes.tex:5669:for the hidden base class may be specified using a qualified name.
classes.tex:5828:corresponding \grammarterm{mem-initializer}{s} may be omitted.
classes.tex:6803:may differ from the implicit exception specification of
classes.tex:6930:A synthesized three-way comparison may be ill-formed
concepts.tex:398:different type. \tcode{C} may be a reference type.
containers.tex:456:The \tcode{end()} iterator does not refer to any element, so it may be invalidated.
containers.tex:603:but specialized allocators may choose a different definition.
containers.tex:752:\tcode{x[0] = 5} and \tcode{*x.begin() = 10} executed concurrently may result in a data
containers.tex:755:may race with \tcode{y[1] = true}.
containers.tex:773:offer the programmer different complexity trade-offs and should be used
containers.tex:776:is the type of sequence container that should be used by default.
containers.tex:778:should be used when the container has a fixed size known during translation.
containers.tex:780:should be used when there are frequent insertions and deletions from the
containers.tex:878:\tcode{args} may directly or indirectly refer to
containers.tex:3492:takes linear time, may exit via an exception, and does not cause iterators to
declarations.tex:113:entity may appear at the start of the declaration and after the
declarations.tex:1090:A call to an inline function or a use of an inline variable may be encountered
declarations.tex:3145:that specify the bounds of the arrays may be omitted.
declarations.tex:3944:may not appear in a default argument of a member function;
declarations.tex:4369:Copy-initialization may invoke a move\iref{class.copy.ctor}.
declarations.tex:5124:An aggregate array or an aggregate class may contain elements of a
declarations.tex:7276:does not introduce a name and thus may be declared using an
declarations.tex:7951:Two \grammarterm{using-declaration}{s} may introduce functions with the same
declarations.tex:8176:example, a particular language linkage may be associated with a
declarations.tex:8347:with C language linkage may appear in the
declarations.tex:8570:Each implementation should choose a distinctive name for the
declarations.tex:8727:program, but may result in generation of more efficient code.
diagnostics.tex:847:custom \tcode{error_category} types should create a single object of each
diagnostics.tex:1053:and unbounded, and some may not correspond to any POSIX \tcode{errno} value. Thus
exceptions.tex:359:Consequently, destructors should generally catch exceptions and not let them propa-gate.
expressions.tex:76:The implementation may regroup operators according to
expressions.tex:275:A glvalue may have complete or incomplete non-\tcode{void} type.
expressions.tex:425:In an unevaluated operand, a non-static class member may be
expressions.tex:1748:The function call operator or operator template may be constrained\iref{temp.constr.decl}
expressions.tex:2849:\tcode{const_cast} may be the product of replacing a
expressions.tex:4029:Subject to the restrictions in this subclause, an expression may be cast
expressions.tex:4085:may produce undefined behavior\iref{dcl.type.cv}.
expressions.tex:4460:Any number of coroutines may be successively resumed in this fashion,
expressions.tex:4687:The \grammarterm{type-id} may be a cv-qualified type, in which case the
expressions.tex:4918:The set of allocation and deallocation functions that may be called
expressions.tex:4920:may include functions that do not perform allocation or deallocation;
expressions.tex:6731:statement about how the target of the assignment may be aliased in general.
expressions.tex:6847: Such a class may have a non-trivial destructor.
expressions.tex:7164:Such expressions may be
expressions.tex:7211:Such expressions may be used in \tcode{new}
expressions.tex:7274:execution.\footnote{Nonetheless, implementations should provide consistent results,
future.tex:573:allocated, and hence should be freed by the destructor for the
future.tex:2745:This operation may need to initialize locks.
intro.tex:887:semantics may be defined by each implementation.
iostreams.tex:11151:Care should be taken to ensure that this does not result in deadlock.
iostreams.tex:11997:For wide portability, users may wish to limit \grammarterm{filename}
iostreams.tex:12100:Some operating systems may have no unambiguous way to distinguish between native format and generic format arguments.
iostreams.tex:12129:The implementation may generate the generic format pathname
iostreams.tex:12584:and may not be portable between operating systems.
iostreams.tex:13118:it may not be the case that \tcode{p.stem() + p.extension() == p.filename()},
iostreams.tex:13724: and the character sequence should always be interpreted in the same way.
iostreams.tex:14625:Programs performing directory iteration may wish to test if the
iostreams.tex:14628:walking directory trees for purposes of removing and renaming entries may wish
iostreams.tex:14838:then the end iterator may be unreachable.
iostreams.tex:15149:and many other kinds of errors occur frequently in file system operations, users should be aware
iostreams.tex:15150:that any filesystem operation function, no matter how apparently innocuous, may encounter
iostreams.tex:15642: identify that the link is to a directory. Portable code should use \tcode{create_directory_symlink()} to create directory symlinks rather than \tcode{create_symlink()}
iostreams.tex:15758: global variable. It may be changed unexpectedly by third-party or system
iostreams.tex:15785: global state. It may be changed unexpectedly by a third-party or system
iostreams.tex:16309:implementation may use some other mechanism.
iostreams.tex:16510:\item Otherwise, the rename may include the following effects:
iostreams.tex:16516: but may be an error on other operating systems.
iostreams.tex:16579:\tcode{available} may be
iterators.tex:1441:transparency.) Algorithms on weakly incrementable types should never attempt to pass
iterators.tex:1442:through the same incrementable value twice. They should be single-pass algorithms. These algorithms
iterators.tex:1671:Algorithms on output iterators should never attempt to pass through the same iterator twice.
iterators.tex:1672:They should be single-pass algorithms.
iterators.tex:2028:Algorithms on input iterators should never attempt to pass through the same iterator twice.
iterators.tex:2029:They should be
iterators.tex:2093:Algorithms on output iterators should never attempt to pass through the same iterator twice.
iterators.tex:2094:They should be single-pass algorithms.
lex.tex:146:The process of analyzing and translating the tokens may occasionally
lex.tex:171:Some or all of these may be supplied from a
lex.tex:177:This may include
lex.tex:1397:the actual compiler implementation may use its own native character set,
lib-intro.tex:1583:indeterminate values may cause undefined behavior.
lib-intro.tex:1671: compare equal should be very small, approaching \tcode{1.0 / numeric_limits
jensmaurer
commented
3 years ago __STDC_MB_MIGHT_NEQ_WC__ is a good one for eradicating "might" in normative text.
We use "could" both as past tense of "can" and as a conditional form. Example: [class.mem.general] p9 "In a member-declarator for a bit-field, the constant-expression is parsed as the longest sequence of tokens that could syntactically form a constant-expression."
jensmaurer
commented
3 years ago After the fixes in cplusplus/draft#4194, there are still 90 occurrences left of shall/should/may inside notes, and 75 occurrences of "might "or "could" in normative text.
We should form an opinion where we want to go with categories such as
Note that my check.sh extension does not cover footnotes, because they are harder to identify correctly across multiple lines (they don't have nice begin/end markers, which might be a good idea to fix regardless).
I think the "Implementations should" phrases should become normative; do we want to prefix these with "Recommended practice:" \recommended (in a separate paragraph), which seems to be a good idea?
What about "The user should..."; those seem to need some harsher rephrasing?#
Some categories for "could":
jensmaurer
commented
3 years ago Are we ok that "might" in notes is fine in expressing an (English-level) hypothetical possibility?
zygoloid
commented
3 years ago Direction:
I'll express to ISO why we're leaving could, might, must alone.
jensmaurer
commented
3 years ago Editorial meeting 2020-09-16:
jensmaurer
commented
3 years ago The linked pull request cplusplus/draft#4194 now addresses all "shall", "should", "may" inside notes. Footnotes are not yet machine-checked.
JohelEGP
commented
3 years ago * "could", "might": these are fine English words, and for example are used in the ISO Drafting Directives. No change. * "could": don't do anyhting; used in the drafting directives * "might": don't do anyhting; used in the drafting directives
It also says:
It is not the intention that the ISO/IEC Directives, Part 2 follow the same structure and drafting rules as International Standards and associated publications (referred to collectively as documents, see 3.1.1). - ISO/IEC Directives, Part 2
The drafting directives are not a document.
zygoloid
commented
3 years ago It is not the intention that the ISO/IEC Directives, Part 2 follow the same structure and drafting rules as International Standards
This is a bit of a silly claim for them to be making; it's obvious from the structure and wording of their document that they are attempting to follow their own rules. But I suspect the intent of this is precisely so that they can say "you still have to follow our rules even if we didn't manage to do so".
However...
The ISO Drafting Directives include "could" in an example of how to draft standards, see section 25.6 (it's in an example of an example, in a subclause named "Examples" within a Clause named "Examples" that gives examples of examples, so I think it's an example :) ). And there is no rule in the directives about use of "could". So I think we're completely fine there. (ISO's complaint about our use of "could" came from them first misinterpreting a use of "must" as an attempt to say "shall" and then saying "ISO doesn't define what "could" means, so you can't use "could" with "shall", which is just silly.)
For "might", there is a rule, and the rule is simply "do not use "might" when you mean "may"". We've checked that we're not using "might" where we mean "may", so I think we're fine to leave the remaining uses of both "could" and "might" alone.
burblebee
commented
3 years ago Remember that when merging to master, we want to apply this diff to [expr.cond], and possibly reword "disregarded" as well:
diff --git a/source/expressions.tex b/source/expressions.tex
index 0140bf3c..a5ef12bb 100644
--- a/source/expressions.tex
+++ b/source/expressions.tex
@@ -6434,13 +6434,16 @@ of the operand expression \tcode{E2} as follows:
\begin{itemize}
\item If \tcode{E2} is an lvalue, the target type is
-``lvalue reference to \tcode{T2}'', subject to the
-constraint that in the conversion the reference binds
-directly\iref{dcl.init.ref} to a glvalue.
+``lvalue reference to \tcode{T2}'', and
+implicit conversion sequences for which
+the reference does not bind directly\iref{dcl.init.ref}
+to a glvalue are disregarded.
\item If \tcode{E2} is an xvalue, the target type is
-``rvalue reference to \tcode{T2}'',
-subject to the constraint that the reference binds directly.
+``rvalue reference to \tcode{T2}'', and
+implicit conversion sequences for which
+the reference does not bind directly
+are disregarded.
\item If \tcode{E2} is a prvalue or if neither of the conversion sequences above can be
formed and at least one of the operands has (possibly cv-qualified) class type:In chat, zygoloid added: for the improved version: ", and an implicit conversion sequence can only be formed if the reference would bind directly to a glvalue." I can't decide whether this is "and" or "but" territory. I'm leaning towards "but"
jensmaurer
commented
3 years ago Accepted with modification.
ISO/IEC Directives, Part 2, 2016, Clause 7: “shall” is used to express a requirement “should” is used to express a recommendation “may” is used to express a permission “can” is used to express a possibility (for information “must” may only be used to express an external constraint) Also, “could”, “might”, are not recognised ISO verbal forms.
Please check all provisions to ensure that verbal forms are used correctly. Please remove occurrences of “could” and “might” and replace them with “can” to express possibility even if it sounds different from “regular” English. Verbal forms can also affect certain parts of the document. For example, requirements are not allowed in the Introduction, Scope, definitions, Notes, or examples; recommendations and permissions are not allowed in Notes, etc.