Design Meeting Notes, 3/31/2018

[mhegazy]

global

• JS
  • PR: Bind toplevel this assignments as global declarations #22891
• issues:
  • type: Expose global declarations on window #19816
  • value (TC39): Add support for ES global proposal #12902
  • namespace: Global type references #983

Issue comes in the context of recognizing assignments to properties on this or window as global declarations.
We need way to refer to the global type, e.g. declare var window: Window & global; for DOM.
We have a precedence in the declare global { .. } support.

Some options:

// use new `import("module")` syntax with `global` instead
var window: Window & import(global);

// or no operand at all
var nan: typeof import().NAN;

// import.meta?
import.meta.global

// C++ anyone?
var x: global::NaN

// call it `global` or just `Global`
var x1: Global;
var x1: typeof Global;
var x1: Global.Array<number>

var x1: Global["NaN"];

var x1: typeof Global.NaN;

TC39 has been looking into a name for the value side of global https://github.com/tc39/proposal-global, the proposal is at stage 3.
The proposal has stalled on the choice of the variable name, global seems to be already in use.

@rbuckton contacted the proposal champion (@ljharb), and the proposal is still active. there are few names proposed at this point.

Conclusion, wait for TC39 to pick a name, and then use that in both type and value positions.

Resolving .json files

• PR: Resolve the modue names with "modulename.json" to json files when doing node module resolution #22167

• issue: In JS, importing JSON should not give an error #7071

• Concerns:

  • .json files can be large, this can impact performance of a compilation
    • should we put it under a switch?
      • probably
    • limit the file size, and if larger than limt, return any.. implicit any maybe
      • does not seem right
      • files can be huge
      • many of them
      • but it is useful for completions..
  • it is good for language service, and for .js file experience

• no contextual type here, do we need a way to "impose" a type on the .json file?

  • seems like an orthogonal issue

• taking the discussion offline until we address the concerns above

Allow infer types in expression type argument positions

• PR: WIP - Allow infer types in expression type argument positions #22368

• @weswigham, this is probably too much power, not clear what use cases require that.

• the change is simple, relatively, thought

• practically gives you associated types

• We still need named type parameters, what to do when you wnat to specify the fifth type parameter and get everything inferred

• we already have a proposal here, no need for another proposal

Array.isArray and ReadonlyArray

• PR: Add support for ReadonlyArray to Array.isArray #22942
• it is a breaking change, we are just trading one set of problems with another
• should not change it
• the core issue is that Array and ReadonlyArray are two distinct types. we need to think about a readonly modifier again

Variadic types

• look at bindCallback in Unable to infer types from callback in bindCallback function for RxJS #22952 (comment)
• we need:
  • a concept of an infinite tuple
  • a way to declare optional members in a tuple
  • a grand unified theory of tuples and function parameters
  • make all of that work in higher order