[clang-tools-extra] [clang-tidy] Add `modernize-use-uniform-initializer` check (PR #91124)

[Piotr Zegar via cfe-commits]

https://github.com/PiotrZSL commented:

Overall, i would see this as readability check.
And I would see this as configurable check, so I could select one of:
` = 10;`, or `(10);` or `{10};` and stick to that convention.

Other thing, in project not so long ago we had issues with {} initialization.
Thing was that there were let say `std::vector<Object> variable{0x12345}`, and problem were that Object had constructor that take int as argument, and when developer expected to create something like this: `std::vector<Object> variable{{0x12345}}`, in fact created std::Vector that consumed few GB of memory. At that point idea were to restrict usage of `{}` for common containers, and report this as possible miss-spell.

With this check, developers could run into more issues like this or containers that accept std::initialization list but also got normal containers. Using different initialization for different things usually helps protect against that.

For example I do not think that `int callinit_5{(7 + (-9))};` is better than `int callinit_5 = 7 + (-9);`. And what I learn over years is that C++ standard is a one big trashbin, and if something is put there, it doesn't mean it's better. Just look into modernize-use-trailing-return-type, that check enforces something "new", but still on github alone there is over 3800 clang-tidy config files with this check explicitly disabled.

So if you want to make this check actually usable, make it readability, and add config option to enforce specific style, note that there is also open issue for a check that would enforce `int a = 0;` instead of `int a = {}`; So you could somehow merge that.

Overall check is +- fine, and if you want it it's ok, but I feat that it may end up as one of those "allways disable" checks, and it may not have to many users.


https://github.com/llvm/llvm-project/pull/91124