6 ms·

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just

The problem pointed out in the article seems a little silly. We're adding an entire language feature because someone wanted an optional bool class? Why not just create a uint8_t with three values: OPTIONAL_BOOL_FASLE, OPTIONAL_BOOL_TRUE, OPTIONAL_BOOL_UNDEFINED? Doing so takes the same space as a bool, and could be wrapped in a class if desired to provide a nicer interface.

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 ago
  Well, 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 ago
    What do you think the programming language fix would be?
    - swiftcoder 7mo ago
      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...
    - tialaramex 7mo ago
      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.
IsTom 7mo ago
Ah, the good old True, False, FileNotFound.
- DaiPlusPlus 7mo ago
  ...huh, TDWTF is not-only still online, but it even has recent updates. (for those wanting context, it's from this post from 2005: https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth )
cataphract 7mo ago
It was an example. The point was to make untagged unions usable in constant evaluation contexts. What I was surprised with was that their union code was valid. I thought accessing a union member that was not active was valid in C, but not in C++.
- matthewkayin 7mo ago
  I would think it would have to work the same in both since otherwise C code using that behavior would not compile in C++, right? I am not a C++ expert, but I'm surprised to hear that it is considered UB to access the other member since as far as I can tell a union is just a chunk of memory that can be interpreted differently depending on which union member you access? So, if you had a union { bool b, char c }, and you set b = false, then I would think that accessing c would predictably give you a value of '\0'. Granted, you probably shouldn't go around accessing an inactive union member like that, but when people say it's UB they make it sound like it's impossible to guarantee what data will be inside that byte, and it seems to me like that isn't true.
deleted 7mo ago
[deleted]

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 ago
Well, 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 ago
  What do you think the programming language fix would be?
  - swiftcoder 7mo ago
    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...
  - tialaramex 7mo ago
    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.

IsTom 7mo ago

Ah, the good old True, False, FileNotFound.

DaiPlusPlus 7mo ago
...huh, TDWTF is not-only still online, but it even has recent updates. (for those wanting context, it's from this post from 2005: https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth https://thedailywtf.com/articles/Classic-WTF-What-Is-Truth )

cataphract 7mo ago

It was an example. The point was to make untagged unions usable in constant evaluation contexts. What I was surprised with was that their union code was valid. I thought accessing a union member that was not active was valid in C, but not in C++.

matthewkayin 7mo ago
I would think it would have to work the same in both since otherwise C code using that behavior would not compile in C++, right? I am not a C++ expert, but I'm surprised to hear that it is considered UB to access the other member since as far as I can tell a union is just a chunk of memory that can be interpreted differently depending on which union member you access? So, if you had a union { bool b, char c }, and you set b = false, then I would think that accessing c would predictably give you a value of '\0'. Granted, you probably shouldn't go around accessing an inactive union member like that, but when people say it's UB they make it sound like it's impossible to guarantee what data will be inside that byte, and it seems to me like that isn't true.

deleted 7mo ago

[deleted]