Use-case for making weak-types / EPC more strict

[devanshj]

Suggestion

🔍 Search Terms

exact types, epc, weak types, all optional properties

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Consider the following problem...

type Basket = { bananas: number, apple: number }
declare const updateBasket: (f: (state: Basket) => Partial<Basket>) => void

updateBasket(basket => ({ banana: basket.bananas + 1, apple: 10 }))
// oops didn't catch "banana" typo it should have been "bananas"

Imo this should be solved by implementing exact types but given Ryan said in this...

[...]
For the most part where people want exact types, we'd prefer to fix that by making EPC smarter. A key area here is when the target type is a union type - we want to just take this as a bug fix (EPC should work here but it's just not implemented yet).
[...]

Summary: Use Cases Needed

Our hopeful diagnosis is that this is, outside of the relatively few truly-closed APIs, an XY Problem solution. Wherever possible we should use EPC to detect "bad" properties. So if you have a problem and you think exact types are the right solution, please describe the original problem [...]

... hence I'm filing this issue (not sure if it's a bug or a feature). Moreover there's also an involvement of a "weak type" here (namely the Partial<Basket>) so this part of that comment from Ryan also applies...

Related to EPC is the problem of all-optional types (which I call "weak" types). Most likely, all weak types would want to be exact. We should just implement weak type detection (#7485 / #3842); the only blocker here is intersection types which require some extra complexity in implementation.

Also note that this is a very common pattern in state-management libraries, that is take a function that returns a partial of the state to be updated. For example zustand implements this pattern and an user fell for this pitfall shown above and their typo compiled. I think we can agree that it'd be annoying if you debugged for a long time just to find a typo that the type-checker didn't catch.

This can be implemented in user-land though...

type Basket = { bananas: number, apple: number }
declare const updateBasket:
  <F extends [(state: Basket) => ShallowExact<ReturnType<F[0]>, Partial<Basket>>]>(...f: F) => void
  // using variadic args as a hack to workaround the circular constraint

updateBasket(basket => ({ banana: basket.bananas + 1, apple: 10 }))
// Type 'number' is not assignable to type 'never'

type ShallowExact<T, U> =
  T extends U
    ? U extends unknown
        ? { [K in keyof T]: K extends keyof U ? T[K] : never }
        : never
    : U

[RyanCavanaugh]

The root cause of this manifestation (function return expressions) is #241

[devanshj]

I see. Although in this specific use-case requires deep exact types, for instance a typo can be made like this too...

type Basket = { fruits: { bananas: number, apple: number } }
declare const updateBasket: (f: (state: Basket) => Partial<Basket>) => void

updateBasket(basket => ({ fruits: { ...basket.fruits, banana: basket.fruits.bananas + 1 } }))
// oops didn't catch "banana" typo it should have been "bananas"

(Again this is real-world code, people write stuff like this all the time, (and maybe they should use immer instead :P))