Inconsistent overload parameters when generic never is present

[kade-robertson]

Not sure if the title makes it super clear what I'm experiencing -- essentially, when using function overloads, where one of the parameters is never typed in one overload, but has a well-defined type in another overload, two different behaviours can occur:

• If the return type does not depend on the generic, the parameter type appears to be correctly resolved as the well-defined type.
• If the return type does depend on the generic, the parameter type is resolved as never. (After further investigation, this might just happen any time the return type is never)

Playground Link

This seems to have started happening after the overhaul to overloaded types was released in v0.20.0 -- in the previous version, this inconsistency didn't occur.

My understanding is that given T | never == T, the parameter type should resolve to whatever the non-never type is. In any case, I would have expected both of these to return the same thing, but maybe this is a bad expectation.

This is reasonably easy to work around by adding a dummy value that prevents the never type, so I'm not particularly fussed.

[mmkal]

Yeah, when making assertions on generics, you can run into trouble unless you do what I have struggled to find better language for than "make them specific".

So you could, in your case, use a function (to avoid any runtime effects) to do something like this:

expectTypeOf(() => getKey(AvailableKeys.KeyA)).returns.toEqualTypeOf<ExpectedSettingsType[AvailableKeys.KeyA]>()

(note, I think there's a bug in your overload implementation in the playground, here's what I think maybe you meant, along with the above example?

You could use a similar technique to turn your resultA, resultB, etc. examples into actual assertions.

Note that we could avoid the awkward expectTypeOf(() => getKey(...)).returns boilerplate if #98 were merged, it's be the slightly-more-explicit:

expectTypeOf((getKey).map(fn => fn((AvailableKeys.KeyA)).toEqualTypeOf<ExpectedSettingsType[AvailableKeys.KeyA]>()

Though there's not all that much gain there beyond making the intent a little clearer.

---

Having said all that, maybe there is something that could be done to avoid the never-ification of certain generics. If you'd be interested in opening a PR, I can take a look - I think we should be pretty well defended against regressions.

[kade-robertson]

(note, I think there's a bug in your overload implementation in the playground, here's what I think maybe you meant, along with the above example?

I think your overload implementation is actually bugged -- providing AvailableKeys.A as a key without a token should cause a type error because restricted keys require an access token for the call to be valid, but your example does not surface that error

---

I can maybe try at some point to resolve the issue -- that overloads type file looks pretty daunting to try and remedy the problem with though.

[mmkal]

I see. A little hard to follow the intent in the original example, does this playground convey more or less what you're talking about, minus the various enums and helper types? Pasted below for reference:

import { expectTypeOf } from 'expect-type';

function getKey<K extends never>(key: K): [K]
function getKey<K extends 123>(key: K, token: string): [K]
function getKey(key: any, token?: string) {
	if (key === 123 && !token) throw new Error('missing token')
	return [key]
}

// these fail, but maybe should pass? They both pass if you comment out the first overload of `getKey`
expectTypeOf(getKey).parameter(0).toEqualTypeOf<123>() // fails, it's `never`
expectTypeOf(getKey).parameters.toEqualTypeOf<[123, string]>() // fails, it's `never` (not even `[never] | [123, string]`)

If so I see what you mean. It's weird to have a function with an overload that only accepts a generic which extends never (note that there's no problem if you remove the generic and the function just accepts never directly) - but I guess I can see how you could end up with it. Probably a bit of an edge case, and might not be worth adding a special case to the overloads helper. Note that the version before the overloads overhaul only really would have worked for you by luck. It relied on the builtin typescript Parameters<...> helper which just arbitrarily picks the last overload, which in your case happens to be the one you care about.

So, in your case you could just do the equivalent of this which works for my simplified example:

expectTypeOf<Parameters<typeof getKey>>().toEqualTypeOf<[123, string]>()

Or wait for the .map helper if you want to control which overload is used, for cases that get even more complex.

If you can find a nice easy modification to the very gnarly overloads.ts, I'd be happy to take a look at it.