Narrowing fails with union of functions

[ElianCordoba]

Bug Report

🔎 Search Terms

function union, function union, multiple signatures

🕗 Version & Regression Information

• This is the behavior in every version I tried. It's not fixed in nightly

⏯ Playground Link

Playground link with relevant code

💻 Code

type SimpleFn = (text: string) => string 
type WithArgsFn = (text: string, ...options: string[]) => () => string

interface FnMapper {
  [key: string]: SimpleFn | WithArgsFn;
}

const mapper: FnMapper = {
  foo: (text) => '', 
//      ^^^ Error, text is any, should be string
}

🙁 Actual behavior

Parameter text implicitly has an any type.

🙂 Expected behavior

No error plus text should be of type string

[Andarist]

I can't be sure right now if the root issue is the same but this issue feels related: #48663

[ahejlsberg]

We only infer contextual parameter types from a union of contextual function types when the contextual function types have identical parameter lists, so this is effectively a design limitation. We could possibly do better by inferring the widest possible parameter types in such situations.

[RyanCavanaugh]

It's very very rarely useful to contextually type by a union of functions -- the only cases where it really helps are basically places where you could have used the subtype instead, as is the case here (using WithArgsFn instead).

[fatcerberus]

@RyanCavanaugh For the record, manual subtype reduction isn't possible here because one has a return type of () => string while the other just string. BUT this actually highlights an issue with the code as written: the signatures overlap. WithArgsFn can legally be called without any options, in which case the union with SimpleFn suggests it's intended to return a string. But if a given caller is only passing text there's no way for the compiler to tell the two signatures apart.

[ackvf]

Similar.

Here I am writing a dictionary of "checks" (isAddress, isMatching, etc.) for form validation. The developer is supposed to follow the required form, which was supposed to be enforced by the satisfies operator. Unfortunately the type intellisense breaks with this union. It's such a shame, this would have been a perfect use case. Is it at all possible to achieve something similar with current state of TS?

stack overflow
playground

type Valish = (value: string) => boolean
type CurryValish = (...args: number[]) => Valish

const check = {
  vin: (value) => true,            // ✗ any, should be string
  cin: (curry) => (value) => true, // ✗ any any, should be number string
} satisfies {
  [key: string]: 
    | Valish
    | CurryValish
}

Some other examples of what the object is supposed to hold.
It's basically a function that checks the value of an input, e.g. min(10)(input.value) or notEmpty(input.value)

const c = (regex) => new RegExp(regex)
const r = (characters) => new RegExp(`^[${characters}]+$`)
let minLength, isMatching

export const check = {
  isTrue: (value) => value == true,

  /* numbers */

  min: (min: number) => (value: Numberish) => Number(value) >= min,
  max: (max: number) => (value: Numberish) => Number(value) <= max,
  clamp: (min: number, max: number) => (value: Numberish) => Number(value) >= min && Number(value) <= max,

  /* strings */

  maxLength: (length: number) => (s: string) => s.length <= length,
  minLength: (minLength = (length: number) => (s: string) => s.length >= length),
  notEmpty: minLength(1),
  isTrimmed: (s: string) => s.trim() === s,

  /* regex */

  /** Matches a provided regex. */
  isMatching: (isMatching = (r) => (s) => r.test(s)),
  isAlphaNumeric: isMatching(c(ALNUM)),
  isNumeric: isMatching(c(NUMBER)),
  isDecimal: (decimals?: number) => isMatching(r(DECIMAL_TEMPLATE(decimals))),
  isAddress: isMatching(r(ADDRESS)),
  isText: isMatching(c(TEXT)),
  isUUID: isMatching(r(UUID)),
} as const satisfies { [key: string]: Validator | ((...args: any[]) => Validator) }

type Validator = (value: string) => boolean

[Andarist]

TS can't pick one of the union members here for any given key. This is the same "problem" as this one:

type Valish = (value: string) => boolean;
type CurryValish = (...args: number[]) => Valish;

const fn1: Valish | CurryValish = (value) => true; // implicit anys
const fn2: Valish | CurryValish = (curry) => (value) => true; // implicit anys

And it stems from the fact that you can't really call a union of functions like this. How would you discriminate between members?

type Valish = (value: string) => boolean;
type CurryValish = (...args: number[]) => Valish;

declare const fn: Valish | CurryValish

fn() // const fn: (arg0: never, ...args: number[]) => boolean | Valish

As long as your arguments are different (and you have string and number at the first positions here) that will reduce to never (the parameters are intersected). For example, this one works OK since both functions use number at the first position:

type Valish = (value: number) => boolean;
type CurryValish = (...args: number[]) => Valish;

declare const fn: Valish | CurryValish

fn(10) // ok

This wouldn't help you with those contextual parameter types though, as per #51639 (comment)