Why does the standard differentiate between direct-list-initialization and copy-list-initialization?

Question

We know that T v(x); is called direct-initialization, while T v = x; is called copy-initialization, meaning that it will construc

Answer 1

Because they don't do the exact same thing. As stated in 13.3.1.7 [over.match.list]:

In copy-list-initialization, if an explicit constructor is chosen, the initialization is ill-formed.

In short, you can only use implicit conversion in copy-list-initialization contexts.

This was explicitly added to make uniform initialization not, um, uniform. Yeah, I know how stupid that sounds, but bear with me.

In 2008, N2640 was published (PDF), taking a look at the current state of uniform initialization. It looked specifically at the difference between direct initialization (T{...}) and copy-initialization (T = {...}).

To summarize, the concern was that explicit constructors would effectively become pointless. If I have some type T that I want to be able to be constructed from an integer, but I don't want implicit conversion, I label the constructor explicit.

Then somebody does this:

T func()
{
  return {1};
}

Without the current wording, this will call my explicit constructor. So what good is it to make the constructor explicit if it doesn't change much?

With the current wording, you need to at least use the name directly:

T func()
{
  return T{1};
}