New rule: no partial array reduce

[danielnixon]

Suggestion

A new rule that forbids the partial versions of reduce and reduceRight.

Given:

  const arr: readonly string[] = ...; // may or may not be empty

Would be invalid according to suggested rule:

  // compiles, throws TypeError: Reduce of empty array with no initial value
  const foo = arr.reduce((a, b) => a);

  // compiles, throws TypeError: Reduce of empty array with no initial value
  const bar = arr.reduceRight((a, b) => a);

Would be valid according to suggested rule:

  // compiles, doesn't throw
  const foo = arr.reduce((a, b) => a + b, "");

  // compiles, doesn't throw
  const bar = arr.reduceRight((a, b) => a + b, "");


  // if you can prove to tsc that you have at least one element, the form without `initialValue` is safe:
  const arr: readonly [string, ...(readonly string[])] = [""];
  const foo = arr.reduce((a, b) => a);

This is equivalent to the situation with reduce versus fold in Scala: https://www.wartremover.org/doc/warts.html#iterableops

[danielnixon]

Here is one that you are welcome to take: https://github.com/danielnixon/eslint-plugin-total-functions/blob/master/src/rules/no-partial-array-reduce.ts

It has 100% test coverage against these examples: https://github.com/danielnixon/eslint-plugin-total-functions/blob/master/src/rules/no-partial-array-reduce.test.ts

[RebeccaStevens]

I'm really unsure about whether to add this or not.
eslint-plugin-total-functions might just be a better home for such a rule.

@jonaskello Do you have any opinion on this?

[danielnixon]

That's fair enough, you won't offend me if that's the outcome.

I had a inkling it might be appropriate over here thanks to the combination of already being anti-exceptions (plugin:functional/no-exceptions) and reduce being an especially common operation in FP-oriented codebases.

[RebeccaStevens]

I'm going to close this as there hasn't been any feedback on it.