Deprecate guard

[aleclarson]

It seems that guard is mostly syntax sugar for this:

import * as _ from 'radashi'

const myAsyncFunc = async () => {…}

await _.guard(myAsyncFunc)

// …same as…
await myAsyncFunc().catch(() => {})

// …or you could use noop instead:
await myAsyncFunc().catch(_.noop)

To mimic the “error predicate” argument:

await _.guard(myAsyncFunc, err => err instanceof MyError)

await myAsyncFunc().catch(err => {
  if (err instanceof MyError) {
    return null
  }
  throw err
})

As we can see, it's not particularly hard to accomplish the same task without guard and it doesn't require whoever is reading the code to learn a new function.

In this RFC, I'd like to collect perspectives on the proposal to deprecate guard. Specifically, I'd like to know if you found guard to be a worthwhile utility in your development experience.

[aleclarson]

I noticed now that it also supports synchronous functions. I think it helps in managing verbosity a lot better there:

const result = _.guard(() => {
  // Do something that may throw…
  return 1
}) ?? 0

let result: number // <- explicit type annotation necessary :(
try {
  // Do something that may throw…
  result = 1
} catch (error) {
  result = 0
}

Though I'm still not convinced it's a must-have utility.

[aleclarson]

Just days later, I found a good use case for it:

// Look for a package that of multiple possible names:
for (const id of ['foo', 'bar']) {
  if (guard(() => import.meta.resolve(id, importer))) {
    return id
  }
}

Still interested in hearing how others are using it. 😄

[MarlonPassos-git]

I’ll be honest, I’ve never used it haha.

It would be interesting if we had some way to gauge which functions are most frequently used to make better decisions in cases like this.

I’ve thought about using GitHub's search API to check which functions are most commonly used in public projects that use Radashi