Design Meeting Notes: 10/20/2017

[DanielRosenwasser]

Errors & Warnings

Visiting for this meeting: @alexeagle

• Issue Add support for diagnostic severities #13408

• PR: Classify lintish diagnostics as warnings, add treatWarningsAsErrors #19126

• Alex: Current behavior is definitely better than the behavior today.

  • Seems like it's accidental that TypeScript ever got into lint checks.

• Here's how warnings work at Google.

  • "Survivor bias" - warnings that exist and are ignored are "probably fine" because the product already ships.
  • But that means people don't realize that they have new warnings.

• Things that are typically warnings often include style nits that shouldn't be dealt with at development-time.

• Don't suppressions like ts-ignore help with the error-blindness issues?

• One reason we're even thinking about doing this is to help give a better JS experience in VS Code.

• In general though, we'd like to get out of the lint business.

• But we've gone 5 years without warnings in TypeScript, so why is it that for these few cases we want these checks?

  • It's much more expensive for TSLint to do it.
  • We could potentially expose APIs to do this efficiently.

• One big difficulty here is we're trying to align different ideas like "severities" (or even "semantic", "syntactic", etc.) need to have some intended behavior instead of going the other way around.

• Do we believe others will just wrap the compiler and do their own thing?

  • Probably not.

• Do we have a principle that if something is too computationally expensive, that we will adopt it in TypeScript itself?

  • It's too difficult to talk about things in the absolute.

• Why not include try to tie TypeScript more closely to TSLint?

  • Maybe

• Alex: maybe document what the role of the type-checker is

• Conclusion: hold off on dealing with warnings, understand how to improve TSLint, think about how to champion community tooling better by default for projects.

undefined parameters as optional

#12400
#19259
#17644

• Why are the following not equivalent?

  class A {
    constructor(); // Error: overload signature not compatible with impl
    constructor(a: number | undefined) {}
  }
  
  class A {
    constructor();
    constructor(a?: number) {} // this one works
  }

• Can be frustrating, they are mostly equivalent, but have pedantic differences.

• But we have the same problem with properties that are optional.

• Solving this might involve a new missing type.

  • missing would be a supertype of undefined.
  • But this seems extremely confusing - how do you explain how missing is different from undefined, null, never, void, and {}.

• Conclusion: continue next time on TypeScript Design Meeting Z