On 10/01/2023 18:41, Edward Catmur via Std-Discussion wrote:
> On Mon, 9 Jan 2023 at 23:04, Lénárd Szolnoki via Std-Discussion <
> std-discussion_at_[hidden]> wrote:
>
>> However if two user-defined conversions yield different types before
>> the second conversion sequence, then they are necessarily have to use
>> different user-defined conversion functions or constructors, so the
>> conversion sequences would be indistinguishable by [over.ics.rank]/3,
>> as [over.ics.rank]/3.3 does not apply:
>>
>> https://timsong-cpp.github.io/cppwp/n4868/over.ics.rank#3.3
>
>
> This appears to be defective. There is full agreement that the following
> conversion is unambiguous:
>
> struct A {};
> struct B : A {};
> struct C : B {};
> struct X {
> operator B*();
> operator C*();
> };
> int f(A*);
> int i = f(X()); // calls X::operator B*()

There is nothing to resolve for the single `f` here, the overload resolution is between `X::operator B*()` and `X::operator C*()`, where the argument is `X()` and the parameter is the implicit object parameter, so these functions are indistinguishable by ICS on the argument.
What distinguishes them is https://timsong-cpp.github.io/cppwp/n4861/over.match.best#2.2

IOW, the example is not related to https://timsong-cpp.github.io/cppwp/n4868/over.ics.rank#3.3, you need multiple `f`s to start to care about that bullet.