Could you elaborate? I think I understand "boolean blindness" but I'm not sure how it applies here. MaybeFoo.type is deliberately an enum.

(I could totally be missing/misunderstanding something, though...)

Checking whether mf.type is NOTHING or JUST is your boolean. It's linked by providence to whether or not getFoo() is a runtime exception. With a true ADT getFoo would not be accessible unless mf.type == JUST, but in this example it's up to the programmer to enforce that providence.

So that's the blindness. The pre/post conditions around how mf.type relates to its surroundings cannot be expressed first-class in the code. You are required to do risky things like call potentially partial code.

So it's specifically the separation of the check and the action? I totally agree this is undesirable; I understood "boolean blindness" to be closer to "bare primitive types lack meaning", specialized to Bool.

I always think of it as your data types being too unrestricted so as to allow for invalid states. The eliminator for Maybe

    (a -> r) -> r -> Maybe a -> r

means you only access the `a` if it's there and the access/matching are inextricably linked.

So, I think "bare primitive types lack meaning" is basically correct given that you interpret "meaning" as "meaningful uses/actions".

Yeah, given the nature of the types involved here, I think the two concepts I was trying to distinguish are not as far apart as I'd thought.