Design Meeting Agenda, 11/4/2020

[DanielRosenwasser]

override and noImplicitOverride

#39669

• By default, it at least says "you must override" if you put the modifier there.
• With the flag, you have to say
• With DefinitelyTyped, will we say you can't use this flag?
  • Think that we make an exception for ambient contexts (.d.ts files)
  • Good: that could break a lot of people.
  • Also enables "down-leveling".
• Should we have override in .d.ts emit?
• We removed async and * from .d.ts files - isn't pertinent.
• What about supporting older versions.
  • downlevel-dts
• Don't feel like it adds value in a .d.ts file.
• What about dependencies A and B, A makes a rename, B needs to be updated.
  • You want to give the user a heads up.
  • But that is sometimes unactionable in the meantime.
• Cannot enforce it in declaration files - too painful.
  • Purely advisory.
• Not being able to support .d.ts files in old versions is always a pain.
• What about a JSDoc tag?
  • Maybe preserving in the generated docs at the very least?
• Maybe we should ban it in a .d.ts file.
  • But then you can't emit it later because it will break people?
  • But if you ban it, you still can gradually enable it.
• Impact on DefinitelyTyped is pretty manageable ?
• Module augmenations?
  • They're weird anyway.
• Maybe at a later date, we can emit a JSDoc comment in JS or .d.ts for documentation.
• Sounds like
  • No emit of override in .d.ts files.
  • Do not allow override in .d.ts files.
  • JSDoc support needs to be recognized in the PR - validate that we're checking it in JS files.
    • Using our semantics, not anyone else's.

Don't emit abstract members

#40699

• Technically a breaking change?
  • But it only affects people with --useDefineForClassFields
  • That is definitely an abstract property.
• Feels weird - we don't have protected or whatever affect
• We already elide getters/setters that are abstract.
• Seems like we should be consistent in that case.

Implicit any in yield Positions

#41348

• Originally added new functionality behind strictGeneratorTypes

  function* g1() {
      const value = yield 1; // reports an implicit any error
  }

• Generator that yields but doesn't use the result value, no error.

  function* g2() {
      yield 1; // no error
  }

• If contextually typed, you're strongly typed. No error!

  function* g3() {
    const value: string = yield 1; // result is contextually typed by type annotation of `value`, no error.
  }

• If you have an explicit type annotation, no error

  function* g4(): Generator<number, void, string> {
    const value = yield 1; // result is contextually typed by return-type annotation of `g3`, no error.
  }

• Seems good!