Suggestion Backlog Slog, 11/6/2017

[DanielRosenwasser]

Try-catch statements should be a target of noUnusedParameters

#19601

• What's wrong with _?
  • Well you don't need it at all.
    • But there's nothing wrong with writing it the other way.
      • Why are we policing this?
        • Well it's unused.
          • We never should have done lints.
          • Let's not do more.
          • Conclusion: Writing it this way is okay, so 👎.

Compiler does not narrow tuples based on length property

#19543

• === might make sense under a stricter tuple mode.
• > is too "cute".
• Conclusion: Depends on how we decide to proceed with stricter tuples.

Nested tagged unions

#18758

• Not sure if we'll be able to do this because that would mean that narrowing would have to create new types.
• This specific case wouldn't need changes, but general case could make things very slow.
• Conclusion: Awaiting more feedback.

Type narrowing on Function.length for either callable type

#18422

• Would need to split up parsing of extends & implements clauses.
• What would we permit here then?
  • Anything but object types?
• Conclusion: 👎

Use generic return types for frequently-casted library functions.

#18415

• Blatantly unsafe.
  • The cast keeps you honest.
  • Seems like a bad idea.
  • "Nahh, bad idea."
• Conclusion: 👎

The info that generic type extends some type is lost during inheritance

#18156

• Conclusion: Working as intended.
  • Also, I need to read issues more closely.

Global object properties should not surface on type level indexing

#18118

• Why shouldn't this be allowed?
  • Well it might not be a keyof an object type.
  • But we allow typeof Foo.valueOf, and new Foo().valueOf.
• We're somewhat inconsistent, but it doesn't seem like the current behavior is problematic.
  • Plus it'd just break people.
• Conclusion: 👎

Need way to express hybrid types that are indexable for a subset of properties

#17867

• People have wanted a "fallback" indexer type.
• We give people the intersection option.
  • Pretty gnarly.
• Kicked the can down the road in Suggestion Backlog Slog, 9/13/2017 #18394
• Still unsure what we want.
• Conclusion: Awaiting more feedback.

Can we define a ReadOnly interface directly?

#17769

• Pretty quickly becomes "I also want a readonly type operator."

• But do we want to add a readonly type operator?

  • Comes up every so often - "I want to create a readonly version of our schema."
  • But how do you remove mutating methods?
    • Mapped types only work on plain old data.

• All of this circles back to immutability discussions

  • Big problem was understanding differences in readonly T and Readonly<T>

• Conclusion: 👎

• Off-topic ideas

  • Sounds like something we'd like to do is make properties in object literals as readonly

Allow object types to have property-like associated types

#17588

• A big benefit we'd see here is just being able to specify type parameters by name somewhere.
• Also local type aliases.
• But you can already much of this with indexed access types.
  • Not a fan of using this types everywhere.
• We want to think about use-cases more.
• Conclusion: Awaiting more feedback.

Allow narrowing properties retrieved from types with index signatures

#17567

• Problem is there's no declaration.
• Permitted to access this anyway.
• We narrow based on nodes anyway.
  • Should just work given that we only check "matchiness" of each property access.
• Conclusion: 👍

Recursive generics in function parameters are inferred as {}, and produce funky Intellisense

#17522

We spent about 15 minutes figuring out an alternate API.

Conclusion: See if adjustments work for the user filing the issue.

Add type relationship functions to checker public api

#9943

• Need a factory API for types.
• Need the type relationships.
• We don't want to have something that specially wraps these APIs.
  • It should just be what we use in the checker.
  • So directly use resolveName
    .* Concern: huge leak of implementation details.
• getBuiltinTypes
  • Returns a frozen object.
• Need things like union factories and the like
• What about creating symbol-less types?
• Conclusion: We need to have a proposal for what we would add to what is currently added to the API.
  • Discuss what is available today on the checker (on the Type, Symbol, and Signature objects).
  • Discuss what we want to further add to the API.