X{1,2,3,4} being equal to X{{1,2,3,4}}. Is there any reasons?

[Christiano]

There is a bug in the book PPP2[1] that made me wonder what would be
the reasons for C ++ to accept X{1,2,3,4} to be the same thing as X{{1,2,3,4}}.

The bug is:
"The string{1,c} is a constructor for string, initializing the string to contain the single character c."

No. The string{1,'a'} will create a vector with two elements: 1 and 97 ('a' ascii value).
The correct should be string(1,c).


Proof:
------------begin proof------------------------
#include <iostream>
#include <string>
using namespace std;

void f(const string &s, const string &label)
{
cout << "=== String \"" << label << "\" ===" << endl;
cout << "size: " << s.size() << endl;
for(const char &c : s)
cout << int(c) << endl;
}

int main()
{
f(string{1,'a'}, "1");
f(string(1,'a'), "2");

return 0;
}
----------- end proof------------------------

Output:

=== String "1" ===
size: 2
1
97
=== String "2" ===
size: 1
97

Ok.

Now, look this program:

-----------test.cpp begin-----------------------
#include <iostream>
#include <initializer_list>
using namespace std;

class car
{
public:
car(int n)
{
cout << "Constructor int" << endl;
}
car(initializer_list<int> lst)
{
cout << "Constructor initializer_list" << endl;
for(auto &x: lst)
cout << x << " ";
cout << endl;
}
};

int main()
{
car v{1};
car u{{1,2,3}};
car t{1,2,3};
// car r{{{1,2,3}}}; ERROR
return 0;
}
-------------test.cpp end----------------------


The output is:
Constructor initializer_list
1
Constructor initializer_list
1 2 3
Constructor initializer_list
1 2 3

That is: v, u and t are being constructed using car(initializer_list<int> lst).
v using car(initializer_list<int> lst)
u using car(initializer_list<int> lst)
t using car(initializer_list<int> lst)

What I want to discuss here is: Wouldn't a result similar to following be more reasonable?:

v using car(int n)
u using car(initializer_list<int> lst)
t using car(int, int, int) ---> ERROR because you haven't defined car(int, int, int) here

My point here is: The compiler forbidding X{1,2,3,4} being equal to X{{1,2,3,4}}:

1- would be orthogonally compatible with the error of writing r{{{1,2,3}}}
2- Prevents mixing of C++98 syntax (x(1)) with C++11 syntax (x{1})

Is there any special reason to X{1,2,3,4} being equal to X{{1,2,3,4}} in spite of the benefits that language would gain without it??

----
[1] PPP2 book : http://www.stroustrup.com/Programming/

[Alf P. Steinbach]

On 04-Jun-17 11:39 AM, Christiano wrote:
> There is a bug in the book PPP2[1] that made me wonder what would be
> the reasons for C ++ to accept X{1,2,3,4} to be the same thing as
> X{{1,2,3,4}}.
>
> The bug is:
> "The string{1,c} is a constructor for string, initializing the string to
> contain the single character c."
>
> No. The string{1,'a'} will create a vector with two elements: 1 and 97
> ('a' ascii value).
> The correct should be string(1,c).

Right, except formally the presumption of ASCII.


> Proof:

Careful. The result from a given implementation is not proof of
anything. It can support an argument and serve as an heuristic.

The final authority on C++ is the C++ standard.

But in this case the behavior is well known so you don't need to supply
a proof: you only need to point out the error. For example, the
idiomatic way to create a single character string is `string{c}`, which
relies on the same precedence for initalizer list overload, and which
doesn't work with round parenthesis. At a guess Bjarne originally wanted
the curly braces syntax to be a drop-in replacement for the original
round parenthesis syntax, but it didn't work out that way.


> [snip]

> car v{1};
> car u{{1,2,3}};
> car t{1,2,3};
> // car r{{{1,2,3}}}; ERROR

> What I want to discuss here is: Wouldn't a result similar to following
> be more reasonable?:
>
> v using car(int n)
> u using car(initializer_list<int> lst)
> t using car(int, int, int) ---> ERROR because you haven't defined
> car(int, int, int) here
>
> My point here is: The compiler forbidding X{1,2,3,4} being equal to
> X{{1,2,3,4}}:
>
> 1- would be orthogonally compatible with the error of writing r{{{1,2,3}}}
> 2- Prevents mixing of C++98 syntax (x(1)) with C++11 syntax (x{1})

As I recall in the original C syntax internal braces in an initializer
were optional. Optional is a one-way thing. You can omit but you can
generally not add.

> Is there any special reason to X{1,2,3,4} being equal to X{{1,2,3,4}} in
> spite of the benefits that language would gain without it??

E.g. `std::array`, or more precisely the original `boost::array`, since
the standard library can any kind of magic, relies on this.

The issues we have now with that syntax were not possible, and hence not
considered, in early C, or for that matter in modern C.

When you design a new class it's easy to avoid the problem by e.g.
adding a tag argument to the value list constructor:

#include <iostream>
#include <initializer_list>
using namespace std;

namespace with {
struct Values {} const values = {};
} // namespace with

class Car
{
public:
Car( int )
{
cout << "<init>( int )" << endl;
}

Car( with::Values, initializer_list<int> const values )
{
cout << "<init>( initializer_list ) " ;
for( auto const x : values ) { cout << x << " "; }
cout << endl;
}
};

auto main()
-> int
{
Car v{ 1 }; // int
Car u{ with::values, {1,2,3} }; // values
// Car t{1,2,3}; //! error
// Car r{{{1,2,3}}}; //! error
}

Cheers & hth.,

- Alf

[Christiano]

The book "Effective Modern C++" (EMC++) has a very interesting item:

Item 7: Distinguish between () and {} when creating objects.

The way Scoot Meyers deal with the problem is fantastic.
I can't write the content here because copyright but I can write the "Things to Remember"
at the final of the item 7:

• Braced initialization is the most widely usable initialization syntax, it prevents
narrowing conversions, and it’s immune to C++’s most vexing parse.
• During constructor overload resolution, braced initializers are matched to
std::initializer_list parameters if at all possible, even if other constructors
offer seemingly better matches.
• An example of where the choice between parentheses and braces can make a
significant difference is creating a std::vector<numeric type> with two
arguments.
• Choosing between parentheses and braces for object creation inside templates
can be challenging.

EMC++: http://www.aristeia.com/books.html