We already have uniform initialization, stop proposing braced initialization as a solution for everything

I bet we all have studied some math at school, and without any doubt int i = 1; feels more natural than int i{1};, as it mimics/reminds the notation i = 1.

The assignment is also easier to type, on most keyboard layouts you need to use a key combination to type { and }, misplaced opening and closing parenthesis are also a common source of typos, and typing on devices like a smartphone is also more difficult. Of course, these are only minor issues when writing code against a compiler since it is his job to verify that every statement is correct.

The major issue is readability. In the first case, it reads "i equal 1", even if you never programmed C++, or programmed in general. How do you read the second example? If you know C++ well enough, it reads "i is value-initialized to 1", which raises the bar for beginners and polyglot programmers for no good reason.

Using the same notation that we usually use in math, makes the syntax easier for everyone, and avoids misunderstandings as {} has other meanings too.

Also if you think about it, one of the (many) selling points of C++ is the ability to overload assignment, operator+, operator-, and so on. This is a design decision, to give end-users the ability to define more expressive interfaces. The canonical example is std::complex or a "biginteger" class, but other examples could be matrixes and vectors (not std::vector), quaternions, and many other numerical entities.

So what’s the point of providing such features to make code more readable if, in the end, we encourage to make everything look equal? Why use operator+ instead of a normal function like int add(int, int); like many other programming languages? And if having operator+ adds some value, why shouldn’t it be the same for initialization?

Yes, it’s true that {} has the advantage that it prevents some narrowing conversion. But it’s not really an advantage…​

unsigned int i{-1}; does not compile, but it makes the code inconsistent with unsigned int i{-1u}, since it is after all the same entity: a number that when is added to 1 has 0 as result. And why should unsigned int i{1}; compile if unsigned int i{-1}; does not?

Thus using {} the compiler not only looks at the type (both 1 and -1 are of type int, and 1u and -1u are of type unsigned int), but also at its value. By doing so, it prevents one of the two equivalent expressions from getting compiled, because both unsigned int i = -1; and unsigned int i = -1u; represent the same logical value. It’s the inverse of unsigned int j = 1u. Should therefore unsigned int j = 1; not compile? Or why not accept int i{"1"} as valid code too?

The unfortunate reason is that in C++ "narrowing", when talking about signed and unsigned conversion, does not have the same meaning in math, which continues to confuse many programmers (myself included).

But this post is about initialization, and talking about numbers is a big topic that should be handled separately.

Let’s acknowledge that {} for some people has an advantage when working with integral types, and let’s look at the main motivation. Most of the time it’s because of the mentality that unsigned means "greater than 0", while actually, it means modulo arithmetic, which is not what we want for most use-cases (containers and constants included). If you realize that unsigned means modulo arithmetic, ie working on $({\mathbb{Z}}_n,+,\cdot ),n\in {\mathbb{N}}^{+}$, and not a subset of $(\mathbb{Z},+,\cdot )$, then unsigned i = -1 might not be perfect, but is completely fine, consistent with math notations and easier to read than something like std::numeric_limits<int>::min(), which hides the important information about the given number.

Even without considering conversions between different integral types, how in the world would be int i{}; more readable than assigning i to a number (0 in this case)? Why would something that looks "empty" initialize to 0?

Again, if you are an "expert" then you know why, but it puts the bar higher for everyone else.

Similar arguments hold for the boolean type. How would bool b{}; be more readable than bool b = false;? And again, assignment for boolean variables is used in other fields too, why introduce a new notation and tell everyone to prefer it for most use cases?

My guideline would therefore be: For numeric types (int, double, unsigned int, float, …​), char, bool, and naked pointers: Do not use any kind of parenthesis, prefer assigning directly to literals (for example 1, -2u, 'b', nullptr, false), or other values. Normally it is much more readable than using {} in any form, especially because using = is an established convention in many fields.

Yes, indeed, it might not be consistent with other types in C++, but why should this be an issue?

This is not about generic code but about specific use cases. Not all types have the same API, should we, therefore, stop writing + and use add because it looks like a function call?

No, it should be as easy as possible to read and write.

We should not be afraid of implicit conversion, there is no need to hope for a warning. GCC, Clang, and MSVC have warnings, just enable the corresponding flag and eventually turn them into errors! Some useful flags for GCC are -Wconversion -Woverflow -Wsign-promo -Wsign-compare, and those for clang are the same plus at least -Wnarrowing. MSVC has similar sets of warnings, and all of them can even be converted to errors.

As always it is easier said than done, especially in a big codebase, and there is also the drawback that those settings, without relying on compiler-specific #pragma, are global. It is "easy" to exclude code that we do not own (use -isystem in GCC and Clang to mark "system" headers, the MSVC compiler offers ^🗄️ /external:), but inside our code-basis, we need to rely on the build system, for applying different flags, and there might be still some edge cases that are not so easy to solve, without locally disabling the warnings.

There is also another downside: the information with which flags the code is compiled, is not available in the source code itself (unless using a #pragma), so generally, it is better to compile everything with the same flags and make all conversions between different integral types explicit.

The same guidelines given for integral boolean and character types hold for enum and especially for enum class. But I wanted to mention them separately because using {} with enumerators has a different behavior.

The selling point of enum class is being a lot more type-safe than enum.

Given enum class ec {a=10, b=20}; it should not be possible to create an instance of ec with a value that is not ec::a or ec::b unless explicit casting (and possibly invoking undefined behavior).

This seems great, code like ec v = 1; does not compile, contrary to ec v = ec::a.

Unfortunately ec v{}; compiles, and what value does v hold? ec::a or ec::b? It holds static_cast<ec>(0), even if it does not coincide with any of the declared enumerations.

I believe this is a bug/misfeature in the language because using {} with an enum class bypasses the selling point of using enum class.

But it gets worse; ec v{0} compiles too since C++17, while ec v(0) does not, with the error message (from GCC) "cannot initialize a variable of type 'ec' with an rvalue of type 'int'".

So much for the supposed safety provided by {} and enum class.

There are surely use cases where it would be nice to initialize an enum with any value of the underlying type (a custom integer type comes to mind) but would have it been better to assign such a feature to a new type?

Or why not define a structure with just one member variable? It should have no padding, and thus have the same size as the contained type.

Now, enum class has, together with {}, some of the disadvantages of a normal enum, that both enum class and {} wanted to solve.

If you are mainly using enum class for enumerating, then using mainly {} instead of () might lead to subtle bugs.

So, it’s just the same as with plain old integers. Avoid if possible any type of parenthesis, use literals, and assignment. The most straightforward way is the one that has minor possibilities to create bugs.

At this point, I’ve nearly shown all primitive types. Only arrays and strings are left, but I’ll discuss them together with other containers.

Classes and structures that hold values, without enforcing any invariant on the contained item should be initialized with {}, if what we want is initializing the contained item with such values.

Examples of such classes are: arrays, std::array, std::vector, std::tuple, std::pair, smart (and raw) pointers, std::variant, std::optional, std::map, all other containers, and therefore also classes like struct handle{int value;};, and many others.

Let’s use std::vector as an example:

std::vector<int> v{55}; initializes the contained value, while std::vector<int> v(55); performs some logic, and does not initialize the contained value with the given parameter.

The same holds for struct handle{int v;};, it can and probably should be initialized as handle v {value};

std::array is known to be an exception for the number of parentheses, the canonical example where the inconsistency arises is std::array<std::complex<double>> or std::array<std::pair<int, int>>.

std::array<std::pair<int,int>,2> a{{1,1},{2,2}}; does not compile, the correct form is std::array<std::pair<int,int>,2> a{{{1,1},{2,2}}};, or using T = std::pair<int,int>; std::array<T,2> a{ T{1,1}, T{2,2}};.

The same holds for std::complex. std::array<std::complex<double>,3> v{{1}, {1,2}, {54}}; yields a compiler error, and the correct form would be std::array<std::complex<double>,3> v{{{1}, {1,2}, {54}}};

But let’s take advantage of the fact that C++ gives us better tools to match the domain logic. Isn’t std::array<std::complex<double>,3> v{1, 1.+2i, 54}; easier to read and write, even if I needed to write 1. or 1.0 instead of 1?

Using {} for containers and aggregates has another advantage, that has nothing to do with C++. It is the same syntax used for describing sets!

It maps so well to the C++ convention for containers, that I cannot believe that it happened by accident. By using {} it seems natural that all expressions using it should be compiled to some sort of collection, in C++ it’s std::initializer_list, or the collection it’s explicitly assigned to.

Thus this also lowers the bar for novice programmers, as they might have seen a similar syntax somewhere else.

Notice that always using {} for containers has a drawback, consider:

in this case, it would be unusual for someone to want a set with a couple of iterators, but not impossible.

This is why my rule is not to use {} for containers, but to use it if the container is going to be initialized with the contained content. In this case, the usage of {} maps well with the mathematical notation.

What about std::string (and std::string_view and other string classes)? It’s a container, so using {} seems to be the right choice.

But strings are a little bit special. Literals and std::string have one structural invariant: the trailing '\0'. std::string_view does not have such invariant, and other custom string classes might not have it too, but still, they all have something else in common.

Strings literals are already delimited, not by parentheses, but by ", so adding another delimiter is redundant. Considering that nearly all languages use quotation marks (single or double), suggesting to use of braced parenthesis as an additional delimiter does not make the code necessarily easier to understand.

Also for the empty std::string, using {} seems strange, especially since the string will contain at least the \0 terminator, so it’s not a (mathematical) empty set, or empty container (even if the trailing '\0' is not counted in .size()).

If we want to be very explicit that the string is initialized empty, and not by accident, we can write std::string s = "";, as an alternate form to std::string s;. This would normally have a runtime cost (it calls std::strlen internally), and increase the binary size (because of the global empty string literal).

C++ is a compiled language, there are of course no guarantees, but MSVC, GCC, and clang all optimize such drawbacks completely away with -O1 or better, and generate for both std::string s = "";, std::string s; and std::string s{}; the same assembly.

Therefore performance and binary size should not be an argument for a less readable statement. (The same holds of course for other containers and types too). I’m not stating that debug builds should not be fast too, especially when fuzzing or running under Valgrind performance is just as important. Since there is no allocation, the runtime cost even in those scenarios is negligible.

Also, the fact that std::string s1 = {}; (or std::string s1{};) and std::string s2 = {""}; (or std::string s2{""};) generates two objects with the same value, while with other containers (and auto) passing zero or more arguments, creates objects with different sizes, is another inconsistency to take into account.

Similarly to numbers, my advice is to avoid braces and prefer literals as long as possible, and similar to other containers prefer to use = when assigning values.

Normally we use parenthesis for grouping values. It is a convention used in math, physics, many other programming languages, and other disciplines.

Parameters for a function are, for example, grouped with (), and expressions, for changing the evaluation order, are grouped with () too.

For grouping multiple values in a set (mathematical sense) or container (C++ sense, array included), we use {}.

It seems a simple concept, but the language is not that consistent:

So using {} without = either does not compile, or behaves as if it would not be a collection of elements, but the single element contained.

Since both int i{} and int i{0} compile to the same, it also seems inconsistent that auto v{} and auto v{0} do not compile to the same, but I’m not going to argue that we want this behavior.

It’s clear that the committee had something different in mind with {}, even if it plays so well (except as shown with auto) with the mathematical syntax. This example with auto shows again that using {} for everything is not that easy, and that it has inconsistencies.

With the mathematical notation in mind and all other containers, the general advice would be to prefer {} with = instead of without, but there are use cases where we cannot use = that I’ll show later.

So I’m not concluding much here, just that the advice "prefer {}" seems misguided, and that we should prefer = { /* elements */ } to express better the intent when initializing collections of objects because it is always consistent and probably better to read.

As a (not so) fun fact: when C++11 was standardized, all variables, from v2 to v6 with v4 excluded defined a std::initialiser_list<int>, which is what I would have expected, and find more consistent with the rest of the language.

Unfortunately, someone noticed it and both n3922 ^🗄️ and n3681 ^🗄️ were discussed and accepted. This is how we ended (IMHO) with a much bigger inconsistency.

The background seems to be, that many people (possibly not all, otherwise there would not have been inconsistencies with auto) want to teach that every variable could and should be initialized with {}.

I hope that in the future this idea will change, even if it is too late to change again the behavior of auto v2{1};.

Just for the sake of completeness, let’s look at how the code behaves if we would have used ()

One last note auto v5 = ( (1) ) still compiles to an int, while auto v5 = {{1}} does not. Thus parents are idempotent in this (and other) contexts, while I’m not aware of any situation where braces are.

At this point, I’ve mentioned fundamental types, collections of objects, and strings.

What about the rest of the world? All those custom classes with a not-so-generic interface or well-defined behavior?

Objects that have some invariants, should get initialized most straightforwardly, just as we use = for initializing a number.

If there are some invariants, it might be better to use () to indicate that the passed value is not necessarily stored (or accessible) in the initialized object. () are also used, when defining and implementing constructors, just like all other functions, so why use two different syntaxes if there is no good reason?

Consider auto w = Window{10} and auto w = Window(10).

In the first form, I (and I know this is a personal opinion) would assume to be able to get the value 10 out of w, just the way I can with any container, aggregate, integral type, or smart pointer. This thinking is also encouraged by the fact that when using {} on fundamental types, there is no narrowing conversion, so the value does not get reinterpreted in some other way. And here lies the problem.

For specific use cases, there is little reason for trying to initialize everything the same way. It hurts readability and expectations.

In the case of Window, we are not creating a window of 10, but we are converting 10 into a window object, or using 10 for creating a window instance.

The Window constructor might use the value 10 for logging, as a coordinate, title, internal id, or something else. In those cases, why should the code look as if I could get a 10 out of a Window?

Better make it clear that we are using a constructor, that uses the input parameter for doing something.

Making it explicit does not harm, we could also make it more explicit by casting, for example, auto w =static_cast<Window>(10), but you have to draw somewhere the line, and the static_cast is just noise. Calling the constructor is or at least should be, the line, for the same reason that we do not use an alternate syntax for calling functions.

In case something like Window w = 10 compiles, then consider fixing the Window class (make the constructo explicit), unless it represents some numerical quantity (in that case, consider changing the name of the class). If some type is broken or converts implicitly for no good reason, there is little defense against it, using {} for initialization adds very little protection, and since it has drawbacks, I cannot recommend it as a general rule.

Fixing the offending class would fix the problem for every user, instead of teaching everyone to use one syntax instead of another because of subtle differences.

This is another interesting object type that I did not consider before.

Instead of writing auto l = [](){return 1;};, since we should we should prefer using {} for initializing, we should write auto l = {[](){return 1;}};. This agglomerate of parenthesis does compile and creates a std::initializer_list of one lambda. auto l {[](){return 1;}}; compiles to the wanted lambda, but I doubt someone could argue that it is more readable than an assignment.

In case you were asking yourself, yes, auto l ([](){return 1;}); and auto l = ([](){return 1;}); compiles too, just arrays do not work with (). I do not believe that adding more parentheses (lambdas have already enough) just for consistency as a general rule does make the code more readable or easy to teach because it would be more consistent. It does not make code simpler, and this is a good recipe for hiding bugs.

Same rules as if it were integers: just use assignment. Together with auto, there are no unintended conversions.

Generally speaking, using = makes it clear that there is an assignment or initialization. The same notation is used in other fields, so this is a big advantage.

Most examples describing these guidelines (granted, mine too) are one-liner, just initializing one or two variables, so using or not using = does not make a big difference in readability if you know C++.

But inside a bigger piece of code, between statements, the = symbol (maybe surrounded by spaces), is much easier to recognize than { and } which, depending on your fonts, might even look similar to ( and ), and it’s easy to overlook them or confuse, for example, with function calls.

So most of the time int a = function(); instead of int a{function()}; (and int a(function());) is easier to read and acknowledge that a new variable has been declared and initialized. And if the variable was already declared, just remove the type: a = function();.

Assignment and initialization should go hand in hand, therefore it’s fine if both of those syntaxes are nearly equal. If a class is doing something else, consider fixing it, or there must be a very good reason to behave differently.

Note that adding a space before or after { does not change much in terms of readability, at least in my experience.

There are situations where we cannot write =, but most guidelines do not say anything explicitly about those cases.

The first example that comes to mind is when returning a variable.

I would not recommend writing return {1}; instead of return 1;, it is a pessimization for more complex types (looking at RVO) but I’ve heard people arguing for it as more consistent with "always prefer {} ".

Another use-case are function parameters. Suppose there is a function void enable(bool). The expression enable({}) is probably the less readable, enable({false}) is misleading (are we passing false or something that takes false as a constructor?), and enable(false) is probably the easiest to write, read and understand, unless there is an implicit conversion, but {} does not help to prevent it.

And last, but not least, another place where we cannot use = is during the initialization of member variables in a constructor. In this case, we need to choose between {} and ().

Deciding which form is more readable between foo(var a_): a{a_}{} and foo(var a_): a(a_){} is not always straightforward.

My guideline is just to apply the same rule between {} and (), but without taking = into consideration: If a is some sort of collection and a_ has the type of the contained element, then use {} (otherwise it would not work for arrays, and since the type is the same, it does not cause problems with enum class). If a_ and a are of the same type, using {} might prevent some error (unintended conversions) if during refactoring the type of a or a_ changes, but for enum class it’s the opposite. Since I believe that in the majority of cases, member variables of classes are not enums, probably it is safe to use {}. In all other cases, prefer to be explicit that we are doing some conversion through the constructor and use ().

Notice that in this case, we do not have edge cases like auto v{} or auto v{1}, because the type is never deduced, it has been declared somewhere else.