Ask HN: Do You Use Enum for Yes, No, Unset?

TypeScript is nice because its null type is explicit. So if a type claims to be bool, it is really bool (either true or false, nothing else).

For a nullable variable of type T (including boolean), the type must be explicit about it:

    let choice: T | null;

Another nice alternative is an Option type, like Rust has. I think it would be something like Option.

But those (a null, or a None, respectively) would be only choices if internally, at the code level, the Unset case must be handled as some kind of extraordinary scenario. If it was possible for users to make a conscious decision to leave it unset, i.e. if Unset is part of the valid choices offered by the user-facing API, then I'd encode it as a proper possible state, in an enum.

I'd probably avoid using NULL in DB to convey a borderline-value for the simple reason that NULL has weird semantics in SQL and it can be pretty confusing.

If you're not using NULLs in DB, it's weird to translate an enum into a nullable Boolean.

In the end, there is very little downside to using enums in this case. It's by far the least confusing option.

I use the convention that an 'null' value is a value that was not explicitly set by the user.

So in C#, I would always use a nullable boolean in this case (choices yes and no). If the field is a required value, I would annotate the field as such.

When using the field in an ORM, the required annotation would lead to a not-null field in the database.

When using the field in a dto, the required annotation could be used for validation of incoming input.

If the user should have the choice "yes", "no", "unknown", I would use a nullable enum to express this. An 'null' value means that the value was not explicitly set. The enum value "unknown" indicates that the user explicitly chose the "unknown" value.

So, in both cases the 'null' is not a separate state, it simply indicates that no explicit value was given to the field.

When the final record should have either Yes or No, but the there is an intermediate state where the answer could be missing, you want something like a Maybe which you can map to a simple Bool as part of validation. Ideally you'd use a functor-style parameter for this, for example in Haskell:

  data Record f = Record { …, someField ∷ f Bool, … }
  type PartialRecord = Record Maybe
  type CompleteRecord = Record Identity

  getCompletedRecord ∷ PartialRecord → Maybe CompleteRecord
  getCompletedRecord (Record { …, someField, … }) =
    Record  …  (Identity  someField)  …

This way you can define your record type once and handle all the missing fields in a uniform way, and functions can easily indicate whether they expect a partial record full of Maybes or a complete record with no potentially missing fields. You can use the same type definition for other things, too, by substituting different functors in place of Maybe or Identity. For example, `Record ToString` where `ToString a` is a newtype over `(a → String)` could be a record of functions describing how to render each field as a string.

In the DB you would need to store incomplete records in a separate table, since they have different validation rules. Queries against the main table should be able to assume that all the records are complete.

In the code, it's considered something of a smell to use a bool at all. Look up "Boolean blindness". Basically instead of a bool field saying whether the person wants the deluxe upgrade, you'd have an enum whose values are Regular | Deluxe. How you would represent that in a db would depend on how your implementation works.