This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.

### 2114. Incorrect "contextually convertible to `bool`" requirements

Section: 16.4.4.4 [nullablepointer.requirements], 25.3.5.3 [input.iterators], 25.3.5.7 [random.access.iterators], 27.1 [algorithms.general], 27.8 [alg.sorting], 33.2.1 [thread.req.paramname] Status: Resolved Submitter: Daniel Krügler Opened: 2011-12-09 Last modified: 2022-11-22

Priority: 3

View all issues with Resolved status.

Discussion:

As of 16.4.4.2 [utility.arg.requirements] Table 17/18, the return types of the expressions

>     a == b

or

>     a < b

for types satisfying the `EqualityComparable` or `LessThanComparable` types, respectively, are required to be "convertible to `bool`" which corresponds to a copy-initialization context. But several newer parts of the library that refer to such contexts have lowered the requirements taking advantage of the new terminology of "contextually convertible to `bool`" instead, which corresponds to a direct-initialization context (In addition to "normal" direct-initialization constructions, operands of logical operations as well as `if` or `switch` conditions also belong to this special context).

One example for these new requirements are input iterators which satisfy `EqualityComparable` but also specify that the expression

>     a != b

shall be just "contextually convertible to `bool`". The same discrepancy exists for requirement set `NullablePointer` in regard to several equality-related expressions.

For random access iterators we have

> `a < b` contextually convertible to `bool`

as well as for all derived comparison functions, so strictly speaking we could have a random access iterator that does not satisfy the `LessThanComparable` requirements, which looks like an artifact to me.

Even if we keep with the existing requirements based on `LessThanComparable` or `EqualityComparable` we still would have the problem that some current specifications are actually based on the assumption of implicit convertibility instead of "explicit convertibility", e.g. 20.3.1.6 [unique.ptr.special] p3:

>     template <class T1, class D1, class T2, class D2>
>     bool operator!=(const unique_ptr<T1, D1>& x, const unique_ptr<T2, D2>& y);

> > -3- Returns: `x.get() != y.get()`.

Similar examples exist in 20.3.1.3.3 [unique.ptr.single.dtor] p2, 20.3.1.3.4 [unique.ptr.single.asgn] p9, 20.3.1.3.5 [unique.ptr.single.observers] p1+3+8, etc.

In all these places the expressions involving comparison functions (but not those of the conversion of a `NullablePointer` to `bool`!) assume to be "convertible to `bool`". I think this is a very natural assumption and all delegations of the comparison functions of some type `X` to some other API type `Y` in third-party code does so assuming that copy-initialization semantics will just work.

The actual reason for using the newer terminology can be rooted back to LWG 556. My hypotheses is that the resolution of that issue also needs a slight correction. Why so?

The reason for opening that issue were worries based on the previous "convertible to `bool`" wording. An expressions like "`!pred(a, b)`" might not be well-formed in those situations, because `operator!` might not be accessible or might have an unusual semantics (and similarly for other logical operations). This can indeed happen with unusual proxy return types, so the idea was that the evaluation of `Predicate`, `BinaryPredicate` (27.1 [algorithms.general] p8+9), and `Compare` (27.8 [alg.sorting] p2) should be defined based on contextual conversion to `bool`. Unfortunately this alone is not sufficient: In addition, I think, we also want the predicates to be (implicitly) convertible to `bool`! Without this wording, several conditions are plain wrong, e.g. 27.6.6 [alg.find] p2, which talks about "`pred(*i) != false`" (`find_if`) and "`pred(*i) == false`" (`find_if_not`). These expressions are not within a boolean context!

While we could simply fix all these places by proper wording to be considered in a "contextual conversion to `bool`", I think that this is not the correct solution: Many third-party libraries already refer to the previous C++03 `Predicate` definition — it actually predates C++98 and is as old as the SGI specification. It seems to be a high price to pay to switch to direct initialization here instead of fixing a completely different specification problem.

A final observation is that we have another definition for a `Predicate` in 33.2.1 [thread.req.paramname] p2:

> If a parameter is `Predicate`, `operator()` applied to the actual template argument shall return a value that is convertible to `bool`.

The problem here is not that we have two different definitions of `Predicate` in the standard — this is confusing, but this fact alone is not a defect. The first (minor) problem is that this definition does not properly apply to function objects that are function pointers, because `operator()` is not defined in a strict sense. But the actually worse second problem is that this wording has the very `same` problem that has originally lead to LWG 556! We only need to look at 33.7.4 [thread.condition.condvar] p15 to recognice this:

>     while (!pred())
>       wait(lock);

The negation expression here looks very familiar to the example provided in LWG 556 and is sensitive to the same "unusual proxy" problem. Changing the 33.2.1 [thread.req.paramname] wording to a corresponding "contextual conversion to `bool`" wouldn't work either, because existing specifications rely on "convertible to `bool`", e.g. 33.7.4 [thread.condition.condvar] p32+33+42 or 33.7.5 [thread.condition.condvarany] p25+26+32+33.

To summarize: I believe that LWG 556 was not completely resolved. A pessimistic interpretation is, that even with the current wording based on "contextually convertible to `bool`" the actual problem of that issue has not been fixed. What actually needs to be required here is some normative wording that basically expresses something along the lines of:

> The semantics of any contextual conversion to `bool` shall be equivalent to the semantics of any implicit conversion to `bool`.

This is still not complete without having concepts, but it seems to be a better approximation. Another way of solving this issue would be to define a minimum requirements table with equivalent semantics. The proposed wording is a bit simpler but attempts to express the same thing.

[2012, Kona]

Agree with Daniel that we potentially broke some C++03 user code, accept the changes striking "contextually" from tables. Stefan to provide revised wording for section 25, and figure out changes to section 30.

Move to open, and then to Review when updated wording from Stefan is available.

[2012-10-12, STL comments]

1. The current proposed resolution still isn't completely satisfying. It would certainly be possible for the Standard to require these various expressions to be implicitly and contextually convertible to `bool`, but that would have a subtle consequence (which, I will argue, is undesirable - regardless of the fact that it dates all the way back to C++98/03). It would allow users to provide really wacky types to the Standard Library, with one of two effects:

   1. Standard Library implementations would have to go to great lengths to respect such wacky types, essentially using `static_cast<bool>` when invoking any predicates or comparators.

   2. Otherwise, such wacky types would be de facto nonportable, because they would make Standard Library implementations explode.

   Effect B is the status quo we're living with today. What Standard Library implementations want to do with `pred(args)` goes beyond "`if (pred(args))`" (C++03), contextually converting `pred(args)` to `bool` (C++11), or implicitly and contextually converting `pred(args)` to `bool` (the current proposed resolution). Implementations want to say things like:

   >     if (pred(args))
   >     if (!pred(args))
   >     if (cond && pred(args))
   >     if (cond && !pred(args))

   These are real examples taken from Dinkumware's implementation. There are others that would be realistic ("`pred(args) && cond`", "`cond || pred(args)`", etc.)

   Although negation was mentioned in this issue's Discussion section, and in LWG 556's, the current proposed resolution doesn't fix this problem. Requiring `pred(args)` to be implicitly and contextually convertible to `bool` doesn't prevent `operator!()` from being overloaded and returning `std::string` (as a wacky example). More ominously, it doesn't prevent `operator&&()` and `operator||()` from being overloaded and destroying short-circuiting.

2. I would like LWG input before working on Standardese for a new proposed resolution. Here's an outline of what I'd like to do:

   1. Introduce a new "concept" in 16.4.4 [utility.requirements], which I would call `BooleanTestable` in the absence of better ideas.

   2. Centralize things and reduce verbosity by having everything simply refer to `BooleanTestable` when necessary. I believe that the tables could say "Return type: `BooleanTestable`", while Predicate/BinaryPredicate/Compare would need the incantation "shall satisfy the requirements of BooleanTestable".

   3. Resolve the tug-of-war between users (who occasionally want to do weird things) and implementers (who don't want to have to contort their code) by requiring that:

      1. Given a `BooleanTestable x`, `x` is both implicitly and contextually convertible to `bool`.

      2. Given a `BooleanTestable x`, `!x` is `BooleanTestable`. (This is intentionally "recursive".)

      3. Given a `BooleanTestable x`, `bool t = x, t2(x), f = !x;` has the postcondition `t == t2 && t != f`.

      4. Given a `BooleanTestable x` and a `BooleanTestable y` of possibly different types, "`x && y`" and "`x || y`" invoke the built-in `operator&&()` and `operator||()`, triggering short-circuiting.

      5. `bool` is `BooleanTestable`.

   I believe that this simultaneously gives users great latitude to use types other than `bool`, while allowing implementers to write reasonable code in order to get their jobs done. (If I'm forgetting anything that implementers would want to say, please let me know.)

3. About requirement (I): As Daniel patiently explained to me, we need to talk about both implicit conversions and contextual conversions, because it's possible for a devious type to have both "`explicit operator bool()`" and "`operator int()`", which might behave differently (or be deleted, etc.).

4. About requirement (IV): This is kind of tricky. What we'd like to say is, "`BooleanTestable` can't ever trigger an overloaded logical operator". However, given a perfectly reasonable type `Nice` - perhaps even `bool` itself! - other code (perhaps a third-party library) could overload `operator&&(Nice, Evil)`. Therefore, I believe that the requirement should be "no first use" - the Standard Library will ask for various `BooleanTestable` types from users (for example, the result of "`first != last`" and the result of "`pred(args)`"), and as long as they don't trigger overloaded logical operators with each other, everything is awesome.

5. About requirement (V): This is possibly redundant, but it's trivial to specify, makes it easier for users to understand what they need to do ("oh, I can always achieve this with `bool`"), and provides a "base case" for requirement (IV) that may or may not be necessary. Since `bool` is `BooleanTestable`, overloading `operator&&(bool, Other)` (etc.) clearly makes the `Other` type non-`BooleanTestable`.

Previous resolution from Daniel [SUPERSEDED]:

> This wording is relative to the FDIS.

> 1. Change Table 25 — "`NullablePointer` requirements" in 16.4.4.4 [nullablepointer.requirements] as indicated:

>    Table 25 — `NullablePointer` requirements
>    Expression | Return type | Operational semantics
>    --- | --- | ---
>    `[…]`
>    `a != b` | contextually convertible to `bool` | `!(a == b)`
>    `a == np np == a` | contextually convertible to `bool` | `a == P()`
>    `a != np np != a` | contextually convertible to `bool` | `!(a == np)`

> 2. Change Table 107 — "Input iterator requirements" in 25.3.5.3 [input.iterators] as indicated:

>    Table 107 — Input iterator requirements (in addition to Iterator)
>    Expression | Return type | Operational semantics | Assertion/note pre-/post-condition
>    --- | --- | --- | ---
>    `a != b` | contextually convertible to `bool` | `!(a == b)` | pre: `(a, b)` is in the domain of `==`.
>    `[…]`

> 3. Change Table 111 — "Random access iterator requirements" in 25.3.5.7 [random.access.iterators] as indicated:

>    Table 111 — Random access iterator requirements (in addition to bidirectional iterator)
>    Expression | Return type | Operational semantics | Assertion/note pre-/post-condition
>    --- | --- | --- | ---
>    `[…]`
>    `a < b` | contextually convertible to `bool` | `b - a > 0` | `<` is a total ordering relation
>    `a > b` | contextually convertible to `bool` | `b < a` | `>` is a total ordering relation opposite to `<`.
>    `a >= b` | contextually convertible to `bool` | `!(a < b)` |
>    `a <= b` | contextually convertible to `bool` | `!(a > b)` |

> 4. Change 27.1 [algorithms.general] p8+9 as indicated:

>    > -8- The `Predicate` parameter is used whenever an algorithm expects a function object (22.10 [function.objects]) that, when applied to the result of dereferencing the corresponding iterator, returns a value testable as `true`. In other words, if an algorithm takes `Predicate pred` as its argument and first as its iterator argument, it should work correctly in the construct `pred(*first)` implicitly or contextually converted to `bool` (Clause 7.3 [conv]). The function object `pred` shall not apply any non-constant function through the dereferenced iterator.

>    > -9- The `BinaryPredicate` parameter is used whenever an algorithm expects a function object that when applied to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type `T` when `T` is part of the signature returns a value testable as `true`. In other words, if an algorithm takes `BinaryPredicate binary_pred` as its argument and `first1` and `first2` as its iterator arguments, it should work correctly in the construct `binary_pred(*first1, *first2)` implicitly or contextually converted to `bool` (Clause 7.3 [conv]). `BinaryPredicate` always takes the first iterator's `value_type` as its first argument, that is, in those cases when `T` value is part of the signature, it should work correctly in the construct `binary_pred(*first1, value)` implicitly or contextually converted to `bool` (Clause 7.3 [conv]). `binary_pred` shall not apply any non-constant function through the dereferenced iterators.

> 5. Change 27.8 [alg.sorting] p2 as indicated:

>    > -2- `Compare` is a function object type (22.10 [function.objects]). The return value of the function call operation applied to an object of type `Compare`, when implicitly or contextually converted to `bool` (7.3 [conv]), yields `true` if the first argument of the call is less than the second, and `false` otherwise. `Compare comp` is used throughout for algorithms assuming an ordering relation. It is assumed that `comp` will not apply any non-constant function through the dereferenced iterator.

> 6. Change 33.2.1 [thread.req.paramname] p2 as indicated:

>    > -2- If a parameter is `Predicate`, operator() applied to the actual template argument shall return a value that is convertible to `bool` `Predicate` is a function object type (22.10 [function.objects]). The return value of the function call operation applied to an object of type `Predicate`, when implicitly or contextually converted to `bool` (7.3 [conv]), yields `true` if the corresponding test condition is satisfied, and `false` otherwise.

[2014-05-20, Daniel suggests concrete wording based on STL's proposal]

The presented wording follows relatively closely STL's outline with the following notable exceptions:

1. A reference to `BooleanTestable` in table "Return Type" specifications seemed very unusual to me and I found no "prior art" for this in the Standard. Instead I decided to follow the usual style to add a symbol with a specific meaning to a specific paragraph that specifies symbols and their meanings.

2. STL's requirement IV suggested to directly refer to built-in operators `&&` and `||`. In my opinion this concrete requirement isn't needed if we simply require that two `BooleanTestable` operands behave equivalently to two those operands after conversion to `bool` (each of them).

3. I couldn't find a good reason to require normatively that type `bool` meets the requirements of `BooleanTestable`: My assertion is that after having defined them, the result simply falls out of this. But to make this a bit clearer, I added also a non-normative note to these effects.

[2014-06-10, STL comments]

In the current wording I would like to see changed the suggested changes described by bullet #6:

1. In 24.2.2.1 [container.requirements.general] p4 undo the suggested change

2. Then change the 7 occurrences of "convertible to `bool`" in the denoted tables to "`bool`".

[2015-05-05 Lenexa]

STL: Alisdair wanted to do something here, but Daniel gave us updated wording.

[2015-07 Telecon]

Alisdair: Should specify we don't break short circuiting.
Ville: Looks already specified because that's the way it works for bool.
Geoffrey: Maybe add a note about the short circuiting.
B2/P2 is somewhat ambiguous. It implies that B has to be both implicitly convertible to bool and contextually convertible to bool.
We like this, just have nits.
Status stays Open.
Marshall to ping Daniel with feedback.

[2016-02-27, Daniel updates wording]

1. The revised wording has been updated from N3936 to N4567.

2. To satisfy the Kona 2015 committee comments, the wording in [booleantestable.requirements] has been improved to better separate the two different requirements of "can be contextually converted to `bool`" and "can be implicitly converted to `bool`. Both are necessary because it is possible to define a type that has the latter property but not the former, such as the following one:

   > 2016-08-07, Daniel: The below example has been corrected to reduce confusion about the performed conversions as indicated by the delta markers:

   >     using Bool = int;

   >     struct OddBoolean
   >     {
   >       explicit operator bool() const = delete;
   >       operator Bool() const;
   >       OddBoolean(bool) = delete;
   >       OddBoolean(Bool){}
   >     } ob;

   >     bool b2 = ob; // OK
   >     bool b1(ob);  // Error
   >     OddBoolean b2 = true; // OK
   >     OddBoolean b1(true);  // Error

3. In [booleantestable.requirements] a note has been added to ensure that an implementation is not allowed to break any short-circuiting semantics.

4. I decided to separate LWG 2587/2588 from this issue. Both these issues aren't exactly the same but depending on the committee's position, their resolution might benefit from the new vocabulary introduced here.

[2021-06-25; Daniel comments]

The paper P2167R1 is provided to resolve this issue.

[2022-05-01; Daniel comments]

The paper P2167R2 is provided to resolve this issue.

Previous resolution [SUPERSEDED]:

> This wording is relative to N4567.

> 1. Change 16.4.4.2 [utility.arg.requirements] p1, Table 17 — "EqualityComparable requirements", and Table 18 — "LessThanComparable requirements" as indicated:

>    > -1- […] In these tables, `T` is an object or reference type to be supplied by a C++ program instantiating a template; `a`, `b`, and `c` are values of type (possibly `const`) `T`; `s` and `t` are modifiable lvalues of type `T`; `u` denotes an identifier; `rv` is an rvalue of type `T`; and `v` is an lvalue of type (possibly `const`) `T` or an rvalue of type `const T`; and `BT` denotes a type that meets the `BooleanTestable` requirements ([booleantestable.requirements]).

>    > […]

>    > > Table 17 — `EqualityComparable` requirements [equalitycomparable]
>    > > Expression | Return type | Requirement
>    > > --- | --- | ---
>    > > `a == b` | convertible to `bool` `BT` | `==` is an equivalence relation, that is, it has the following properties: […]

>    > […]

>    > > Table 18 — `LessThanComparable` requirements [lessthancomparable]
>    > > Expression | Return type | Requirement
>    > > --- | --- | ---
>    > > `a < b` | convertible to `bool` `BT` | `<` is a strict weak ordering relation (27.8 [alg.sorting])

> 2. Between 16.4.4.3 [swappable.requirements] and 16.4.4.4 [nullablepointer.requirements] insert a new sub-clause as indicated:

>    > ?.?.?.? `BooleanTestable` requirements [booleantestable.requirements]

>    > > -?- A `BooleanTestable` type is a boolean-like type that also supports conversions to `bool`. A type `B` meets the `BooleanTestable` requirements if the expressions described in Table ?? are valid and have the indicated semantics, and if `B` also satisfies all the other requirements of this sub-clause [booleantestable.requirements].

>    > > An object `b` of type `B` can be implicitly converted to `bool` and in addition can be contextually converted to `bool` (Clause 4). The result values of both kinds of conversions shall be equivalent.

>    > > [Example: The types `bool`, `std::true_type`, and `std::bitset<>::reference` are `BooleanTestable` types. — end example]

>    > > For the purpose of Table ??, let `B2` and `Bn` denote types (possibly both equal to `B` or to each other) that meet the `BooleanTestable` requirements, let `b1` denote a (possibly `const`) value of `B`, let `b2` denote a (possibly `const`) value of `B2`, and let `t1` denote a value of type `bool`.

>    > > [Note: These rules ensure what an implementation can rely on but doesn't grant it license to break short-circuiting behavior of a `BooleanTestable` type. — end note]

> 3. Somewhere within the new sub-clause [booleantestable.requirements] insert the following new Table (?? denotes the assigned table number):

>    > Table ?? — `BooleanTestable` requirements [booleantestable]
>    > Expression | Return type | Operational semantics
>    > --- | --- | ---
>    > `bool(b1)` | `bool` | Remarks: `bool(b1) == t1` for every value `b1` implicitly converted to `t1`.
>    > `!b1` | `Bn` | Remarks: `bool(b1) == !bool(!b1)` for every value `b1`.
>    > `b1 && b2` | `bool` | `bool(b1) && bool(b2)`
>    > `b1 || b2` | `bool` | `bool(b1) || bool(b2)`

> 4. Change 16.4.4.4 [nullablepointer.requirements] p5 and Table 25 — "NullablePointer requirements" as indicated:

>    > […]

>    > -5- In Table 25, `u` denotes an identifier, `t` denotes a non-`const` lvalue of type `P`, `a` and `b` denote values of type (possibly `const`) `P`, and `np` denotes a value of type (possibly `const`) `std::nullptr_t`, and `BT` denotes a type that meets the `BooleanTestable` requirements ([booleantestable.requirements]).

>    > […]

>    > > Table 25 — `NullablePointer` requirements [nullablepointer]
>    > > Expression | Return type | Operational semantics
>    > > --- | --- | ---
>    > > `…`
>    > > `a != b` | contextually convertible to `bool` `BT` | […]
>    > > `a == np` `np == a` | contextually convertible to `bool` `BT` | […]
>    > > `a != np` `np != a` | contextually convertible to `bool` `BT` | […]

> 5. Change 22.4.9 [tuple.rel] as indicated;

>    >     template<class... TTypes, class... UTypes>
>    >     constexpr bool operator==(const tuple<TTypes...>& t, const tuple<UTypes...>& u);

>    > > -1- Requires: For all `i`, where `0 <= i` and `i < sizeof...(TTypes)`, `get<i>(t) == get<i>(u)` is a valid expression returning a type that is convertible to `bool` meets the `BooleanTestable` requirements ([booleantestable.requirements]). `sizeof...(TTypes) == sizeof...(UTypes)`.

>    > > […]

>    >     template<class... TTypes, class... UTypes>
>    >     constexpr bool operator<(const tuple<TTypes...>& t, const tuple<UTypes...>& u);

>    > > -4- Requires: For all `i`, where `0 <= i` and `i < sizeof...(TTypes)`, `get<i>(t) < get<i>(u)` and `get<i>(u) < get<i>(t)` are valid expressions returning types that are convertible to `bool` meet the `BooleanTestable` requirements ([booleantestable.requirements]). `sizeof...(TTypes) == sizeof...(UTypes)`.

>    > > […]

> 6. Change 24.2.2.1 [container.requirements.general], Table 95 — "Container requirements", and Table 97 — "Optional container operations" as indicated:

>    > -4- In Tables 95, 96, and 97 `X` denotes a container class containing objects of type `T`, `a` and `b` denote values of type `X`, `u` denotes an identifier, `r` denotes a non-`const` value of type `X`, and `rv` denotes a non-`const` rvalue of type `X`, and `BT` denotes a type that meets the `BooleanTestable` requirements ([booleantestable.requirements]).

>    > > Table 95 — Container requirements
>    > > Expression | Return type | […]
>    > > --- | --- | ---
>    > > `…`
>    > > `a == b` | convertible to `bool` `BT` | […]
>    > > `a != b` | convertible to `bool` `BT` | […]
>    > > `…`
>    > > `a.empty()` | convertible to `bool` `BT` | […]

>    > […]

>    > > Table 97 — Optional container requirements
>    > > Expression | Return type | […]
>    > > --- | --- | ---
>    > > `…`
>    > > `a < b` | convertible to `bool` `BT` | […]
>    > > `a > b` | convertible to `bool` `BT` | […]
>    > > `a <= b` | convertible to `bool` `BT` | […]
>    > > `a >= b` | convertible to `bool` `BT` | […]

> 7. Change 25.3.1 [iterator.requirements.general], Table 106 — "Input iterator requirements", and Table 110 — "Random access iterator requirements" as indicated:

>    > -12- In the following sections, `a` and `b` denote values of type `X` or `const X`, `difference_type` and `reference` refer to the types `iterator_traits<X>::difference_type` and `iterator_traits<X>::reference`, respectively, `n` denotes a value of `difference_type`, `u`, `tmp`, and `m` denote identifiers, `r` denotes a value of `X&`, `t` denotes a value of value type `T`, `o` denotes a value of some type that is writable to the output iterator, and `BT` denotes a type that meets the `BooleanTestable` requirements ([booleantestable.requirements]).

>    > > Table 106 — Input iterator requirements
>    > > Expression | Return type | […]
>    > > --- | --- | ---
>    > > `a != b` | contextually convertible to `bool` `BT` | […]

>    > […]

>    > > Table 110 — Random access iterator requirements
>    > > Expression | Return type | […]
>    > > --- | --- | ---
>    > > `…`
>    > > `a < b` | contextually convertible to `bool` `BT` | […]
>    > > `a > b` | contextually convertible to `bool` `BT` | […]
>    > > `a >= b` | contextually convertible to `bool` `BT` | […]
>    > > `a <= b` | contextually convertible to `bool` `BT` | […]

> 8. Change 27.1 [algorithms.general] p8+p9 as indicated:

>    > [Drafting note: The wording changes below also fix (a) unusual wording forms used ("should work") which are unclear in which sense they are imposing normative requirements and (b) the problem, that the current wording seems to allow that the predicate may mutate a call argument, if that is not a dereferenced iterator. Upon applying the new wording it became obvious that the both the previous and the new wording has the effect that currently algorithms such as `adjacent_find`, `search_n`, `unique`, and `unique_copy` are not correctly described (because they have no iterator argument named `first1`), which could give raise to a new library issue. — end drafting note]

>    > -8- The `Predicate` parameter is used whenever an algorithm expects a function object (20.9) that, when applied to the result of dereferencing the corresponding iterator, returns a value testable as `true`. In other words, i If an algorithm takes `Predicate pred` as its argument and `first` as its iterator argument, it should work correctly in the construct `pred(*first)` contextually converted to `bool` (Clause 4)the expression `pred(*first)` shall have a type that meets the `BooleanTestable` requirements ( [booleantestable.requirements]). The function object `pred` shall not apply any non-constant function through the dereferenced iterator its argument.

>    > -9- The `BinaryPredicate` parameter is used whenever an algorithm expects a function object that when applied to the result of dereferencing two corresponding iterators or to dereferencing an iterator and type `T` when `T` is part of the signature returns a value testable as `true`. In other words, i If an algorithm takes `BinaryPredicate binary_pred` as its argument and `first1` and `first2` as its iterator arguments, it should work correctly in the construct `binary_pred(*first1, *first2)` contextually converted to `bool` (Clause 4)the expression `binary_pred(*first1, *first2)` shall have a type that meets the `BooleanTestable` requirements ( [booleantestable.requirements]). `BinaryPredicate` always takes the first iterator's `value_type` as its first argument, that is, in those cases when `T` value is part of the signature, it should work correctly in the construct `binary_pred(*first1, value)` contextually converted to `bool` (Clause 4)the expression `binary_pred(*first1, value)` shall have a type that meets the `BooleanTestable` requirements ( [booleantestable.requirements]). `binary_pred` shall not apply any non-constant function through the dereferenced iterators any of its arguments.

> 9. Change 27.8 [alg.sorting] p2 as indicated:

>    > […]

>    > -2- `Compare` is a function object type (20.9). The return value of the function call operation applied to an object of type `Compare`, when contextually converted to `bool`(Clause 4), yields `true` if the first argument of the call is less than the second, and `false` otherwise. `Compare comp` is used throughout for algorithms assuming an ordering relation. Let `a` and `b` denote two argument values whose types depend on the corresponding algorithm. Then the expression `comp(a, b)` shall have a type that meets the `BooleanTestable` requirements ( [booleantestable.requirements]). The return value of `comp(a, b)`, converted to `bool`, yields `true` if the first argument `a` is less than the second argument `b`, and `false` otherwise. It is assumed that `comp` will not apply any non-constant function through the dereferenced iterator any of its arguments.

>    > […]

> 10. Change 31.5.3.2 [fpos.operations] and Table 126 — "Position type requirements" as indicated:

>     > -1- Operations specified in Table 126 are permitted. In that table,

>     > - `P` refers to an instance of `fpos`,

>     > - […]

>     > - `o` refers to a value of type `streamoff`,

>     > - `BT` refers to a type that meets the `BooleanTestable` requirements ([booleantestable.requirements]),

>     > - […]

>     > > Table 126 — Position type requirements
>     > > Expression | Return type | […]
>     > > --- | --- | ---
>     > > `…`
>     > > `p == q` | convertible to `bool` `BT` | […]
>     > > `p != q` | convertible to `bool` `BT` | […]

> 11. Change 33.2.1 [thread.req.paramname] p1 as indicated:

>     > -1- Throughout this Clause, the names of template parameters are used to express type requirements. If a template parameter is named `Predicate`, `operator()` applied to the template argument shall return a value that is convertible to `bool` `Predicate` is a function object type (22.10 [function.objects]). Let `pred` denote an lvalue of type `Predicate`. Then the expression `pred()` shall have a type that meets the `BooleanTestable` requirements ( [booleantestable.requirements]). The return value of `pred()`, converted to `bool`, yields `true` if the corresponding test condition is satisfied, and `false` otherwise.

[2022-11-05; Daniel comments]

The paper P2167R3 has been reviewed and accepted by LWG and would solve this issue.

[2022-11-22 Resolved by P2167R3 accepted in Kona. Status changed: Open → Resolved.]

Proposed resolution: