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

Explicit spesifiying generic type parameters, while remain should be infer from function parameters #25603

Closed
wesleyolis opened this issue Jul 12, 2018 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@wesleyolis
Copy link

Expect that the remaining generic type parameters that are not explicitly set, should be inferred from the function parameters.

const testsCallBack = {
	test : function (callback : (err : any, result : string) => void)
}

function Prom<R extends any, M extends keyof O = any, O extends {} = any>(object : O, method : M) : void

const sftpWrapper = Prom<ssh2.SFTPWrapper>(testsCallBack, 'test'); // I would expect that the typing engine should infer the remain generics that are not explicitly set.

const sftpWrapper = Prom<ssh2.SFTPWrapper>(testsCallBack, 'tet');// Compiler Error
const sftpWrapper = Prom(ssh2, 'fastGet');// returns a good implementation of the types library

Also see post regarding top type unknown, which could also fix this problem, basically comes down to this being a type infer issues/bug in my opion.

#24439

@AlCalzone
Copy link
Contributor

I think you're looking for #23696

@wesleyolis
Copy link
Author

wesleyolis commented Jul 12, 2018

Their is alot in that post,
@AlCalzone Their is alot in that post, but basically the typing engine inferring an empty {} for the function call below, cause these to function to also be identical, were the more stricter one is chosen over the less stricter one based on parameters.

Typically I envisage this to be order thing, were one would typically choose the least constraining function call when the type system was to intersect the function type signature.
This is typically not what we want when we wanting to return different return type signature based on input signature, we wan the return type signature to be choose from the function call signature, that has the stricts constrains that match.

What are you thoughts regarding, this belongs with the other post, it fit with the partial infer type from air of that post.

const testsCallBack = {
	test : function (callback : (err : any, result : string) => void)
}

function Prom<R>(object : {}, method : string) : () => Bluebird<R>
function Prom<O extends {}>(object : O, method : keyof O) : Bluebird<Extract<O>>

const sftpWrapper = Prom(testsCallBack, 'test'); // return type BlueBird<{}>

@wesleyolis
Copy link
Author

Looks like I will have to check the next release versions, to see if it is all resolved..
I think the part of concern would be the return type and finding the most restrictive match to return the return type to use.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Jul 12, 2018
@typescript-bot
Copy link
Collaborator

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

4 participants