Here's a use case for nullable booleans in the database, at least. Arguably this could be solved with different data modeling, but suppose you have an "Applicat

Here's a use case for nullable booleans in the database, at least. Arguably this could be solved with different data modeling, but suppose you have an "Application" model/table that represents an employment or credit application. The application requires many different steps, so you want to save progress along the way. On Step 3, there are checkboxes for perhaps certifying whether or not you're a U.S. Citizen, or to check if you agree to a certain legal document. Prior to step 3, you wouldn't want to default those values to "false", as they haven't been specified yet by the user, so you leave it as "null". Once the user saves Step 3, you can now be sure that the false or true value is one that came from the user. That being said, I challenge other developers on my team to make sure they have a very good reason for using a nullable boolean. Sloppily using nullable booleans when not needed causes queries and data understanding to be a mess (i.e. what does IsActive == null mean?!), as well as the possibility of introducing subtle bugs. Also, I don't think "nullable boolean" as used by the parent actually should refer to the CLI/GUI, but rather that the setting of whether you've opted in or out would be null by default before the first run, and then the CLI/GUI would force a choice resulting in a non-null true or false for whether to opt-in to telemetry. That doesn't require "nullable" checkboxes, but rather a nullable boolean data field in the .NET Core settings. If you need to represent a "I'm purposefully not making a choice" null boolean value in a UI, use a radio group with 3 options.