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

Type not captured in generic functions when using a configuration object #15769

Closed
ricokahler opened this issue May 11, 2017 · 2 comments
Closed
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed

Comments

@ricokahler
Copy link

ricokahler commented May 11, 2017

TypeScript Version: 2.3.2

The type isn't captured when using generics inside of a configuration object in some cases.

In particular, the function functionAThatTakesAnObject should capture the type of aNumber so that the type of shouldBeInferedToBeANumber should be number but instead it's given type {}

Code

function functionA<T>(funcThatReturnsT: (something: any) => T, funcThatTakeT: (t: T) => any) {
    let something = undefined as any;
    let hasTypeT = funcThatReturnsT(something);
    return funcThatTakeT(hasTypeT);
}

let aNumber = 5;

// works
functionA(() => aNumber, shouldBeInferedToBeANumber => shouldBeInferedToBeANumber.toExponential());
// still works
functionA(_ => aNumber, shouldBeInferedToBeANumber => shouldBeInferedToBeANumber.toExponential());

/**
 * this is the same as `functionA` but it takes a configuraton object instead
 */
function functionAThatTakesAnObject<T>(opts: {
    funcThatReturnsT: (something: any) => T,
    funcThatTakeT: (t: T) => any
}) {
    let something = undefined as any;
    let hasTypeT = opts.funcThatReturnsT(something);
    return opts.funcThatTakeT(hasTypeT);
}

// works
functionAThatTakesAnObject({
    funcThatReturnsT: () => aNumber, // if there is no parameter, it works
    funcThatTakeT: shouldBeInferedToBeANumber => shouldBeInferedToBeANumber.toExponential()
});

// DOES NOT WORK
functionAThatTakesAnObject({
    funcThatReturnsT: _ => aNumber, // if there is a parameter, it breaks
    funcThatTakeT: shouldBeInferedToBeANumber => shouldBeInferedToBeANumber.toExponential()
});

Expected behavior:

shouldBeInferedToBeANumber should be inferred to be of type `number

Actual behavior:

shouldBeInferedToBeANumber is given type {}

@ricokahler ricokahler changed the title [bug] type inference in generic functions breaks [bug] type inference in generic functions breaks with configuration object May 11, 2017
@ricokahler ricokahler changed the title [bug] type inference in generic functions breaks with configuration object [bug?] type inference in generic functions breaks with configuration object May 11, 2017
@ricokahler ricokahler changed the title [bug?] type inference in generic functions breaks with configuration object Type not captured in generic functions when using a configuration object May 21, 2017
@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label May 24, 2017
@ricokahler
Copy link
Author

ricokahler commented May 24, 2017

I asked about this on stackoverflow and someone discovered that when r...

// this works!
functionAThatTakesAnObject({
    funcThatReturnsT: (r: any) => aNumber, // if there is a parameter, it breaks
    funcThatTakeT: shouldBeInferedToBeANumber => shouldBeInferedToBeANumber.toExponential()
});

...in the call functionAThatTakesAnObject has it's type explicitly stated, then there is no error. I find this strange because r already had the type of any but it works when I re-assert that is has type of any.


Here is a typescript playground showing the error.

Thanks for any help!

@RyanCavanaugh RyanCavanaugh added Design Limitation Constraints of the existing architecture prevent this from being fixed and removed Needs Investigation This issue needs a team member to investigate its status. labels Sep 16, 2019
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Sep 16, 2019

Using context-sensitive functions' return types for inference requires a unification-based algorithm; see #30134

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Limitation Constraints of the existing architecture prevent this from being fixed
Projects
None yet
Development

No branches or pull requests

2 participants