Additional notes, February, 2017:

The statement of the issue is incorrect. In an example like

  struct A { A(); A(initializer_list<int>); };
  void f(A a);
  int main() { f({}); }

the rule in question is not used for the initialization of the parameter. However, it is used to determine whether a valid implicit conversion sequence exists for a. It is unclear whether an additional change to resolve this discrepancy is needed or not.

Proposed resolution (January, 2017):

Change 12.2.2.8 [over.match.list] paragraph 1 as follows:

When objects of non-aggregate class type T are list-initialized such that 9.4.5 [dcl.init.list] specifies that overload resolution is performed according to the rules in this section, overload resolution selects the constructor in two phases:

• Initially, the candidate functions are the initializer-list constructors (9.4.5 [dcl.init.list]) of the class T and the argument list consists of the initializer list as a single argument.

• If no viable initializer-list constructor is found, overload resolution is performed again, where the candidate functions are all the constructors of the class T and the argument list consists of the elements of the initializer list.

If the initializer list has no elements and T has a default constructor, the first phase is omitted. In copy-list-initialization, if an explicit constructor is chosen...

According to 12.2.2.8 [over.match.list] paragraph 1 says,

If the initializer list has no elements and T has a default constructor, the first phase is omitted.

However, this case cannot occur. If T is a non-aggregate class type with a default constructor and the initializer is an empty initializer list, the object will be value-constructed, per 9.4.5 [dcl.init.list] bullet 3.4. Overload resolution is only necessary if default-initialization (or a check of its semantic constraints) is implied, with the relevant section concerning candidates for overload resolution being 12.2.2.4 [over.match.ctor].

See also issue 1518.