6 ms·
Exactly my thought. Or a typed enum: enum class uint8_t { NAH, YEAH, OMGWTF }; I'm (fairly) sure there's a good reason for that language feature, but the justi
by ephou7 7mo ago
Exactly my thought. Or a typed enum: enum class uint8_t { NAH, YEAH, OMGWTF };
I'm (fairly) sure there's a good reason for that language feature, but the justification the blog article gives is super weak.
- tialaramex 7mo agoWell, here's Barry's actual proposal paper: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2641r4.html https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p26... The language is the problem, and WG21 hates fixing the language. The really bone headed stuff like "UB? in my Lexer?" got through as a language change and Barry has also had some success with "just fix it" language changes, that's what happened so that C++ can attempt what Rust's MaybeUninit<T> does, but mostly WG21 will take weird new intrinsics in the standard library, as here, over just fixing the programming language.
- yearolinuxdsktp 7mo agoWhat do you think the programming language fix would be?
- swiftcoder 7mo agoThe whole problem only arises because accessing the union member as a character is allowed at runtime, but disallowed in constexpr. If that restriction were relaxed to be the same in both cases, the entire motivating problem would disappear...
- tialaramex 7mo agoBarry even explains, the transmutation is outlawed during compile time in C++. They could remove this prohibition but they did not. Notice that e.g. Rust doesn't prohibit compile time transmutation, the provided core::mem::transmute literally does this operation, and it's const. The result is - as with similar situations in C++ - that if at compile time that's a 2 the compilation fails, 2 is not a boolean. You don't need all this bother because Rust's type system is better so Option<bool> already does have the same size as bool, but that's beside the point.