Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Meta-issue: Use Full Unification for Generic Inference? #30134

Open
RyanCavanaugh opened this issue Feb 27, 2019 · 29 comments
Open

Meta-issue: Use Full Unification for Generic Inference? #30134

RyanCavanaugh opened this issue Feb 27, 2019 · 29 comments
Labels
Meta-Issue An issue about the team, or the direction of TypeScript

Comments

@RyanCavanaugh
Copy link
Member

Search Terms

unification generic inference

Suggestion

Today, TypeScript cannot retain or synthesize free type parameters during generic inference. This means code like this doesn't typecheck, when it should:

function identity<T>(arg: T) { return arg; }
function memoize<F extends (...args: unknown[]) => unknown>(fn: F): F { return fn; }
// memid: unknown => unknown
// desired: memid<T>(T) => T
const memid = memoize(identity);

Use Cases

Many functional programming patterns would greatly benefit from this.

The purpose of this issue is to gather use cases and examine the cost/benefit of using a different inference algorithm.

Examples

Haven't extensively researched these to validate that they require unification, but it's a start:

#9366
#3423
#25092
#26951 (design meeting notes with good examples)
#25826
#10247

@RyanCavanaugh RyanCavanaugh added the Meta-Issue An issue about the team, or the direction of TypeScript label Feb 27, 2019
@essenmitsosse
Copy link

Wouldn't that be a solution:

function identity<T>(arg: T) { return arg; }
function memoize<F extends <G>(...args: G[]) => G,G>(fn: F): F { return fn; }

// memid<T>(T) => T
const memid = memoize(identity);

Which wouldn't work with non generic functions, but this could be fixed like that:

function memoize<F extends ( <G>(...args: G[]) => G ) | ( (...args: G[]) => G ),G>(fn: F): F { return fn; }

// memid<T>(T) => T
const memid1 = memoize(identity);

function stupid(arg: string) { return arg; }
// memid (string) => string
const memid2 = memoize(stupid);

It's definitely not pretty, but it seems to do the job.

@RyanCavanaugh
Copy link
Member Author

Correct. memoize is possible to write a workaround for, but in more complex cases it isn't possible to fix in user code.

@dragomirtitian
Copy link
Contributor

@essenmitsosse

This approach would work only for really simple cases. If for example there is any constraint on the type parameter of identity we will get an error, and there really is no way to forward the generic type constraint. Also if the number of type parameters is variable we again have an issue, but this could be solved with a number of overloads.

@RyanCavanaugh
Not sure if this is in scope here, but I have seen people often struggle with generic react components and HOCs. There really is no good way to write a HOC that forwards generic type parameters, maintains generic type constraints and removes some keys from props. Not sure if this will ever be possible but one can dream :). A simple example of what I am talking about:

type Omit<T, K extends keyof T> = Pick<T, Exclude<keyof T, K>>

function HOC<P extends { hocProp: string }>(component: (p: P) => void): (p: Omit<P, 'hocProp'>) => void  {
  return null!;
}

// Works great for regulart components
// const Component: (props: { prop: string }) => void
const Component = HOC(function (props: {  prop: string, hocProp: string}) {});

// Curenly an error, ideally we could write HOC to get 
// const GenericComponent: <T extends number | string>(p: {  prop: T }) => void
const GenericComponent = HOC(function <T extends number | string>(p: {  prop: T, hocProp: string}) {

})

@yortus
Copy link
Contributor

yortus commented Feb 28, 2019

@RyanCavanaugh is #29791 another example of something that could be addressed by this? You mention the absence full unification in your comment there.

@airlaser
Copy link

airlaser commented Aug 14, 2019

I'm currently running into this issue, or at least what I think is this issue. I have a class that extends an interface that uses generics. I have to explicitly type the parameters on methods in my class even though the type is already explicitly stated on the interface. If I don't, it complains that I didn't type it and calls it an any. If I type it incorrectly, it tells me the type is wrong, so clearly it knows what type it's supposed to be.

An example:

interface FolderInterface<FolderInfo> {
      getFolderName: (folder: FolderInfo) => Promise<string>;
}

class FolderImplementation implements FolderInterface<WindowsFolder> {
    getFolderName = async (folder: WindowsFolder) => apiCallForFolderName(folder);
}

In FolderImplementation if I don't explicitly type folder it complains that Parameter 'folder' implicitly has an 'any' type. If I purposefully type it incorrectly (for example, as string) it complains that Type '(folder: string) => Promise<string>' is not assignable to type '(folder: WindowsFolder) => Promise<string>'.

Would this be fixed by this? It would be a lot less verbose if I didn't have to re-explicitly-type everything.

@johnsonwj
Copy link

johnsonwj commented Sep 7, 2019

I think I also have an example for this issue:

class Pair<L, R> {
    constructor(readonly left: L, readonly right: R) {}
}

class PairBuilder<L, R> {
    constructor(readonly r: R) {}

    build(l: L) { return new Pair(l, this.r); }

    map<R2>(f: ((r1: R) => R2)): PairBuilder<L, R2> { return new PairBuilder(f(this.r)); }
}

const makePairBuilder = <L> (r: string) => new PairBuilder<L, string>(r);

function f0(): PairBuilder<string, string> {
    return makePairBuilder('hello');
    // resolves as expected
    //    const makePairBuilder: <string>(r: string) => PairBuilder<string, string>
}


const badPair = f0().build({});
// type error as expected
//     Argument of type '{}' is not assignable to parameter of type 'string'.

const pair = f0().build('world');
// resolves as expected
//    const pair: Pair<string, string>


function f1(): PairBuilder<string, string> {
    return makePairBuilder('hello').map(s => s + ' world');
}

// unexpected type error:
//    Type 'PairBuilder<unknown, string>' is not assignable to type 'PairBuilder<string, string>'.

in f0(), the compiler correctly narrows the type for makePairBuilder to match the declared return value. However, when that call is "hidden" behind an extra call to map as in f1(), the inference fails, even with an explicit declaration.

This case may be a more specific and easier to analyze issue; the left type is unchanged by PairBuilder.map which makes it easier to conclude that we can carry it forward through the map() call.

(edit1: fix some wording)

(edit2: remove the unnecessary Pair.map function)

@bogdanq
Copy link

bogdanq commented Dec 3, 2019

link

import React from 'react'

function Parent<T>({ arg }: { arg: T }) { 
    return <div />
}

interface Props<T> {
    arg: T;
}

const Enhance: React.FC<Props<number>> = React.memo(Parent)

const foo = () => <Enhance arg={123} />

@ghost
Copy link

ghost commented Dec 12, 2019

Just tried out above example, with TS 3.7.2 it seems to be working now?

function identity<T>(arg: T) { return arg; }
function memoize<F extends (...args: unknown[]) => unknown>(fn: F): F { return fn; }

const memid = memoize(identity); // memid: <T>(arg: T) => T

const fn = memid((n: number) => n.toString()) // fn: (n: number) => string

Playground

In contrast to 3.6.3 Playground

I am bit puzzled (in positive sense), @RyanCavanaugh did I miss out a feature or so?

@RyanCavanaugh
Copy link
Member Author

@Ford04 good point - the issue in the OP was tactically fixed by allowing some transpositions of type parameters. I need to write up a new example

@ekilah
Copy link

ekilah commented Jan 30, 2020

Is this SO post relevant for your need for a new example @RyanCavanaugh ? https://stackoverflow.com/questions/58469229/react-with-typescript-generics-while-using-react-forwardref

Specifically, I got here because I'm trying to correctly type a call to React.forwardRef, where the component I'm forwarding a ref to has a generic props type. Is this possible? I've struggled to figure out a way to do this without losing the type safety of the generic props type.

@Eliav2
Copy link

Eliav2 commented Nov 3, 2021

Another example that happens all the time to those of us who use noImplicitAny:false:

interface Test<S> {
  func1: (arg) => S;
  func2: (arg:S) => any;
}

function createTest<S>(arg: Test<S>): Test<S> {
  return arg;
}

createTest({
  func1: () => {
    return { name: "eliav" };
  },
  func2: (arg) => {
    console.log(arg.name); //works - name is recognized
  },
});
createTest({
  func1: (arg) => {
    return { name: "eliav" };
  },
  func2: (arg) => {
    arg; // type unknown, why?
    console.log(arg.name); //ERROR - name is NOT recognized
  },
});

very annoying

@nhhockeyplayer
Copy link

nhhockeyplayer commented Nov 12, 2021

My HashSet wont work anymore

TypeError: value.hash is not a function

IUserDTO-> hash()
UserEntity implements IUserDTO-> hash(){}

    add(value: T): void {
        const key: string = value.hash()
        if (!this.hashTable[key]) {   
            this.hashTable[key] = value
        } else {
            throw new RangeError('Key ' + key + ' already exists.')
        }
    }

typescript says value.hash() is not a function when I modeled it properly with an interface and a class that implements the interface in fact it had been working great as hashable

export interface IHashable {
    hash?(): string
}

export interface IHashTable<T> {
    [hash: string]: T
}

but now my generic wont work anymore

whats going on?

Only diff is Im pulling entities off the back end http and collecting them as typeorm entities

are generics toast now? This would take out the entire abstraction layer across the industry.

@nhhockeyplayer
Copy link

I use
"noImplicitAny": false,
to accomodate previously stealth working deep-spread constructs

@nhhockeyplayer
Copy link

nhhockeyplayer commented Nov 12, 2021

well my issue might be this

declaring IHashable interface to be a class Hashable
instead of interface

maybe this is why Im not getting anything under the hood

export class Hashable {
    hash?(): string
}

export interface IHashTable<T> {
    [hash: string]: T
}

export class HashSet<T extends Hashable> implements Iterable<string>, Iterator<T> {
    protected position = 0
    private hashTable: IHashTable<T>

strange how angular and typescript will let one get away with and run with until it finally shows up

I cant imagine generics not working

@nhhockeyplayer
Copy link

still fails

TypeError: value.hash is not a function
    at eval (eval at add (http://localhost:4200/main.js:1:1), <anonymous>:1:7)
    at HashSet.add (http://localhost:4200/main.js:12607:27)
    at HashSet.populate (http://localhost:4200/main.js:12573:18)

Im peeling a TypeORM entity off the back end successfully in its own class that implements hash()

can anyone answer if generics are broken?

@juanrgm
Copy link

juanrgm commented Nov 19, 2021

Another example:

function test<TItem, TValue>(data: {
  item: TItem;
  getValue: (item: TItem) => TValue;
  onChange: (value: TValue) => void;
}) {}

test({
  item: { value: 1 },
  getValue: (item) => item.value,
  onChange: (value) => {}, // value is unknown
});

test({
  item: { value: 1 },
  getValue: (item) => 1,
  onChange: (value) => {}, // value is unknown
});

test({
  item: { value: 1 },
  getValue: () => 1,
  onChange: (value) => {}, // value is number
});

@Andarist
Copy link
Contributor

Based on the comment here: #44999 (comment) the "full unification" algorithm would solve the issue outlined in that issue.

@echocrow
Copy link

echocrow commented Mar 5, 2022

Adding to the list of examples:

Workbench Repro

Excerpt:

interface Example<A, B> {
  a: A
  aToB: (a: A) => B
  useB: (b: B) => void
}
const fn = <A, B>(arg: Example<A, B>) => arg

const example = fn({
  a: 0,
  aToB: (a) => `${a}`,
  useB: (b) => {}
})
// want: Example<number, string>
// got: Example<number, unknown>

Similar (/identical?) in structure to what was reported in #25092.

Have additional utility types or syntax—i.e. some way of helping the TS compiler determine where to infer a generic, and where to just enforce it—been considered?

In the example above, the TS compiler currently seems to want to infer B from the parameter of useB(). As the code author, one could (at least in this case) tell the TS compiler to explicitly infer B from the return type of aToB().

Some examples, extending the example above:

// Explicitly specify from where to infer generic `B`.
interface Example<A, B> {
  aToB: (a: A) => infer B
  // or
  aToB: (a: A) => assign B
  // or
  aToB: (a: A) => determine B
  // or
  aToB: (a: A) => Infer<B>
}

// Or explicitly specify from where to _not_ infer (i.e. just enforce) generic `B`.
interface Example<A, B> {
  useB: (b: derive B) => void
  // or
  useB: (b: Derived<B>) => void
  // or
  useB: (b: Weak<B>) => void
}

Understandably this would just be a duct tape solution to the bigger shortcoming; ideally TypeScript would be able to infer these generics correctly. Given that a revamp of the generic inference algorithm (full unification or some multi-pass attempt) may be too complex at this point, maybe something like this could serve as an "intermediary" solution? No idea if this would be trivial to implement, or equally too complex.

One minor added benefit of explicitly telling the compiler from where to infer a given generic might be that type collisions could then be reported in places where such errors may be more expected. In the example above, a mismatch would be detected and reported in the useB() parameter, as opposed to the aToB() return statement.

Obvious downsides to this approach include additional syntax/utility type, and extra onus on code authors to comply with and work around the compiler.


EDIT (2024-02-08):
TypeScript 5.4 will introduce a NoInfer<T> type, which I believe addresses the issue in this particular post.

@jcalz
Copy link
Contributor

jcalz commented Apr 10, 2022

Is this issue the most appropriate one for the inference failure in the following?

declare function g<T>(x: T): T;
declare function h<U>(f: (x: U) => string): void

h(g) // error, inference of U fails and falls back to unknown
//~ <-- Argument of type '<T>(x: T) => T' is not assignable to parameter of type '(x: unknown) => string'.

h<string>(g) // okay, U manually specified as string, T is inferred as string
h(g<string>) // okay TS4.7+, T is manually specified as string, U is inferred as string

Playground link

Or does there exist another more specific GitHub issue somewhere for this? I can't find one if there is.

@lifeiscontent
Copy link

lifeiscontent commented Aug 24, 2022

@RyanCavanaugh is there a possibility of taking a look at this issue for the next version? I've been running into this issue a lot lately within the react ecosystem.

Example

is there currently a way to overcome this shortcoming without specifying the generic?

@huangyingwen
Copy link

I can't restrict the last parameter to be RequestParams, I don't know if it's related to this problem

type BaseFunc<
  P extends
    | [RequestParams]
    | [never, RequestParams]
    | [never, never, RequestParams]
    | [never, never, never, RequestParams]
    | [never, never, never, never, RequestParams],
  T = any,
  E = any,
> = (...args: P) => Promise<HttpResponse<T, E>>;

export function useFetch<
  TP extends
    | [RequestParams]
    | [never, RequestParams]
    | [never, never, RequestParams]
    | [never, never, never, RequestParams]
    | [never, never, never, never, RequestParams],
  TFunc extends BaseFunc<TP>,
>(fetchApi: TFunc, ...params: Parameters<TFunc>) {
  let controller: AbortController;

  const fetch = (...args: Parameters<TFunc> | []) => {
    if (controller) {
      controller.abort();
    }
    controller = new AbortController();

    args[fetchApi.length] ??= {};
    args[fetchApi.length].signal = controller.signal;

    return fetchApi(...args).then(res => {
      return res;
    });
  };

  fetch(...params);

  onUnmounted(() => {
    controller?.abort();
  });

  return { fetch };
}

@tpict
Copy link

tpict commented Jan 31, 2024

@RyanCavanaugh is there a possibility of taking a look at this issue for the next version? I've been running into this issue a lot lately within the react ecosystem.

Example

is there currently a way to overcome this shortcoming without specifying the generic?

Thanks for this playground–I thought I was losing my mind seeing onClick being inferred correctly according to the hover UI, but the args being implicitly any according to the type checker

@jcalz
Copy link
Contributor

jcalz commented Oct 22, 2024

Linking to @ahejlsberg's comment #17520 (comment) which I always look for when coming here:

[...] TypeScript's type argument inference algorithm [...] differs from the unification based type inference implemented by some functional programming languages, but it has the distinct advantage of being able to make partial inferences in incomplete code which is hugely beneficial to statement completion in IDEs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Meta-Issue An issue about the team, or the direction of TypeScript
Projects
None yet
Development

No branches or pull requests