Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Link to the rule's documentation

https://typescript-eslint.io/rules/no-confusing-void-expression

Description

Following from #8375 (review): we tried enabling @typescript-eslint/no-confusing-void-expression internally and very quickly found it to be inconvenient:

Looking at the changes - TBH I don't really like this rule. I don't think any of these changes improve clarity or readability of code.

The biggest issue I see is that if the function is implicitly typed or explicitly marked as returning void the rule still requires you to change things.

For example this code should pass the rule, IMO:

function returnsVoid(): void {}

function test1(): void {
  return returnsVoid(); // should be fine
}
const test2 = (): void => returnsVoid(); // should be fine

Because there's nothing confusing about that code - the expressions are all typed as void and the functions are typed as void.

Also changes like () => expr => () => { expr } actively reduce readability, IMO, esp when considering the above.

Agreed. @bradzacher and I chatted briefly, and Brad suggested:

1. Adding an option to ignore the void <-> void return case
2. Making that option the default in v8

Agreed! Filing this issue to add that option. We can file a followup if & when it gets in.

Fail

declare function returnsVoid(): void;

function outerReturnsVoid(): void {
  return returnsVoid();
}

Pass

declare function returnsString(): string;

function outerReturnsString(): string {
  return returnsString();
}

Additional Info

No response