Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Design LimitationConstraints of the existing architecture prevent this from being fixedConstraints of the existing architecture prevent this from being fixed

   on Feb 18, 2022
2. RyanCavanaugh commented on Feb 18, 2022

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Feb 18, 2022

   Member

   More actions

   For the case where you exhaust all the arguments, there's really no reason to use bind over a function call.

   For the case where you don't exhaust all the arguments, we don't have a type that can represent that - there's not a type annotation on b that you could write that would make it behave the same way as if its bind argument(s) were present at the subsequent call site.

   function a<T extends Array<any>>(anArray: T, s: T): T {
       return anArray;
   }
   
   // b: ??
   let b = a.bind(undefined, [1]); // b has type () => any[]
3. matthew-dean commented on Jan 19, 2024

   

   Matthew Dean (matthew-dean)

   on Jan 19, 2024

   Last edited by matthew-dean

   More actions

   Ryan Cavanaugh (@RyanCavanaugh)

   For the case where you don't exhaust all the arguments, we don't have a type that can represent that - there's not a type annotation on b that you could write that would make it behave the same way as if its bind argument(s) were present at the subsequent call site.

   Can you explain why? I'm currently trying to map an object with functions that conform to a specific (albeit generic) interface to function types that retain their generic-ness, and I think it's related to this issue.

   In other words, say I have this the following (a super-reduced version of my use-case):

   /* example 1 */
   type Functions = Record<string, ((data: any, errorMessage?: string) => any)>
   
   const fns = (() => {
     function number(data: string, errorMessage?: string): number
     function number(data: any, errorMessage?: string): { output: 0 }
     function number<T>(data: T, errorMessage?: string): number | { output: 0 } {
         // Do something with errorMessage ...
         if (typeof data === 'string') {
           return Number(data)
         }
         return { output: 0 }
       }
   
     return { number }
   })() satisfies Functions
   
   let foo1 = fns.number({}) // { output: 0 }
   let bar1 = fns.number('hi') // number

   Now say I want to support this pattern:

   /* example 2 */
   let doWith = <T, F extends Functions>(value: T, fns: F) => {
     const returnVal = {} as {
       [K in keyof F]: (errorMessage?: Parameters<F[K]>[1]) => ReturnType<F[K]> // ??
     }
   
     for (const [key, value] of Object.entries(fns)) {
       returnVal[key as keyof F] = value.bind(value, value)
     }
     return returnVal
   }
   
   let foo2 = doWith({}, fns).number() // { output: 0 }
   let bar2 = doWith('hi', fns).number() // { output: 0 } but should be number

   IMO there's enough information here for TypeScript to properly infer types, there's just no syntax for it. In other words, the problem is here:

     const returnVal = {} as {
       [K in keyof F]: Bind<F[K], [T, T]> // ¯\_(ツ)_/¯ - basically some way to pass the type to the function type
     }

   TypeScript knows what each function produces in terms of type based on an input type, and that type is known by likewise knowing the input type of the parent function. None of these types are dynamic and they are statically analyzable.

   Ryan Cavanaugh (@RyanCavanaugh) - re-thinking it, maybe what you are saying is that there isn't currently a type annotation that can do this, in which case this would be a feature request instead of a bug report? In which case, what about a top-level Bind type?
4. matthew-dean commented on Jan 19, 2024

   

   Matthew Dean (matthew-dean)

   on Jan 19, 2024

   Last edited by matthew-dean

   More actions

   In other words, a bind statement should be considered by TypeScript to be something like this:

   function something<const T>(data: T, message?: string): T {
     console.log(message)
     return data
   }
   const foo = something.bind(undefined, ['bar'])
   // Type of `foo` should be (message?: string) => readonly ['bar']

   I don't understand any (technical) reason why that can't be inferred? The information for inference is all there.
5. Ryan Cavanaugh (RyanCavanaugh)

   closed this as completedon Feb 24, 2024
6. natew commented on Aug 30, 2025

   

   Nate Wienert (natew)

   on Aug 30, 2025

   More actions

   This would be really nice to have