- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Seems like a modern take on https://thedailywtf.com/articles/What_Is_Truth_0x3f_
Admin
Pre-1999 versions of C? C23 is the first version of C where true and false were their own thing. Before then they are just macros defined in stdbool.h!
Admin
OK, but versions starting at C99 but still before C23 do at least have a way to create a bool type that coerces values to exactly true or exactly false without the programmer having to define it.
Admin
These really need a comment above them in the code that says “I know this is stupid but it is the only thing that fixes [bug scenario].” Then we get to cry with the original coder rather than laugh at him.
Admin
Considering that C/C++ is not 100% type safe with it's implicit cast operations of standard types that can result in data loss, TRUE/FALSE were perfectly fine and well defined long before C99 (FALSE is zero and TRUE is everything but FALSE).
Admin
And the billion dollar mistake is still unsolved because
Optionalcan also (a) be null (it's a class like everything in Java) and (b) contain null (becauseBooleanis also a class)!Admin
I know in .NET's CLR, instantiating the same object repeatedly adds churn to the GC and static instances of commonly used types (e.g. serialization configuration options object) can improve performance (although maybe not meaningfully below a certain scale though).
I'm guessing this is Java, would it benefit the same way?
Admin
Optional solves null the same way a sign saying "Are you wearing your hard hat?" solves builders not wearing their hard hats. The same people who don't check for null don't check that the optional has a value.
Admin
#define TRUE 0 #define FALSE !TRUE
stdbool.h was not in K & R 'C'
Admin
Optionals cannot "contain null", conceptually. They are either empty or contain a non-null value. And if you use an Optional, you expect that under certain conditions it can be empty, otherwise you wouldn't have used an Optional.
Admin
this actually kinda makes sense its just implemented the wrong way. if youre dealing with incomplete data
Optional.emptymeans unknown andOptional.of(Boolean)is a true/false value. the problem is making these into a constant and naming themTRUEandFALSEAdmin
I've already revealed my age, so I guess it's ok to mention that the first C class I taught used the K&R white-book.
Admin
This is a joke, right?
Admin
That sounds ... wrong, or at least slightly off the mark.
I don't do Java, nor C#, but an Optional<T> (where T is a nullable type) that doesn't allow me to store a null value in it is broken. In essence, such an optional has three possible states: empty (no value stored at all), NULL stored, and something-that's-not-NULL stored. If Java (or C#) doesn't work like that, I'd be happy for someone to fill the gaps in my knowledge.
Admin
This may make sense when parsing JSON with Jackson, if you need to differentiate between a field not being present, or being explicitly set to null:
Parsing { "foo": null } will give foo = Optional.empty(), while an empty object {} will result in foo = null.
Admin
Optional does not, at all, fix the "problem" of null. because, regardless of whether you use NULL or Optional, it boils down to: if you use the value you're actually interested in without checking if said value actually exists, you're gonna have a bad time.
Admin
"Optional types are an attempt to patch the "billion dollar mistake"." Nope. The billion dollar mistake was not inventing nulls, it was making it so very easy for objects to be null when they shouldn't be. Most objects, once properly constructed and ready to use, should never be null in the same way that integers shouldn't be. But language design misfeatures mean that that's really hard to enforce and it's really easy to introduce bugs.
Optional/nullable types, like database nulls, were invented to solve an entirely different problem, namely that sometimes it's useful to have an easy way to handle the case that sometimes the value of a variable is genuinely "unknown".
Admin
The billion dollar mistake was assuming that programmers would check return codes from functions.
Admin
It seems to me that there's no single "billion dollar mistake" but a billion "dollar mistakes" spread all over...
Admin
The statement in the original post was about making constants for true and false. C99 explicitly makes constants for true and false …
Admin
I think you're just misunderstanding what "empty" means here. An empty Optional is just holding a null value. Being inside an Optional means you can't get a null back out of it by accident; Optional.<Object>ofNullable(null).get() throws an exception rather than giving you a null.
Admin
In Java and Scala, at least, Optional values can indeed contain null. It’s rather the bane of my existence at times.
Conceptually, we can have
None,Some(value)orSome(null). This comes up most often when modelling input from an external system (config, user input, API input etc.) where a value may or may not be supplied, and if supplied, may be expressly “unset”.We then have
Nonemeaning “user did not supply a value”,Some(x)meaning “user supplied valuex” orSome(null)meaning “user expressly supplied an empty value”.There are definitely other ways to handle this - one being
Optional<Optional<T>>, and another to use specific sentinel values for “empty” - but I’m not convinced that there are actuallly better ways to handle it!Admin
Yes, but since you have to explicitly extract the value from inside the Optional (which already puts you on notice that the value may not be there or it wouldn't be wrapped in an Optional), that's the point where not checking there's a value there to start with will bite. Not at some arbitrary point in the program where that object of type T you've been passing around turns out to have actually been a null of type T all along.
And that's the "billion-dollar mistake". Not the existence of nulls, but null references: that it's possible to have an object reference that doesn't reference an object; the fact that having an object of type T does not guarantee that you have an object of type T.
Admin
By that, you mean "In Scala, and java when using Scala's Optional type", because Java 8 introduced it's own Optional type, which permits Optional.empty() or Optional.of(value), but doesn't permit of(null). (and has Optional.ofNullable(valueMaybeNull) which returns Optional.empty() if provided null)
Both have their usefulness, depending on if you need an explicit indication of there being a (non-null) value, or if you need to distinguish between no value was supplied vs. the value supplied was null/empty.
Admin
They could have declared a third constant named EMPTY.
Admin
I suspect it's partly due to requiring a somewhat more complicated compiler to avoid all those Optionals taking up extra space, on top of language features to make sure you do the check.
Admin
No they don't. At least, they don't in languages that were designed with optionals from the start.
Optional<T>is a different type toTwhich means that the compiler will refuse to compile programs where you haven't explicitly unwrapped the value of typeT. This contrasts with the null reference approach because a null reference - in Java - is the same type as a non null reference. The compiler cannot enforce checking.Admin
Even back in the 80s, I couldn't remember whether 0 was true or false. (Probably because UNIX return codes of 0 were "good", but in C 0 was false.)
For my own sanity, I always used:
Addendum 2025-09-02 11:32: I'm sure I would have added a space after TRUE to align the operators. It took years of using source-code-control to break that habit.
Admin
const FILE_NOT_FOUND = None