[rectang]

I strongly disagree. The existing getchar() API is not simple at all! All the possible error conditions are still there, they're just obscured by an overstreamlined API which fuses them inappropriately into a single return type. That makes it harder to handle all cases well, because you have to do all the work manually.

[enriquto]

The man page for getchar is a single, easy to read paragraph. To understand algebraic types you need a couple of textbooks.

[dmit]

No, encoding additional information in unused bits of an int that you return is stupid over-engineering that needs multiple textbooks to grok. Option<char>, on the other hand, is the simplest possible solution for this problem.

[bloomer]

I would also like to not that encoding the the Option<char> using the unused bits of the return value is a perfectly valid implementation. But that is exactly what it is, an implementation detail. It could work exactly the same way as today but the programmer wouldn’t have to care about how it was implemented, just whether they got a char or None.

[dmit]

In fact, that's exactly what Rust already does today! Option<char> uses the exact same amount of bits to store as plain char, because the compiler has enough information to encode the Option-ness of char in what it knows is a garbage bit of the underlying type.

https://play.rust-lang.org/?version=stable&mode=debug&editio...

[steveklabnik]

Rust guarantees this, actually.

[enriquto]

> No, encoding additional information in unused bits of an int that you return is stupid over-engineering that needs multiple textbooks to grok. Option<char>, on the other hand, is the simplest possible solution for this problem.

What kind of wicked education you had for this to be the case?

My dad taught me about bits and bytes and words when I was a kid, and by 16 I had a quite solid grasp of it (without any textbook). Then I studied several years and got a phd in applied math (mostly numerical pde, and that involved a lot of programming). Then I have spent 15 more years doing math and programming in several languages (mostly C and Python) and getting paid for teaching data science and signal processing to people who got on to have fruitful jobs in industry. Today, I read the wikipedia page about "option type" [1] and the one about about type theory [2], which seems a prerequisite, and couldn't understand a word.

[1] https://en.wikipedia.org/wiki/Option_type

[2] https://en.wikipedia.org/wiki/Type_theory

[wk_end]

Surely if you have a PhD in applied math you've seen that Wikipedia will often foreground dense theoretical issues, even for topics with straightforward practical applications.

You do not need to understand theoretical type theory to understand options. It's just like a pointer that can be NULL except the compiler makes sure you can't accidentally dereference it if it is. Algebraic data types in general are basically just structs and tagged unions, except the compiler makes sure you can't screw the tags up.

Like, dude, by your own account, you're pretty smart; that's the point of your last paragraph, right? There are, at this point, hoards of Rust and Scala and Swift and Kotlin programmers who can figure out how option types work, and don't seem to have too much of a problem with it and pretty much universally think they're great. Are they actually just smarter than you?

[enriquto]

> Are they actually just smarter than you?

Sure they are. Or at least they do not hold an irrational, primary hatred of over-abstraction like I do. In math there's also people like this, who work in stuff like category theory, logic and whatnot. Fortunately, they are a mostly controlled minority.

[empath75]

I’m a community college drop out and have never taken a CS class and I use options in my code all the time.

It’s just a wrapper around some value that is either Some(value) or None and you need to unwrap it and handle both possibilities for your code to compile.

You don’t need to know anything about monads or ADT’s to understand it.

[enriquto]

But do you understand that some values of a 32 bit int can be used to encode meta-data about a 8 bit char?

If you understand both, which one is conceptually easier to you?

[dmit]

Option<T> is conceptually easier because:

1) It applies exactly the same way to any type, not just char.

2) You don't need to read the man page for every single function that returns an int on the off chance that said int actually contains a bool, a char, or a short plus additional flags.

[epolanski]

option obviously.

I just do not understand what the problem with Option is.

It's either Some(1) or None. If it's some you have the value, otherwise you handle the fact you don't have it.

It's so simple and basically every modern language uses it to handle nullable types.

[empath75]

Options for sure, at least in rust.

Rust has tons of help dealing with options built into the language.

[wyldfire]

You can amortize that cost over all of the problems in the language's domain, not just getchar.