[over.best.ics.general] p1 says
An implicit conversion sequence is a sequence of conversions used to convert an argument in a function call to the type of the corresponding parameter of the function being called. The sequence of conversions is an implicit conversion as defined in [conv], which means it is governed by the rules for initialization of an object or reference by a single expression ([dcl.init], [dcl.init.ref]).
[over.best.ics.general] p9 says
If no sequence of conversions can be found to convert an argument to a parameter type, an implicit conversion sequence cannot be formed.
[conv.general] p3 says
An expression E can be implicitly converted to a type T if and only if the declaration T t=E; is well-formed, for some invented temporary variable t ([dcl.init]).
Consider this example
struct A{
A(int) = delete;
};
struct B{
B(int) {}
};
void fun(A); //#1
void fun(B); // #2
int main(){
fun(0); // #3
}
Since, A t = 0; is ill-formed, hence the expression "0" cannot be implicitly converted to a type A, hence, it could arguably say we cannot find an implicit conversion that converts "0" to type A. So, according to [over.best.ics.general] p9, it cannot form an implicit conversion sequence for #1. However, this interpretation does not conform the most implementations, which process the example as an ambiguity. Even though [over.best.ics.general] p2 intends to avoid to concern these properties it didn't talk about(i.e. #1 is a viable function)
Implicit conversion sequences are concerned only with the type, cv-qualification, and value category of the argument and how these are converted to match the corresponding properties of the parameter.
However, since the invented declaration is ill-formed; the implicit conversion cannot be done, Isn't it exactly about how these are converted to match the corresponding properties of the parameter? I think these rules about how can an implicit conversion sequence be formed are contradictory. Is it considered a defect?