Question -

I was kind of thinking we would also want to exempt cases where they both includethis, sincethis: Foo | void isn't equivalent to the overload form (playground). Is that not the case?

Wouldn't that break cases that should be flagged for merge like this?

functionfoo(this:SomeClass)functionfoo(this:SomeClass,x:number)

Hmm but using different logic, we could also exempt cases where some but not all signatures havethis: void without breaking the above example

@kirkwaiblinger btw doesreturnsVoid (especially calling it with a function argument) do something tricky in your example that I'm not aware of? It seems to me instead of

overloadedThisVoid.call(returnsVoid(()=>'lol'));

you could just do

overloadedThisVoid.call((()=>{})())

Or more explicitly

overloadedThisVoid.call(1asanyasvoid)

Both of which trigger the same TypeScript error.

Hmm, yeah, I guess it would come down to special-casing aroundvoid, since, in addition to your example, which I agree with, we'd also want to consider:

functionfoo(this:Foo,x:number)functionfoo(this:Bar,x:number)

can still be

functionfoo(this:Foo|Bar,x:number)

Wonder if special-casing aroundvoid is even relevant for non-this parameters too?

functionfoo(x:void);functionfoo(x:number);

Would have to play around to figure that one out.

It appears that TS picks thethis type from the last overload when it comes to.call, lol.

functionfoo(this:string):void;functionfoo(this:number):void;functionfoo(){}foo.call(1)foo.call('a')// Argument of type 'string' is not assignable to parameter of type 'number'.(2345)functionbar(this:number):void;functionbar(this:string|boolean):void;functionbar(){}bar.call(1)// Argument of type 'number' is not assignable to parameter of type 'string | boolean'.(2345)bar.call('a')bar.call(true)

ah right, the unsoundness of TS function typing rears its head again
Do you know why TS doesn't treat embedded void expressions as an error the wayno-confusing-void-expression does? Would be curious to know the explicit rationale from the TS team.

It appears that TS picks thethis type from the last overload when it comes to.call, lol.

Huh. 👀 . Well - that the.bind()/.call()/.apply() types are going over my head at this point 😆

possibly related -microsoft/TypeScript#14107,microsoft/TypeScript#33815,microsoft/TypeScript#38353... they seem to have more to do with teh parameter types than thethis type, but anyway. Let's not stress too much about bind/call/apply type behavior, I suppose. 🤷

Do you know why TS doesn't treat embedded void expressions as an error the wayno-confusing-void-expression does? Would be curious to know the explicit rationale from the TS team.

Not off the top of my head, but I'm sure you'll get (or more likely be pointed to) a thorough answer if you ask in the TS discord.

FYI/PSA - I changed this not to be a type predicate since it's only valid in thetrue branch, not thefalse branch (the function returningfalse does not imply thatparam isnot aTSESTree.Identifier).

Oh I didn't think about TS doing a negative refinement when the function returnsfalse. It would be useful to be able to declare an assertion that only refines in thetrue case