Design Meeting Notes, 1/20/2021

[DanielRosenwasser]

as const Usage Analysis

(continued from last design meeting)

• Were mostly interested on perf numbers.
  • Looked into some of Artsy's code and Webpack.
  • Looked at 4.1 vs. 4.2
  • 1.6% Webpack, 3% slowdown on Artsy
  • On the every-day machine, not totally scientific, but still generally slower.
  • Mostly just concatenating strings!
  • Might have a recommendation to
• There is some literal widening issues
  • https://github.com/ionic-team/ionicons/blob/1543daa0103c9065805f7075b5dc6abd1c2dd9c1/scripts/build.ts#L262
  • "Our covariant inference is contravariant in its analysis" here.
  • Should have to opt in.
• Whole point was users shouldn't need to opt-in in those cases.
• Argument that this is not the usual behavior people expect still feels compelling.

const aa = "hallo";
const bb = "welt";

// string??
const cc = (aa + bb) as const;

• Wat?
  • What is this winning us?
  • User who is parsing dotted names.
  • Was that string contextually typed?
• Can't unship, so have to decide.
• Some unknowns
  • Contextual type is sort of a "good enough signal".
  • We don't know what literal widening will do.
  • We don't know what people are going to do in the wild.
• We can't have this discussion without

Better-Typed DOM Methods

microsoft/TypeScript-DOM-lib-generator@c81fa76

• Changes are worse - unsafe in presence of contextual type.
• Global override of the signature if you want.
  • A bit heavy-handed.
• JSON.parse is similar. We can't create shortcuts for all of these types of patterns.
• Could we imagine suggesting APIs that work well into the platform?
  • Unclear if we're able to provide a better version of this.
• The as version is not that bad overall.

Instantiation Limiter Doesn't Catch Big Tuples

#41771

• Turns out that doubling makes things go really fast!
• The instantiation depth limiter of 50 isn't "enough" in some of these cases.
• Could introduce an "unreasonable length limit" for tuples, then issue an error.
  • Unclear what length you want.
• 65,535 is good if we need to run on 16-bit platforms!
• Should create a cap on how big a tuple should be constructed.
• But that should be different from whether the type length is derived from a syntactic position (i.e. an array literal) than if it's created purely in the type space.
• Synthesis cap should be different (probably higher?) from the inference cap.
• In addition to instantiation depth, we have the global count of instantiations - worth seeing if there is a mechanism for leveraging that.