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

Design Meeting Notes, 2/3/2021 #42631

Closed
DanielRosenwasser opened this issue Feb 4, 2021 · 1 comment
Closed

Design Meeting Notes, 2/3/2021 #42631

DanielRosenwasser opened this issue Feb 4, 2021 · 1 comment
Labels
Design Notes Notes from our design meetings

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 4, 2021

Separate Get/Set Types and Modifiers

#42425

  • Long-standing request for getters/setters to differ in their visibility and types.
  • Have some of this implemented now
  • Current rules is getter type must be a assignable to the setter type.
  • Also have examples where a getter can have public visibility and private visibility.
  • Privacy rules?
    • Get accessor must be at least as accessible as the setter too.
    • Can't have a private get but a public set.
  • When we have an intersection/union type, and they have differing modifiers/types, we should... do something?
  • What about set: T, get: undefined | T?
    • Opposite to rule - but you want to say you can't assign a T
    • Legitimate case, kind of what missing is.
    • Is the "missing" case the only exception to the rule?
  • Implementation needs to thread through "read-side"/"write-side" code on intersections/unions.
  • Breaking change in .d.ts emit?
    • Maybe?
    • No, couldn't write this code today.
  • JSX case?
    • Doesn't happen with component props - does with lowercase tags where you meta-program on the HTML element attributes.
  • Assignable to/from?
    • No, let's stick with one direction from one to the other.
  • Comparability?
    • Revisit later.
  • Should we have some sort of principled stance on DOM APIs that implicitly coerce?
    • window.innerWidth = "100"? (we don't know if it works this way, but whatever)
    • Do you want `${number}`?
    • set value(p: number | `${number}`)?
    • So gross, it's beautiful, we love it.
    • Why wouldn't you just write out window.innerWidth = 100?
      • You didn't realize that's what you wanted until you wrote it.
      • Exactly though.
      • Kind of nice to just let it "work" early on.
    • Defer for now.
      • Surprising because DOM seemed like one of the motivating scenarios.
@DanielRosenwasser DanielRosenwasser added the Design Notes Notes from our design meetings label Feb 4, 2021
@thw0rted
Copy link

Re: implicit conversion for DOM APIs, myInput.selectionStart = document.querySelector("input[type=number]")?.value is assigning a string, but per this MDN page it's guaranteed to be one that coerces correctly to a number (or the empty string). Your "gross, beautiful" solution would let that work, I think.

(window.innerWidth is readonly, but HTMLInputElement#selectionStart is not, and allows number | null.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

2 participants