Okay I discovered that unifying them with this: PromiseConstructor | void, so I guess not a false positive

Actually...reopening because this: PromiseConstructor | void currently triggers @typescript-eslint/no-invalid-void-type.

Why isn't it possible to unify them as this: PromiseConstructor | undefined?

TypeScript doesn't seem to like undefined when calling a function without any this binding

2684: The 'this' context of type 'void' is not assignable to method's 'this' of type 'PromiseConstructor | undefined'. 13:1 - 13:16

https://typescript-eslint.io/play/#ts=5.7.2&fileType=.tsx&code=KYDwDg9gTgLgBDAnmYcAKUIFsCWBnYAdRxgAsAlYPCAGwDdgo8AeAFQD44BeOAbwCg4cAPTC4AOkn8Avv36hIsOADMArgDsAxjBwR1cAO4kKVWgyZt2ACkEJS%2BAFzpMuAgGE9eGFFXbocAB84DQATYGUcdWAQ-gBKJwxsfCJjSmp6RhYOPlsoYBhVKH0BISFRCSkhWVl%2BIzI0s0yrWKA&eslintrc=N4KABGBEBOCuA2BTAzpAXGUEKQAIBcBPABxQGNoBLY-AWhXkoDt8B6WJygM0sQBNaySgHMmAQ3yxoKdFETRoAe2iRwYAL4h1QA&tsconfig=N4KABGBEDGD2C2AHAlgGwKYCcDyiAuysAdgM6QBcYoEEkJemy0eAcgK6qoDCAFutAGsylBm3TgwAXxCSgA&tokens=false

PromiseConstructor | undefined seems to work in the implementation declaration for the overloaded example, but not as a non-overloaded function.

Great thanks, that's helpful. This is starting to look like a bug to me.

1. Playground: the original code plus withResolvers()
2. Playground: fixed code plus withResolvers() showing the type error on the this context

I think what's happening is that the rule isn't understanding the difference between the implicit this: void context in withResolves() and the explicit this: undefined context in a potential combined withResolvers(this: PromiseConstructor | undefined). It thinks the two are equivalent and so thinks the overloads are unnecessary. But, this: void isn't the same as this: undefined.

IMO: bug, but I'm not confident - seeking more input from @typescript-eslint/triage-team?

This does beg the question why TypeScript should give this the type void instead of undefined when calling a function without a binding...I'm struggling to think of any concrete problem it would cause if TypeScript used the undefined type

If I understand correctly, undefined is saying.... that this must have value undefined, whereas void is saying "don't use this!" (playground)

Relates to #10959 and the TS issues mentioned there, too. void | PromiseConstructor is kinda meaningless since void dominates the union in terms of possible values. IIRC the TS team mentioned that they'd see unknown as the better type (where they were discussing the case of void | Promise<void>).

Well I know TS can catch certain errors when you try to consume a return value of type void that it wouldn't be able to catch if the function was typed as returning undefined.

But I haven't managed to think of a scenario where this: void would catch errors that this: undefined wouldn't on a function call with no this binding.

But I haven't managed to think of a scenario where this: void would catch errors that this: undefined wouldn't on a function call with no this binding.

Not a direct answer, but here's a playground link with lots of cases relating to this issue and #10984: link

I think, tentatively, that basically both this issue and #10984 are pedantically "working as intended" tbh. Not convinced of this, though, so perhaps there's a counterexample, or some way that the reports can be improved.

Would preferring unknown over void not be a different rule's realm though?

Would preferring unknown over void not be a different rule's realm though?

Yes... these things are all closely related though so it's a bit tricky to avoid discussing related things.

Looking again, neither this: void | T nor this: undefined | T are equivalent to the overloaded form. Furthermore, this?: T is a syntax error. Therefore, pedantically, the overloaded form cannot be replaced with any unified signature I can come up with.

(playground)

function overloaded(): void;
function overloaded(this: String): void;
function overloaded() { }

function unionWithUndefined(this: String | undefined): void { }

function unionWithVoid(this: String | void): void { } 

function optionalThis(this?: String) { } // ERROR, comma expected

const o = { overloaded, unionWithUndefined, unionWithVoid }

overloaded();
o.overloaded();
overloaded.bind(returnsVoid(() => 'lol'))(); // ERROR

unionWithUndefined(); // ERROR
o.unionWithUndefined(); // ERROR 
unionWithUndefined.bind(returnsVoid(() => 'lol')); // ERROR

unionWithVoid();
o.unionWithVoid(); // ERROR
unionWithVoid.bind(returnsVoid(() => 'lol'));

function returnsVoid(cb: () => void): void {
  return cb();
}

export { };

Unfortunately, the overloaded form is technically unsafe to implement, since it doesn't error on o.overloaded(), and therefore, any this value may be provided at runtime. That's not really this rule's place to say, but it does sort of force you into writing a safer form.

On balance, I'm now thinking, yes, this is a bug and the this parameter should be exempted from the optional parameter overload check, even though the only cases where this comes up are likely unsafe.

I guess there might be an idea of a separate issue to have no-invalid-void-type or some other rule check for overloads with this values that might include void, and request the implementation use this: unknown.

Wow, okay I'll work on a PR to close this can of worms. I guess y'all are right to question what's the point of using this pattern, considering TS doesn't even give the desired errors in a lot of cases.