Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion Backlog Slog, 4/16/2018 #23444

Closed
RyanCavanaugh opened this issue Apr 16, 2018 · 1 comment
Closed

Suggestion Backlog Slog, 4/16/2018 #23444

RyanCavanaugh opened this issue Apr 16, 2018 · 1 comment
Assignees
Labels
Design Notes Notes from our design meetings

Comments

@RyanCavanaugh
Copy link
Member

The "Ryan is optimistic about our pace" edition

@RyanCavanaugh RyanCavanaugh self-assigned this Apr 16, 2018
@RyanCavanaugh RyanCavanaugh added the Design Notes Notes from our design meetings label Apr 16, 2018
@RyanCavanaugh
Copy link
Member Author

  • Support a @nonnull/@nonnullable JSDoc assertion comment #23405 Support non-null assertion operator in JSDoc
    • Report from Webpack checkJs conversion
    • Needed for Array#pop in strictNullChecks
    • Some lurking issues for SNC+checkJs, e.g. function fn(x = null) { gives a bad type due to lack of widening
    • 👍 for (/* @nonnull */ expr)
  • Consider collapsing multiple repeated type-related error messages when in --pretty #23393 Collapse multiple error reports in --pretty
    • Certain categories of errors we know will show up many many many times
    • But other categories of error should not be grouped
    • No examples of ideal output?
    • The same error in multiple files may have different meanings
    • Are we talking about what the diagnostics API does, or what --pretty does?
    • What about just stopping at e.g. the first 3 "Cannot find name x" errors per file?
    • Related to multi-location diagnostics issues which lists potentially-collapsible errors
    • Smoosh
    • We should do M-LDs first
      • Does this imply a multi-multi-location diagnostic?
    • We should put effort into our diagnostics like Rust does
    • Revisit at that point
  • Warn on unused property in object literal with spread #23340 Warn for known-overwritten properties in spreaded object literal
    • Seems tempting?
    • 👍
  • Uninitialized variables work around strictNullChecks (follow-up to #13884) #23305 Enforce never-initialized varibles / strictVariableInitialization
    • There is a lint rule for this
    • Error doesn't apply for global variables or for wrong-time assignments
    • Weird that it's not enforced?
    • We have a walk for checking whether parameters are assigned to
    • Sameish as "unused" checks already present
    • No flag for this - breaking change
    • 👍 reuse existing "unused" logic
  • Feature Request / Proposal: constructor type guard #23274 Type guards by expr.constructor (sameish as instanceof)
    • New kind of type guard, not a refinement based on definitions
    • Behaves like instanceof but only does anything in the true branch
    • What about primitives?
      • No narrowing of primitives
    • 👍
  • Inconsistent type compatibility for a type with a call signature and and index signature #23226 isObjectTypeWithInferableIndex returns false for intersection type with index signature
    • Current rule is that T is assignable to S & U if T is assignable to S and T is assignable to U
    • Do we want these lines to be OK or an error?
      • OK
    • Changing intersection type behavior just makes both an error, which is not what we want
    • Why do we exclude objects with call/construct signatures from inferring an index signature?
      • Otherwise function expressions would be StringMaps
    • Kinda want a rule that says call signatures are ok if you have at least one declared property
    • Is this an "I noticed" or a bug? What's the unreduced repro look like?
  • Support locally scoped type alias nodes #23188 Locally-scoped type aliases
    • Discussion of how to read this syntax
    • Sidebar complaining about let expressions
    • People (who?) want a way to introduce aliases in large declarations
    • Can these all be eagerly expanded (to make this easy)?
      • No, because it defeats typeToString
    • 👎
  • Comparing constrained generic types/substitution types to conditional types #23132 Improve behavior of conditional types instantiated with constrained generics
    • Ryan: "This is simple" (Narrator: it wasn't.)
    • This is only for the true case because the false case is not provable due to intersection types
    • Who writes this?
      • Overloads with collapsed parameters using conditional types
      • See example
    • "I'm not seeing why this is that useful" "It isn't"
    • Cautioning: Don't abuse conditional types to write what are really distinct overloads
      • Conditional types should really only appear in the return type position
    • AMF; concrete examples please

Out of time

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Design Notes Notes from our design meetings
Projects
None yet
Development

No branches or pull requests

1 participant