I believe clang is correct here.
We can see from the draft C++ standard section 6.4.2 The switch statement that this involves a contextually implicit conversion. Paragraph 2 says (*emphasis mine going forward):
The condition shall be of integral type, enumeration type, or class
type. If of class type, the condition is contextually implicitly
converted (Clause 4) to an integral or enumeration type.
We can see the section we need to use is 4 Standard conversions and paragraph 5 covers these cases, it says:
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 does not reference section 8.5 which allows for overload resolution by specifically referring to section 13.3 without allowing overload resolution we can not use:
template <typename T>
operator T () const
and therefore there is no ambiguity.
Note this is different from paragraph 4 which covers bool conversions in contexts of if, while etc… and says (emphasis mine):
Certain language constructs require that an expression be converted to
a Boolean value. An expression e appearing in such a context is said
to be contextually converted to bool and is well-formed if and only if
the declaration bool t(e); is well-formed, for some invented temporary
variable t (8.5).
which specifically allows for overload resolution and refers directly to section 13.3 which covers this. It makes sense that it is allowed since we have a specific destination type bool to convert to which we don’t have in the switch case.
Why
We can figure this out by going looking at N3323: A Proposal to Tweak Certain C++ Contextual Conversions, v3 it covers this issue. It would be hard to quote the whole paper so I will attempt to quote enough of the context. It says:
The context in which a C++ expression appears often influences how the
expression is evaluated, and therefore may impose requirements on the
expression to ensure such evaluation is possible. […]In four cases, the FDIS (N3290) uses different language to specify an
analogous contextdependent conversion. In those four contexts, when an
operand is of class type, that type must have a “single non-explicit
conversion function” to a suitable (context-specific) type. […]
and includes:
[stmt.switch]/2: “The condition shall be of integral type, enumeration
type, or of a class type for which a single non-explicit conversion
function to integral or enumeration type exists (12.3).”
and says:
The principal issue, in each of the four contexts cited in the
Introduction, seems to lie in their common helpful but very strict
requirement that limits a class to only one conversion operator […]Another concern is the scope of the qualifier “single” in the current
wording. Must there be but a single conversion function in the class,
or may there be several so long as a single one is appropriate to the
context?The current language seems unclear on this point. It is also
unclear whether a conversion operator that produces a reference to an
appropriate type is an appropriate conversion operator. (A question on
this point was posted to the Core reflector on 2011-02-21, but has
gone unanswered as of this writing.) Current compiler practice seems
to admit such operators, but the current language seems not to.
and proposes:
To address all these concerns, we recommend instead to use the proven
approach typified by the term contextually converted to bool as
defined in [conv]/3. We therefore propose a modest addition to
[conv]/3 to define contextual conversion to other specified types, and
then appeal to this new definition.
and the new language would be as follows;
Certain other language constructs require similar conversion, but 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.
Note N3486: C++ Editor’s Report, October 2012 shows us when N3323 was incorporated in the draft standard.
Update
Filed a gcc bug report.