Design Meeting Notes, 4/26/2023

[andrewbranch]

#54000

• Inference priority problem between never in empty array and T
• Difference between inference in two instantiations of same alias and structural algorithm
• Fixes are likely to be over-targeted corner cases, trading one problem for another
• Conclusion: do nothing

#53995

• PR doesn't affect indirect recursive tail calls, only direct self-calls
• Looks good
• A function that only tail calls itself and never returns anything else will be never, used to be an error
• May need to fix an implementation detail, ensuring the call expression expression is identifier

#53999

• Would we rather revisit the whole set of rules around specifying type parameters on function calls? With this proposal, it seems like we'd always suggest people write preferinfer. Can we just do something like that behavior by default?
  • We could try just using inference instead of defaults on type parameters with defaults, only using the default if no candidates were collected
• This proposal has a limitation of only omitting trailing arguments, whereas the _ placeholder PR lets any parameter be omitted
• A modifier on the type parameter doesn't make sense
• There's something fishy about having a situation where type arguments need to be manually specified anyway
  • There are a lot of poorly designed APIs like this in the wild already
  • Specifying a type argument can be useful in the same kinds of cases where it's useful to explicitly annotate a variable declaration, like setting the element type of an empty array (new Set<string>() comes to mind)
  • People also use additional type parameters with defaults as scoped type aliases
• Worth looking at _ proposal again, or even just always allowing partial tye argument specification (in expression positions)
  • Type argument arity is first pass of overload selection 😬
• Conclusion: update the _ PR, run RWC, see what happens

#54005

• Maybe Jake broke it
• Oops we're not actually prepared to talk about this one
• At least typescript-bot successfully bisected it
• In an ideal world we'd be able to try both and see which one works
• Conclusion: Anders would like to look at it

#53970

• Someone is relying on an implementation detail of when we resolve indexed access type to make a higher-order polymorphism mechanism
• We now defer reduceable intersection types when they occur in indexed access types
• The deferral is kind of the right thing to do, but it breaks the example
• (F & { readonly A: A })['type'] used to reduce to F['type'] without acknowledging that the intersection could produce never
• We could potentially fix this by doing the intersection reduction (A & B)[C] to A[C] & B[C] during inference and inferring from both

#54011

• Needed for a version of Monaco that doesn't bundle TS so you can dynamically figure out what libs are available
• Might be more future-proof to expose it as a function instead
• Can you not just read all the file names in typescript/lib?
  • No, because you might be getting TS files from a CDN, and there's not necessarily a consistent way to get a listing

[Andarist]

This proposal has a limitation of only omitting trailing arguments

Yes, that's true - I forgot to mention that in the feature request but this limitation was knowingly there. I consider that to be a fair tradeoff because the goal of the proposal was that the consumer/user of the function signature wouldn't have to do anything to utilize this feature. I also worked under the assumption that the default behavior of choosing defaults over potential inferences just can't be changed.

There's something fishy about having a situation where type arguments need to be manually specified anyway

I can sympathize with this as a basic rule of thumb but I have situations in which this makes a lot of sense. Argument types are meant to be derived from the type arguments but at times there might not even be good inference candidate spots for certain type parameters. In a similar way, I've seen Ryan mentioning that a contravariant-only inference is fishy - and I agree, usually it is. But with certain APIs we need that - so we either allow for partial type arguments application and avoid contravariant-only inferences or we have to rely on them because partial type arguments are not a thing. Both solutions are fishy - to some extent 😉 Anyway, I feel like those situations arise often in schema-based APIs and in case of aggregates/bulk/factory APIs when people want to "bind" things to certain argument types while inferring the rest. I've seen that quite a bit in the wild (and in some of my APIs as well). This also gives a better manual control over subtype/supertype selection and accidental widening etc.

Conclusion: update the _ PR, run RWC, see what happens

Is there anything I could help out with on that front? I care about this feature a lot and I'd love to keep the ball rolling :)

[mikearnaldi]

We could potentially fix this by doing the intersection reduction (A & B)[C] to A[C] & B[C] during inference and inferring from both

If I understand this correctly it would work for inference but signatures would still become horrendous to read

Someone is relying on an implementation detail of when we resolve indexed access type to make a higher-order polymorphism mechanism

I wouldn't call something that has semantic meaning an implementation detail, the deferred resolution of indexed access was confirmed as expected / intentional in prior issues such as #40928