Skip to content

Contextual inference for nested calls that return constructors #57747

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

Open
sandersn opened this issue Mar 12, 2024 · 2 comments
Open

Contextual inference for nested calls that return constructors #57747

sandersn opened this issue Mar 12, 2024 · 2 comments
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

@sandersn
Copy link
Member

#54813 attempted to make this work, but exposed an underlying bug that caused too many instantiations. Once that bug is fixed, the code in #54813 should be re-applied if possible.

Here's an example of something that should work, but doesn't:

// @strict: true
// @noEmit: true

interface Action<TContext> {
  new (ctx: TContext): void;
}

declare class AssignAction<TContext> {
  constructor(ctx: TContext);
}

declare function assign<TContext>(
  assigner: (ctx: TContext) => void
): {
  new (ctx: TContext): AssignAction<TContext>;
}

declare function createMachine<TContext>(config: {
  context: TContext;
  entry: Action<TContext>;
}): void;

createMachine({
  context: { count: 0 },
  entry: assign((ctx) => { ctx }),
});

ctx should have type { count: number }, inferred from the context of assign, but doesn't.

@sandersn
Copy link
Member Author

@Andarist this tracks your original fix until the performance bug which it exposed is fixed.

@weswigham
Copy link
Member

weswigham commented Mar 12, 2024

(For future readers:) #57710 was the issue that prompted the revert, and whatever test case we can distill from it should be considered alongside the repro for the original issue in the OP.

@RyanCavanaugh RyanCavanaugh added Possible Improvement The current behavior isn't wrong, but it's possible to see that it might be better in some cases Help Wanted You can do this labels Mar 13, 2024
@RyanCavanaugh RyanCavanaugh added this to the Backlog milestone Mar 13, 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
Development

No branches or pull requests

3 participants