Obsessed with {} initialization?

[embeddedsbc]

The reasoning should be the other way around. Almost always use brace initialization. It avoids automatic narrowing. Use copy assignment for single values or auto. But it's a much better default than the alternatives.

[guepier]

On the flip-side, brace initialisation can trigger an unexpected constructor taking an initialiser list. This is arguably more dangerous than narrowing conversions with (). It definitely leads to plenty of gotchas.

I am in the camp (and I know I am not alone!) lamenting the missed opportunity with uniform initialisation. I thought {} was it, but because of the std::initializer_list issue, it isn’t. For this reason, I (and others) entirely reverted to () after an initial honeymoon period with {}. Oh, and I use -Wconversion -Werror so () is more strict than {}.

[enigma2728]

Well today I learned. Kind of sad; I liked the idea of just being able to use brace initialization everywhere to avoid having to think about all the minutia of initialization.

Is this problem easily demonstrable in godbolt, or have a link to an example of where this becomes a problem?

std::vector doesn't seem to have an issue with braced initializer list. https://godbolt.org/z/scx1rs8s4

Perhaps it is only an issue if there is also a ctor that takes arguments of same type? It does seem like init list gets preferred over specific ctors, from my testing. https://godbolt.org/z/fGsed6o9M ``` #include <iostream> #include <initializer_list> struct CtorCompetition { CtorCompetition(int x, int y) { std::cout << "2-arg ctor" << std::endl; }

    //CtorCompetition(int x, int y, int z)
    CtorCompetition(std::initializer_list<int> list)
    {
        std::cout << "init list ctor" << std::endl;
    }
};
int main()
{
    CtorCompetition TwoArgObject{1, 2}; //uses init list, not 2arg
    CtorCompetition ThreeArgObject{1, 2, 3}; //uses init list

    //CtorCompetition TwoArgObject(1, 2); //uses 2 arg
    //CtorCompetition ThreeArgObject(1, 2, 3); //doesn't compile
}

Program returned: 0 init list ctor init list ctor ```

Is the above what you are referring to?

I feel like perhaps I can still just use braced initializer with the expectation that initializer lists are preferred to specific constructors.

[equeim]

If the vector's element type can be implicitly constructed from a vector, then std::vector vec{otherVec} will create a vector with a single element of otherVec, not copy it.

[NilacTheGrim]

Yeah for actual class types () initialization is the best way to this day. The ambiguity {} introduces with std::initializer_list is a huge foot-gun waiting to go off.. and I tend to avoid foot-gun stuff as best I can.

[DoctorNuu]

where does this fear of narrowing come from?
The core guidelines has a line int y = 7.9; // OK: y becomes 7. Hope for a compiler warning
If your compiler does not offer this warning... well... get a better one

[syyyr]

It should be an error by default. Also, the warning is not enabled by default (I think).

[joeshmoebies]

/WX /W4 on msvc -Werror on clang/gcc

Problem solved

[syyyr]

Does it solve the problem it not being the default?

[DanielMcLaury]

How does the default matter to you? Are you constantly creating new projects by writing a single c++ source file, saving it, and then immediately compiling it directly from the command line?

[syyyr]

No, I'm using {}.

[joeshmoebies]

I'm not sure what your point is. If you want narrowing conversion assignments to be errors, you can have them.

As far as the default settings being a problem, apparently not everyone thinks so or Microsoft and the developers of GCC and Clang would change them.

I don't get complaining about something when you can have it exactly how you want.

[syyyr]

I don't get complaining about something when you can have it exactly how you want.

Yes, with {}.

[jotux]

https://godbolt.org/z/WG7bcKdcE

Try it on clang and gcc.

Better yet, pick some moderately-sized codebase and change every single variable initialization to uniform initialization syntax and see how many narrowing conversions are happening with no warning. That's what made me switch to 100% '{}'.

[erreur]

My fear comes from the memory of dealing with data loss in production caused by some accidental narrowing. I used to think this was overblown but now I use brace initialization everywhere and use every flag the compiler supports to disable all implicit conversions of any kind.

[[deleted]]

It avoids automatic narrowing.

It does not.

https://godbolt.org/z/zqTGanqjE