Hacker News new | ask | show | jobs
by ephou7 116 days 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.

1 comments

Well, here's Barry's actual proposal paper: 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.

What do you think the programming language fix would be?
Barry 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.

The 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...