Off the top of my head
You need one constant value to represent one of the two, so that the other can be everything else. 0 makes for a very good choice for false in this regard, but I can't think of anything that can adequately represent a singular truth (maybe Ϫ?)
How would you go around getting rid of those complexities? Fixing the issues with strings('n variants fall into this case as well) leads to rust's multum of string types which is nightmare of it's own. FAM and Union alignment issues are inherent to them so idk how you would even go around to simplifying them. As for const and non-const type casting the only way to "fix" it would be to disallow it or go full on rust route.
Just learn Ada instead of thinking everything that isn't irreparably fucked has to be related to those Rust nitwits.
This is why I object to the phrase "the truth, the whole truth, and nothing but the truth" in the legal context. If you put a Techpriest like yours truly on the stand, the entire courtroom is going to be filled with parchment chaining things together like
true_proposition AND (false_proposition OR (NOT false_proposition)) .... (That is of course where pragmatics steps in.)When will hideous non-passing trooned-out men insist that things like the Boeing 777's fly-by-wire system be migrated from Ada to Rust?
Comparing a boolean variable against a boolean literal (not literally a literal in this case, but effectively one) for equality or inequality is an even bigger antipattern (since the variable is already a boolean that can be used without comparison, either as-is or complemented) so I don't think that's a particularly strong argument.
All this discussion of improving C and changing how switch statements work reminds me of this insanely relevant classic:
Terry said:
The answer of course being abstracting all of that shit away in some form and taking the C out of C. We have enough high-level toy languages.
The complement is interesting from a design perspective. Arguably, 0 being false is rooted in binary representations of true and false (0 and 1) and how comparisons end up being bitwise operations at a lower level. Like in a lot of other areas of math, this makes 0 (or your null, in a strictly mathematical sense) a sort of immutable anchor point. From this immutable definition of false, we can define true: NOT false.
There was a nigger, who came up with this idea:
cout << "Hello world" << endl;
It's telling that most everyone's first exposure to C++ is this alien.
whoever thought it was a good idea to overload the bit shift operator with stream writing?
Doug McIlroy, citing unix file operators allegedly.
Aside from the operator horror show (
cin bugs me more, but they're both awful), std::endl is objectively a nigger's design. It doesn't just "end" the line like a \n does; it also flushes the buffer. The fact this isn't made to be immediately clear from the name is bonkers to me.
How the fuck does that even work? Does the buffer recognize that it just received a newline and flush automatically, or does endl include some special extra character that tells the buffer to do that? Or is this some insane niggerlicious voodoo where sending endl secretly calls some method on the stream?
From cppreference:
Needlessly and niggerishly obscuring all of this behind a shittily-named inline.
Seeing that many (but not all) implementations flush anyway with a
\n disgusts me a lot. Either use buffers with an explicit call to flush when appropriate or fuck off.
It's not a secret, your header file will explicitly tell you that adding << std::endl will result in the calling or inlining of this function:
{ return flush(__os.put(__os.widen('\n'))); }They're going for some kind of ocaml-style operator chaining with this, but it kinda falls flat, as evidenced by
std::print
for quick irony poisoning