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/1/2019 #29694

Closed
DanielRosenwasser opened this issue Feb 1, 2019 · 1 comment
Closed

Design Meeting Notes, 2/1/2019 #29694

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

Comments

@DanielRosenwasser
Copy link
Member

DanielRosenwasser commented Feb 1, 2019

Refactor to Named Parameters

#23552

  • "Named parameters"? what about "parameters object"?
  • What about when there's a contextual type?
    • Doesn't currently work, so we don't make it available.
  • Lots of cases! Direct calls are simple, but then there's issues where you don't know if you can provide a good experience.
  • None of our refactorings deal with this.
    • Ben: not quite true, the async refactoring does have some sort of bailout case.
  • Have to ask where we can offer this, and whether errors after refactoring is okay.
  • Developers have mentioned that they don't trust refactorings that don't definitely have errors when something goes wrong.
    • Could do a check to see whether the first parameter has any property overlap with the produced object argument.
    • But that's useless in JS
    • Could have different behavior for JS.
  • Errors with things that definitely depend on positional parameters.
  • We need to add something to the refactor API that explains why a refactor fails.
  • strictBindCallApply is the only place where
    • Check whether or not all calls are detectable
  • Overloads
    • Not applied right now.
    • Is that okay?
      • Absolutely
  • Overrides - when a subtype overrides a method in its base type.
    • Well it's the same problem as looking for all references of subtypes

    • Yeah, but you can always rename parameters

      class C {
          foo(a: string, b: string): void;
      }
      
      class D extends C {
          // NOTICE: `c` and `d` have different names
          foo(c: string, d: string): void;
      }
  • The fact that users can't apply the refactoring sometimes is actually worse than providing the refactoring and explaining why it won't work.
  • [[5 minute bikeshed over whether or not we should provide an anonymous type for the annotation, or produce a local interface]]
  • JSDoc
    • There's an issue around renaming correctly (confirm @sanders_n)
  • Paramter properties
    • Don't provide the refactor here
  • Rest parameters
    • Doesn't work now, but could refactor the call to take an array of arguments (or tuple).
    • Tuple?
      • Yeah, just depends on the type of the rest parameter
    • Maybe make the property optional entirely?
      • That's a semantic change
      • Just give it an empty array as an empty initializer
  • this parameters
    • Just...just leave it alone.
  • Parameters with initializers
    • Default initializer in a binding pattern
    • Becomes optional in the type
  • All-optional parameters
    • Makes the entire object argument optional
  • What do you do in unannotated JS?
    • Can't be sure! You have no validation when something goes wrong. You have no explicit intent. What if something's optional?
    • Conclusion

es3.d.ts

#28372

  • Why not?
  • Yeah, but why not?
  • First off, those people are targeting ES3 environments, they need some sort of break.
  • Well even the compiler was restricted to ES3, and we could've made our lives easier by setting that as the lib instead of yelling at them not to use .map and .filter and .reduce

Omit in lib.d.ts

#29254

type Omit<T, U extends keyof T> = Pick<T, Exclude<keyof T, U>>;
  • We didn't want to conflict with other Omits that had different behavior - and it would conflict with a global.
  • You're going to run into global scope problems anyway.
    • But you might not, so why are you intentionally breaking people?
  • But there are at least 2 different versions of Omit that are duplicated over DefinitelyTyped
  • Also, this uses Exclude on a generic, so maybe you want to wait for negated types?

Loosening restriction on Array methods taking predicates

#27509

  • {} | null | undefined is wrong, move to unknown
  • filter now allows any which means you can not return
    • Seems like an error worth raising in the type system
  • Why not switch filter to
  • We need a bool-ish type
    • What does that mean
    • "I'm not so bool-ish on that change"
  • This just needs boolean or unknown, not any.
  • Seems like moving from any to unknown is reasonable.
  • find and filter being different stinks.
  • Decide to try it out on RWC

Handling class fields breaking changes

#27644

Interesting ideas

  • Add AST/checking support before we add .d.ts emit support
  • Add .js emit support later on.
  • Maybe flip the name to modernClassFieldEmit?
  • Can you make it depend on the target?
    • Feels weird?
  • Need a good way to evangelize the change if we do this, but the truth is that this is just slower and doesn't actually match our mental model of how the feature should work.
@SlurpTheo
Copy link

  • "I'm not so bool-ish on that change"

🤣

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