Allow setter type to be incompatible with the getter type

Suggestion

🔍 Search Terms

differing accessor types

✅ 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.

⭐ Suggestion

#42425 forces the getter type to be assignable to the setter type. This makes the feature limited on the following DOM typing case, and thus it could be great if the limitation can be lifted.

📃 Motivating Example

[Exposed=Window]
interface CSSStyleRule : CSSRule {
  attribute CSSOMString selectorText;
  [SameObject, PutForwards=cssText] readonly attribute CSSStyleDeclaration style;
};

interface CSSStyleRule extends CSSRule {
    selectorText: string;
    get style(): CSSStyleDeclaration;
    set style(cssText: string); // currently an error
}

document.body.style = "display: none" // thus still an error while the actual behavior allows it 🤔

💻 Use Cases

Allows Web IDL readonly attributes to be assignable, and thus the DOM typing better matches the actual behavior.

Transferred from https://github.com/microsoft/TypeScript-DOM-lib-generator/pull/996.

[rbalicki2]

Hi y’all, I’d like +1 this proposal as well. In Relay (relay.dev), we are working on a feature where graphql linked fields can be updated with simple assignment, instead of the ugly existing API recordProxy.setLinkedRecord(...). A simplified example would be:

const updatableData = readUpdatableQuery(graphql`
  query FooQuery @updatable {
    best_friend {
      ...AssignableBestFriend_user
      name
    }
  }
`, store);
// the type of updatableData would be as follows
type UpdatableData = {
  get best_friend(): { name: ?string },
  set best_friend(value: { $fragmentRefs: AssignableBestFriend_user }): void,
}

This allows us to enforce that any user that can be assigned to best_friend must have had the AssignableBestFriend_user fragment spread at that location. Essentially, using this mechanism, we are letting the Relay compiler validate assignments. However, we don’t want to enforce that any field that is assigned to best_friend must also have a name selection, or to include the $fragmentRefs field from the getter.

(This is only part of what is required to ensure that the assignment is valid, but the rest is irrelevant for the getter/setter discussion.)

Thank you! It would be a pity to be able to roll this out with full type safety for users of Flow, but to have limited type safety in Typescript.

[jlalmes]

+1 for this feature. Flagging this issue that contains lots of great use cases for incompatible getter/setter types: https://github.com/microsoft/TypeScript/issues/2521