3 ms·
> It is in fact not a forced cast Why do you say this when you can explicitly see I specifically made sure to avoid claiming it is in fact a forced cast, and i
by dataflow 5y ago
> It is in fact not a forced cast
Why do you say this when you can explicitly see I specifically made sure to avoid claiming it is in fact a forced cast, and instead I said it is kind of like a forced cast? Clearly I meant something other than that it was actually a forced cast, right?
> if you do not have an initializer_list constructor in your class you do not have to worry.
Which is precisely an example of my point about it being problematic. How would you go about this when you don't know everything about a class? Like, say, in a template? And how do you prevent your code from silently breaking if a class you use later adds an initializer_list constructor?
> Uniform initialization is great
I disagree. It's awful. It's just a minor cosmetic change (which we can call an "improvement" for the sake of argument, though I think that's also dubious and the syntax is just ugly) that introduces pitfalls in the actual semantics of your program. That's not a great trade-off; it's a terrible one.
- qalmakka 5y ago> a minor cosmetic change (which we can call an "improvement" for the sake of argument, though I think that's also dubious and the syntax is just ugly) that introduces pitfalls in the actual semantics of your program std::int64_t i64 { 44 * 44 * 44 }; std::int8_t i8 = i64; // perfectly fine std::int8_t i8_2 { i64 }; // refuses to narrow the int uniform initialization resolves lots of headaches, like T() being ambiguous at times with functions, narrowing, etc.
- dataflow 5y agoI don't see failure on i64 -> i8 as beneficial here; it's harmful if anything. Integer conversions already happen in all sorts of constructs. Which is why compilers have warnings for them. If you don't like them, you can enable warnings (or even set them to errors if you want to outright prohibit them). If you think they should happen implicitly then there's nothing particularly interesting about construction sites vs. assignments or really anything else; there's no reason integer conversions should be treated specially for construction sites. If anything, that would make you feel safer than is actually warranted. With T() being ambiguous, you can already syntactically disambiguate. With extra parentheses or whatever other construct the case may warrant. As people have been doing all these years. Again, it's just a minor syntactic inconvenience.
- qalmakka 5y agoInteger narrowing is dangerous and should always be explicit. The fact that it is still implicitly possible at assignment doesn't mean it should be tolerated at type construction - personally I have saved hundreds of hours of bug fixing since I started consistently initializing integers with {}.