*This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
Core Issues List revision 110b.
See http://www.open-std.org/jtc1/sc22/wg21/ for the official
list.*

2023-01-15

#### 1981.
Implicit contextual conversions and `explicit`

**Section: **7.3 [conv]
**Status: **CD4
**Submitter: **Richard Smith
**Date: **2014-08-08

[Moved to DR at the October, 2015 meeting.]

According to 7.3 [conv] paragraph 5,

Certain language constructs require conversion to a value
having one of a specified set of types appropriate to the
construct. An expression `e` of class type `E`
appearing in such a context is said to be *contextually
implicitly converted to* a specified type `T` and
is well-formed if and only if `e` can be implicitly
converted to a type `T` that is determined as
follows: `E` is searched for conversion functions
whose return type is *cv* `T` or reference
to *cv* `T` such that `T` is allowed by
the context. There shall be exactly one such `T`.

This description leaves open two questions: first, can
`explicit` conversion functions be used for this
conversion? Second, assuming that they cannot, is the
restriction to “exactly one such `T`”
enforced before or after exclusion of `explicit`
conversion functions?

**Notes from the November, 2014 meeting:**

CWG felt that `explicit` conversion functions should
be removed from consideration before determining the set of
types for the conversion.

**Proposed resolution (May, 2015):**

Change 7.3 [conv] paragraph 5 as follows:

...An expression `e` of class type `E`
appearing in such a context is said to be *contextually
implicitly converted* to a specified type `T` and
is well-formed if and only if `e` can be implicitly
converted to a type `T` that is determined as
follows: `E` is searched for non-explicit
conversion functions whose return type
is *cv* `T` or reference to *cv* `T`
such that `T` is allowed by the context. There shall
be exactly one such `T`.