Unfortunately, you're invariably going to end up with a "Some<false>" at some point, and you're going to spend the next 20 years explaining to people why that's not a wart in your language that your if "treats it as true", no matter how much you say "my language doesn't even have true so that's not a valid statement".

It isn't going to matter that it's technically a "JSON::false" or whatever... you're still going to get people calling that a wart forever. ("But a JSON::false would be a None" - no, you need that for either "null" or "missing". A JSON library has to have an exposed "false" value to distinguish it from null and missing, both for input and output.)

I'm not saying that doesn't mean to try this out, but as more of a heads up and something to talk about explicitly in the eventual tutorial.

Personally, I find myself fairly satisfied with if statements rigidly requiring a boolean and refusing to have a concept of "truthiness", which I consider a mistake, and I'm not sure this is solving real problems I've had. A user can always write the Option vs. None themselves in an if statement with mandatory else if they want. This introduces a wrapper level of Option that may not always play nice in real code (I mean, a lot of sum type types essentially already have it built in with things like "type Color = Red | Blue | Green | Unspecified" where adjoining a None is often unnecessary) and may really tempt you towards a concept of truthiness that may be a bigger wart than when you're trying to fix. It's pretty hard for a computer programming language to essentially evict the concept of a "bit" from the language. I'm not sure it can be done in practice, but it's fun to think about it and I encourage the pondering.

▲ moritzwarhier 2 days ago | parent [-]

I admit I didn't read all of your commment.

But is

  Some<false>

different from

  Maybe<false>

? Is it a type-level construct to express a predicate like

  Array.prototype.some

In any case, optional types containing boolean values are definitively an anti-pattern.

And in cases where it's prudent to check for the "presence" of a property containing a

  Maybe<ObjectReference>

, while using coercion, it does not make sense to distinguish false from "falsy".

TypeScript's dynamic narrowing has become pretty comprehensive when it comes to this kind of issue.

Still, Option<Boolean> types are bad in most contexts I think, especially in languages like JS.

Instead of using boolean | undefined , I much prefer explicit defaults (parameters) or properties being declared every time (data).

	▲	jerf a day ago \| parent [-]
		Some<false> was written as the value; the type of that value would be Option<(Some Sort Of Still-A-Boolean)>. I have to write it that way because the entire conversation is about the language not having a boolean, so you can't properly write Option<bool> as a type in that language, which is why I mention it may actually be JSON::boolean or something, as well as several other booleans in other similar situations. My point is that you'll still end up with booleans in them though because you'll still have to have representations of other thing's booleans anyhow.