I agree that the use of the "void" keyword here is confusing. I wish it were more like LLVM IR, where things are more explicit and no values can be left uniniti

I agree that the use of the "void" keyword here is confusing. I wish it were more like LLVM IR, where things are more explicit and no values can be left uninitialized by accident. E.g. something like this would be nice (but requires breaking eggs): int x = zeroinitializer; void *ptr = zeroinitializer; int y = undefined; // explicitly undefined int z; // compile error int w = poison; // compiler error if w or &w is read from Additionally, I am not fond of C and C++ casts and their semantics which vary with the types being used (and can get really hairy when templates are added to the mix). I'd much rather see "casts" that are named after the semantics they use. E.g. uint16_t u16 = 1234; uint32_t u32 = zero_extend(u16); int16_t s16 = -342; int32_t s32 = sign_extend(s16); uint16_t bits = bitcast(s16); // must be same size float fp = 1.234; int32_t fpint = floattoint(fp); uint32_t fpbits = bitcast(fp); In the two examples above, all the semantics are explicit, there are no surprises at runtime and the compiler/static analyzer has much more power in catching problems. This, of course, isn't going to happen in C++ in any kind of backwards compatible way. I'm not sure these things can or should be fixed in C++, because of the amount of existing code and the fact that most projects would never upgrade because of the manual effort required in updating the code and merging it.