Skip to content

Automatically infer context type constaint for class methods #53237

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

Closed
4 tasks done
Larissa-Kravtsova opened this issue Mar 13, 2023 · 5 comments
Closed
4 tasks done

Automatically infer context type constaint for class methods #53237

Larissa-Kravtsova opened this issue Mar 13, 2023 · 5 comments
Labels
Duplicate An existing issue was already created

Comments

@Larissa-Kravtsova
Copy link

Larissa-Kravtsova commented Mar 13, 2023

Suggestion

There is a difference in TS behavior that depends on whether the type of this for method is explicitly declared or inferred: typescript playground link

If inferred:

class Example1 {
    private field = 1;

    show() {
        return this.field;
    }
}

let example1 = new Example1();
let show1 = example1.show;

example1.show();
show1(); // Runtime error

If declared explicitly:

class Example2 {
    private field = 1;

    show(this: Example2) {
        return this.field;
    }
}

let example2 = new Example2();
let show2 = example2.show;

example2.show();
show2(); // Compile-time error: The 'this' context of type 'void' is not assignable to method's 'this' of type 'Example2'.

I believe it would be more consistent and type-safe if it behaved in Example1 the same way as in Example2: if method is using this then it requires this to be object of given class.

🔍 Search Terms

  • this
  • context
  • constraint
  • type

✅ Viability Checklist

My suggestion meets these guidelines:

  • [] This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

This will probably be a breaking change for mobx code that uses decorators to automatically bind methods to objects.

⭐ Suggestion

Make inferred type for methods that use this be methodName(this: ClassName, ...): ReturnType instead of simply methodName(...): ReturnType.

📃 Motivating Example

More errors will be caught at compile-time: if developer tries to pass method as callback it will fail except for cases where this isn't used.

Example:

class SomeState {
  // ...

  doCoolStuff() {
    // ...
    this.evenCoolerStuff();
  }
}

function SomeComponent(props: { state: SomeState }) {
  const { state } = props;

  return (
    <div onClick={state.doCoolStuff} /> /* will emit error at compile-time */
  );
}

💻 Use Cases

  • It allows to detect errors early when passing methods as callbacks and forgetting about .bind.
@MartinJohns
Copy link
Contributor

Sounds like a duplicate of #28548 to me.

@Larissa-Kravtsova
Copy link
Author

Larissa-Kravtsova commented Mar 13, 2023

Sounds like a duplicate of #28548 to me.

Oh. Yes, it definitely is.

Edit: or not exactly. At this time we already have an option to declare this constraint explicitly and typechecking already can catch those errors; but for some reason type inferrence doesn't work as expected. I don't know if this was the case at 2018 when #28548 was filed.

@Larissa-Kravtsova
Copy link
Author

NVM, it is exact duplicate, I've reread that issue.

@fatcerberus
Copy link

Yeah, this isn't inferred. If you don't specify it, it's just any.

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label Mar 14, 2023
@typescript-bot
Copy link
Collaborator

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

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

5 participants