Should ES.23 mention that ()-initialization is likely to be preferrable when dealing with containers containing types initializable from the container itself about cppcoreguidelines HOT 3 OPEN

Should that mention that one might want to prefer ()-initialization to {}-initialization when initializing a container of elements of a given type from a container of the same type, _when the inner type can be constructed from the vector itself?

I am not sure about that.

I'm referring to the fact that

std::vector<std::any> v{1,2,3};
std::vector<std::any> w{v};

will result in w having length 1, with its only element v[0] having been initialized from v. I think this can be surprising to most programmers.

I think w[0] was meant in place of v[0].
What do you think wouldn't surprise most programmers in this case?
In my opinion based on looking at it now, it looks like an artificially convoluted piece of code (in order to define a - single-element - vector, of vector(s), of anys), but I think it looks like the expected behavior.

from cppcoreguidelines.

I think w[0] was meant in place of v[0].

Yes, sorry.

What do you think wouldn't surprise most programmers in this case?

On the contrary, I think that what happens with std::vector<std::any> w{v}; would surprise most programmers at first.

What I'm saying is that it would beneficial if ES.23 mentioned that there are cases where preferring {}-initializer syntax results in not very easy to debug bugs.

it looks like an artificially convoluted piece of code

Ok, to be more concrete, I had to update a class that looked like this,

struct Foo {
  Foo(v, /* other args */)
    : v{}
    , /* other init.ons */
  std::vector<std::any> v;
  // other member vars + API
};

where v would then be altered via some API. This all worked fine. the {} instead of () in v{} was out of the habit of abiding by ES.23.

Later, the need arised for v to be initialized from some argument:

struct Foo {
  Foo(v, /* other args */)
    : v{std::move(v)}
    , /* other init.ons */
  std::vector<std::any> v;
  // other member vars and member funcs
};

But this code is broken for the reason I explained, and it's not easy to debug because you just start seeing std::any_cast fail and you don't immediately understand (I'm sure I'm passing a std::vector<Bar> to Foo's ctor, so why can't I cast an element of v to Bar?).

Another real-life case. Take this talk from Sean Parent about Runtime Polymorphism, where he always uses ()-initialization instead of {}-initialization. When I tried to rewrite that code myself, I came up with this, which is fundamentally his code, but with {} instead of () for initalizing things, becuase that's my habit, i.e. follow ES.23.

The result is that the code is bugged on lines 11-12, and the behavior is a neverending recursive call that stackoverflows.

Making the ctor explicit would have prevented the problem in the first place. But without that, it's clear that the {} is not really resulting in what one generally expects if they write self{std::make_unique<model<T>>(std::move(t))}.

from cppcoreguidelines.

The same point is made in https://abseil.io/tips/88

from cppcoreguidelines.