Would syntactic sugar for ifM, unlessA, and whenA be worth adding?

[morgen-peschke]

For boolVariation keys, it seems common to end up passing this directly to ifM, whenA, or unlessA, is this something that would be worth adding helpers to make this a bit smoother?

Current:

launchDarklyMtlClient
  .boolVariation("some-feature-flag", false)
  .flatMap { tryV2 =>
    if (tryV2) algebra.foo else algebraV2.bar
  }

launchDarklyMtlClient
  .boolVariation("some-feature-flag", false)
  .ifM(
    ifTrue = algebra.foo,
    ifFalse = algebraV2.bar
  )

launchDarklyMtlClient
  .variation(SomeFeatureFlag)
  .flatMap { extraLogging =>
    logger.info("Extra logging stuff").whenA(extraLogging)
  }

Proposed:

launchDarklyMtlClient
  .ifV("some-feature-flag", false)(
    ifTrue = algebra.foo,
    ifFalse = algebraV2.bar
  )

launchDarklyMtlClient
  .whenV(SomeFeatureFlag) {
    logger.info("Extra logging stuff")
  }

[bplommer]

I'm not against this, but I've always been sceptical of the value of ifM specifically - what benefit does it actually give over flatMap and pattern matching, as in the following?

foo.flatMap {
  case true => ???
  case false => ???
}

[bplommer]

I can see the value of whenV - it scratches an itch I often have. But it feels to me like something that could be served in a more generic and composable way by adding new syntax in cats. Not whenA, but an extension for F[Boolean] that takes F[Unit] as an argument. So the syntax would then be

launchDarklyMtlClient
  .boolVariation("some-feature-flag", false)
  .newCatsCombinator(doSomething)

Slightly more verbose, but more widely applicable and with less library-specific cognitive overhead. WDYT?

[morgen-peschke]

I'm not against this, but I've always been sceptical of the value of ifM specifically - what benefit does it actually give over flatMap and pattern matching, as in the following?

foo.flatMap {
  case true => ???
  case false => ???
}

No clue, I'm mostly here for whenA and unlessA and it felt weird to leave ifM out when the implementation was trivial 🤷🏻

[morgen-peschke]

I can see the value of whenV - it scratches an itch I often have. But it feels to me like something that could be served in a more generic and composable way by adding new syntax in cats. Not whenA, but an extension for F[Boolean] that takes F[Unit] as an argument. So the syntax would then be

launchDarklyMtlClient
  .boolVariation("some-feature-flag", false)
  .newCatsCombinator(doSomething)

Slightly more verbose, but more widely applicable and with less library-specific cognitive overhead. WDYT?

I think it would be more likely that it would be something like this (mostly because I can't think of a name that would work in the opposite direction), which already exists for OptionT :

  doSomething
    .whenM(launchDarklyMtlClient.variation(SomeFeatureFlag))

Which would work well enough, the primary argument against doing it this way would be if it would be something that could get merged into cats in a reasonable time frame or not.

The turn-around time on PRs can be agonizing, and I'm not sure if this is something worth waiting six months for. Could just be my bad luck though 🤷🏻

Edit: might not be just me, looks like typelevel/cats#4626 has been in the works for almost exactly one year 😅