Inference Heuristic for Promises

#40466

• Recently we "fixed" the Promise constructor to leverage functionality where trailing void parameters could become optional.
• However, this breaks a couple of cases - one big one where when promisifying functions.
  • There are no inferences, so we go to unknown, but unknown isn't an optional parameter type.
• Idea: add special inference for the "revealing constructor" pattern.

  • new Yadda(callbackParam => { callbackParam(); });

  • This is really based on

    new Promise(resolve => { resolve(); });

  • Figure out the type arguments for Yadda based on
    • invocations of callbackParam
    • contextual type of use-sites of callbackParam
• What's a use-site? Do you walk the whole tree?
  • We use the text search logic from find-all-refs
  • Unicode escapes?
    • Conditional slower code path.
• No major errors in our test suites.
• This makes sense from a type perspective because [[equivalent to being an input position?]]
• Thought we added logic for making unknown an optional parameter.
  • Only in JS files.
• Feels like this is something we'd do for JavaScript...but could we ever really spec this? Not a lot of generalization.
  • There should be a more general approach.
• Circularities?
  • Afraid of phantom bugs where quick info diverges from the actual type-checked type.
• Very similar to Nathan Shively-Sanders (@sandersn)'s earlier work on investigating use-site inference.
  • Very slow, but very naive implementation, used recursive reference-finding.
• How bad of a break are the current changes (without this PR)?
  • A number of changes in VS Code
  • Can move this code into a quick-fix to help people migrate.
  • Might even be simpler.
• How does this affect --strict mode?
  • Current behavior, this PR are invariant on strict modes.
• Does this break any weird stuff?
  • const x = new Promise(resolve => { resolve(); });
• Conclusion
  • Not this change, nor a more general change, for 4.1
  • Hear out the user feedback, see if we need to revert Promise's resolve's parameter's optionality.

Template Casing Operators

#40336

• People are not in love with the "magic modifiers"
  • Already don't need capitalize and uncapitalize as built-ins - can base them off of conditional types with inference and uppercase/lowercase.
• Some way of denoting user-space types with type aliases instead of type operators.
  • type Yadda = internal
  • type Uppercase<T> = internal("uppercase");
  • type Uppercase<T> = internal["uppercase"];
• Variance computation?
  • We could still do that.
• Would we put constraints in the .d.ts file?
  • Does distributivity still work on this?
• What about powering the feature based on writing actual code with an object model?
  • Not for 4.1.
• Still doesn't work on a locale-aware transform.
• Back to syntax bikeshedding syntax
  • intrinsic
• What are we merging today?
  • Can't rip out the operators in time for beta.
  • Can add the type aliases.
    • Remove the operator in the RC
    • Potentially error in the .d.ts file.
  • Messaging to the community is use the type alias reference versions (i.e. use Uppercase instead of uppercase).
  • Will add some sort of instrinsic modifier on type aliases.