[edflsafoiewq]

Think about cases more complicated than passing a bare literal.

  // Booleans + Named Parameters
  foo(should_scrub=not options.scrubbing_disabled)

  // Single-Use Enum
  import ScrubbingOption, ShouldScrub;
  foo(
    if options.scrubbing == ScrubbingOption::Disabled {
      ShouldScrub::No
    } else {
      ShouldScrub::Yes
    }
  )

[oneeyedpigeon]

If you format the second example more sensibly:

    foo(options.scrubbing == ScrubbingOption::Disabled ? ShouldScrub::No : ShouldScrub::Yes)

it doesn't look much worse at all

[kerkeslager]

I'd actually go further and say that there's no reason I can think of that foo() shouldn't have access to the ScrubbingOption, so just pass that in.

If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex.

As a general rule, "it's more verbose" isn't much of a concern to me: verbosity is a very poor indication of complexity, and entering code with your keyboard simply isn't the bottleneck for writing code (if it is, you aren't thinking about what you're writing enough).

[edflsafoiewq]

> If you have two-option enums and for some reason you transform them into two-option enums that represent essentially the same thing, of course that's going to be unnecessarily complex.

"For some reason" being anything so prosaic as they come from different libraries.

[kerkeslager]

If you have two libraries that aren't explicitly made to work with each other and operate on the same problem domain, being explicit about the translation layer between those two libraries is very much a feature, not a bug. That's absolutely a spot where verbosity and named enums will shine.