Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unexpected type infer for function first argument with default value since 5.1 #57706

Open
1 of 5 tasks
ShenQingchuan opened this issue Mar 9, 2024 · 2 comments · May be fixed by #57708
Open
1 of 5 tasks

Unexpected type infer for function first argument with default value since 5.1 #57706

ShenQingchuan opened this issue Mar 9, 2024 · 2 comments · May be fixed by #57708
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Milestone

Comments

@ShenQingchuan
Copy link

ShenQingchuan commented Mar 9, 2024

🔎 Search Terms

"type infer first argument"

🕗 Version & Regression Information

  • This is a crash
  • This changed between versions v5.0.4 and v5.1.6
  • This changed in commit or PR _______
  • This is the behavior in every version I tried, and I reviewed the FAQ for entries about _________
  • I was unable to test this on prior versions because _______

⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.5.0-dev.20240308#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXy1URBgEYAeAFQD4AKRVALngDEpMcYBPK6gSmaUAUKEiwEKdNjwEiJAEy96TVuwycuimgPjChIAB4AHThngYuRhGw7de8ALzxasAOalBAGnhv5zKKhcfI7UPoH6xqbmltZqGlqhTrQAdKluAM7MANqU3gFcALrBDqH5QuVgeOlmiKSOzgC26a7M1TCErvUA5AAWIBAQOF3eGCDV-oHFoQDe8AC+QpWo1T51ToTEZPSkfEIA9HvwR-AAegD8i1VmUPL1GwrbuwfHpxeXyzW3SU0t8G0d3T6AyGU3gswWSxWACM7nItoh5E9Dsdzu9oWtZJt5PREftkUdUWizGBYZtSLRaD9Whh2qhOk5ev1Bl1QeCkS9UZDiV9MQ9Kc1qbT6fBGcCWSEwfN2Si3kA

💻 Code

export type Factory<T> = (arg1: T, arg2: any) => any
export type Factory2<T> = (...args: [T, any]) => any

declare function infer1<T>(fn: Factory<T>): T
declare function infer2<T>(fn: Factory2<T>): T

const f1 = (msg: string = 'hello', test: any) => { }
const a1 = infer1(f1)
//    ^? const a1: string | undefined
const a2 = infer2(f1)
//    ^? const a2: string | undefined

const f2 = (msg: string = 'hello') => { }
const b = infer1(f2)
//    ^? const b: string | undefined
const b1 = infer2(f2)
//    ^? const b1: string | undefined

const c = infer1((msg: string = 'hello') => { })
//    ^? const c: string
const c2 = infer2((msg: string = 'hello') => { })
//    ^? const c2: string | undefined

🙁 Actual behavior

In my code you'll notice that the type of c is not the same as b, but the argument we passing into function infer1 is actually the same.

I've tested this between v5.0.4 and v5.1.6, but the type of c is different:

// v5.0.4
const c: string | undefined

// v5.1.6
const c: string

After checking v5.1 changelog, I'm still not sure what changes have been made between 5.0 to 5.1.

So I decided to submit this issue as a "Bug report".

🙂 Expected behavior

The type of c is supposed to be string | undefined.

Additional information about the issue

No response

@fatcerberus
Copy link

I thought this might be due to #56506 but that was merged in December while you claim this changed in 5.1 which was released in June so... yeah. No idea.

@Andarist
Copy link
Contributor

Andarist commented Mar 9, 2024

Bisects to 7f292bf...ba42ad3 so likely the culprit is #52609

It's interesting cause inferFromAnnotatedParameters already takes into account optionality - based on isOptionalDeclaration. That function doesn't consider initializers. I'll take care of this.

@RyanCavanaugh RyanCavanaugh added Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases labels Mar 11, 2024
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Mar 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Help Wanted You can do this Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases
Projects
None yet
4 participants