Design Meeting Notes, 4/16/2021

[DanielRosenwasser]

Intended Behavior of Labeled Tuples

#43567

How is this supposed to act?

type T05<T extends any[]> = Parameters<(x: string, ...args: T) => void>;

// is this a labeled or non-labeled tuple?
type T06 = T05<[number]>;

• T06 is non-labeled.

• Labeling is not a dependable process.

• But is it an error?

  • No
  • Labeling is not supposed to cause errors during instantiation.
  • You'd get inconsistent error reporting. Instantiation is deferred.

• What is the original thing we're trying to fix?

  // This is an error today.
  type Tup<T extends any[]> = [one: 1, ...T];

• Labels should be preserved through spreads.

  • We do preserve the names, but you need to have a name for the ...T which might be dumb because it might disappear.

• Really what this comes down to is

  • The tuple label checks should be purely syntactic.
  • But we need to know if a ...T must be a ...args: T instead or if we can be more lax.

• Should an unlabeled spread be an error if everything else has an error?

• More likely that the user was just confused, the error message didn't tell them what to do. This even confused the team.

• Just make the error message good?

• Could just remove the rule - no reason we couldn't ease it.

• Let's keep it in place, open an issue to add a quick fix maybe, give a better error message.

importsNotUsedAsValues improvements

#43393

import { readFile } from "fs"

// turns into

import "fs"

because it just preserves the imports statements for side-effects.

• But changing this on importsNotUsedAsValues today is a breaking change.
• Svelte users hit this.
• Would Vue?
  • Maybe.
• Idea: new mode, keeps named imports/exports.
  • Will people really use this? Are they just using Babel?
  • Maybe. Check with stakeholders.
• The more we invest in this, the more you have to have a duplicate import/import type statement.
  • Revisit type as a modifier on named imports?