Generic values

[masaeedu]

TypeScript supports generic type/interface/class declarations. These features serve as an analog of "type constructors" in other type systems: they allow us to declare a type that is parameterized over some number of type arguments.

TypeScript also supports generic functions. These serve as limited form of parametric polymorphism: they allow us to declare types whose inhabitants are parametrized over some number of type arguments. Unlike in certain other type systems however, these types can only be function types.

So for example while we can declare:

type Id = <T>(x : T) => T

const test : Id = x => x

we cannot declare (for whatever reason):

type TwoIds = <T> { id1: (x: T) => T, id2: (x: T) => T }

const test : TwoIds = { id1: x => x, id2: x => x }

One result of this limitation is that the type constructor and polymorphism features interact poorly in TypeScript. The problem applies even to function types: if we abstract a sophisticated function type into a type constructor, we can no longer universally quantify away its type parameters to get a generic function type. This is illustrated below:

// This works
type Id = <T>(x : T) => T

// This should also work
type IdT<T> = (x: T) => T
type Id = <T> IdT<T> // but is impossible to express

Another problem is that it is often useful to quantify over types other than bare functions, and TypeScript prohibits this. As an example, this prevents us from modeling polymorphic lenses:

type Lens<T, U> = {
    get(obj: T): U
    set(val: U, obj: T): T
}

// no way to express the following type signature
const firstItemInArrayLens: <A> Lens<A[], A> = {
    get: arr => arr[0],
    set: (val, arr) => [val, ...arr.slice(1)]
}

firstItemInArrayLens.get([10])      // Should be number
firstItemInArrayLens.get(["Hello"]) // Should be string

In this case, a workaround is to break down the type into functions and move all the polymorphic quantification there, since functions are the only values that are allowed to be polymorphic in TypeScript:

type ArrayIndexLens = {
    get<A>(obj: A[]): A
    set<A>(val: A, obj: A[]): A[]
}

const firstItemInArrayLens: ArrayIndexLens = { ... }

By contrast, in Haskell you'd simply declare an inhabitant of a polymorphic type: firstItemInArrayLens :: forall a. Lens [a] a, similarly to the pseudocode declaration const firstItemInArrayLens: <A> Lens<A[], A>:

{-# LANGUAGE ExplicitForAll #-}

data Lens s a = Lens { get :: s -> a, set :: a -> s -> s }

firstItemInArrayLens :: forall a. Lens [a] a
firstItemInArrayLens = Lens { get = _, set = _ }

In some sense TypeScript has even less of a problem doing this than Haskell, because Haskell has concerns like runtime specialization; it must turn every polymorphic expression into an actual function which receives type arguments.

TypeScript just needs to worry about assignability; at runtime everything is duck typed and "polymorphic" anyway. A more polymorphic term (or a term for which a sufficiently polymorphic type can be inferred) can be assigned to a reference of a less polymorphic type.

Today, a value of type <A> (x: A) => A is assignable where a (x: number) => number is expected, and in turn the expression x => x is assignable where a <A> (x: A) => A is expected. Why not generalize this so an <A> Foo<A> is assignable wherever a Foo<string> is expected, and it is possible to write: const anythingFooer: <A> Foo<A> = { /* implement Foo polymorphically */ }?

[baptistemarchand]

Any news about this issue?

I have a problem which I think is related, let me know if that's not the case :

Let's say I want to create an object which represents a change, containing a before value and an after value. Like so :

type Change<T> = {
  before: T
  after: T
}

If I try to do something like this :

const change: Change = {
  before: 0,
  after: 1,
}

It doesn't work because the parameter T needs to be explicitly set. Instead I have to use a dummy function which works but seems unnecessary :

const typed = <T>(change: Change<T>) => change
const change = typed({
  before: 0,
  after: 1,
})

[jcalz]

I think that's not applicable here; this issue would be for universally quantified generics (so Change would have to act as a Change<T> for every possible T, which it couldn't be). Presumably your use case is for existentially quantified generics (so Change would act as a Change<T> for some T you don't care about), in which case you want #14466. Or maybe you want the compiler to infer T? If so then you want #32794.

[scorbiclife]

Edit: This happens to work because of a bug in TypeScript's type checker. Please don't use it. For further explanation, continue reading the subsequent posts.

Heyyyyy, good news, I think, everybody! I think I partially implemented this in typescript.

Not sure if this is legit, and it's really ugly, but at least it seems to work.

Could you take a look? (Edit: you might want to look at the other form below)

type Lens<out T, out U> = {
  get<T_>(obj: T_ extends T ? T_ : never): U;
  set<T_, U_>(
    val: U_ extends U ? U_ : never,
    obj: T_ extends T ? T_ : never
  ): T;
};

type ArrayLens<out T> = Lens<T[], T>;

const firstItemArrayLens: ArrayLens<never> = {
  get: (arr) => arr[0],
  set: (val, arr) => [val, ...arr.slice(1)],
};

const intFirstItemArrayLens: ArrayLens<number> = firstItemArrayLens;
intFirstItemArrayLens.get([10]);

const stringFirstItemArrayLens: ArrayLens<string> = firstItemArrayLens;
stringFirstItemArrayLens.get(["Hello"]);

type DeferredCall<out A extends any[], out R> = {
  /* f errors with `A_ extends A ? A : never` for some reason */
  f: <A_>(...args: A_ extends A ? A_ : never) => R;
  args: A;
};

const deferredCallExample: DeferredCall<any[], any> = {
  f: () => {},
  args: [],
};

Also perhaps ping issue 14466 in case this is a legit solution?

Edit: this seems to be a little bit more concise, although I'm not sure if the two forms are equivalent.

type Lens<out T, out U> = {
  get<T_ extends T = T>(obj: T_): U;
  set<T_ extends T = T, U_ extends U = U>(val: U_, obj: T_): T;
};

type ArrayLens<out T> = Lens<T[], T>;

const firstItemArrayLens: ArrayLens<never> = {
  get: (arr) => arr[0],
  set: (val, arr) => [val, ...arr.slice(1)],
};

const intFirstItemArrayLens: ArrayLens<number> = firstItemArrayLens;
intFirstItemArrayLens.get([10]);

const stringFirstItemArrayLens: ArrayLens<string> = firstItemArrayLens;
stringFirstItemArrayLens.get(["Hello"]);

type DeferredCall<out A extends any[], out R> = {
  f: <A_ extends A = A>(...args: A_) => R;
  args: A;
};

const deferredCallExample: DeferredCall<any[], any> = {
  f: () => {},
  args: [],
};

[masaeedu]

Hi @nightlyherb. This is an interesting example, but I think what it illustrates is that interaction between variance checking and quantification constraints is unsound in TypeScript. Here is an example:

type Lens<out T, out U> = {
  get<T_ extends T = T>(obj: T_): U;
  set<T_ extends T = T, U_ extends U = U>(val: U_, obj: T_): T;
};

type MyRecord<A> = { foo: A }

const example: Lens<MyRecord<never>, never> = {
  get: ({ foo }) => foo,
  set: (v, _) => v // i only promised this works for `never`, so this is fine in principle, if a bit useless
};

// But the variance annotations lie, so i can put my useless lens to nefarious use
const test: Lens<MyRecord<number>, number> = example 

const result: MyRecord<number> = test.set(42, { foo: 10 })
console.log(result) // => 42

We can extract a more minimal demonstration of the problem:

// It should not be possible to annotate `A` as covariant
type F<out A, out B> = <X extends A = A>(v: X) => B

const a: F<never, never> = v => v
const b: F<unknown, never> = a
const result: never = b(42) // whoops

There's actually more than one bug with variance checking that I encountered while playing with your code. These might be worth keeping in mind for anyone playing around with this stuff.

For example "methods" don't seem to be checked correctly. If I have:

type Lens<in S, out T, in A, out B> = {
  get(s: S): B
  set(v: A, s: S): T
}

Then I can incorrectly annotate the S and A parameters as out and TypeScript appears not to care. We can boil this (unrelated) issue with variance checking down to the following example:

type X<out S> = {
  x(s: S): never
}

const a: X<never> = { x: s => s }
const b: X<unknown> = a
const whoops: never = b.x(42)

Things are checked "correctlier" if you use { x: (s: S) => never } instead of { x(s: S): never }, but there remains the earlier mentioned problem of interaction between quantified constraints and variance annotations.

---

As a general note, the "trick" of using F<never> to stand for forall x. F<x> is a very useful one, but it only works if F is purely covariant in its type parameter (dually we can use F<unknown> if it is purely contravariant). In this situation the typechecker facilitates a lie about F being covariant ("simple"/non-type-changing lenses are unfortunately fundamentally invariant in both their type parameters), and everything that follows is inconsistent as a result.

[scorbiclife]

Edit: I think I was wrong about this whole post. I think the type I suggested isn't covariant.

@masaeedu Thank you for the feedback, but I think there might be a misunderstanding (probably on my side) which would hopefully get elucidated and resolved with more discussion.

Just so that we're on the same page, I'm aware that F<X, Y> = (x: X) => Y is covariant to Y and contravariant to X.

That being said I think F1<X, Y> = <X_ extends X>(x: X_) => Y or F2<X, Y> = <X_>(x: X_ extends X ? X_ : never) => Y are entirely different expressions, and I actually do think it's covariant w.r.t X (and Y).

This is because you actually can put F1<sub-X, Y> where F1<super-X, Y> is needed.

the first "buggy" example you proposed is exactly how I thought people would use this feature.

const example: Lens<MyRecord<never>, never> = {
  get: ({ foo }) => foo,
  set: (v, _) => v // i only promised this works for `never`, so this is fine in principle, if a bit useless
};

The example works for never, thus it can work for any type T. This is assignable because the way you presented the RHS can be applied to any Lens<MyRecord<T>, T>. If you replace a more specific value on the RHS I do see that it doesn't work.

edit: I think this is why the typechecks pass with the "correctlier" version.

type Lens<out T, out U> = {
  get: <T_ extends T = T>(obj: T_) => U;
  set: <T_ extends T = T, U_ extends U = U>(val: U_, obj: T_) => T;
};

Edit: about this example:

// It should not be possible to annotate `A` as covariant
type F<out A, out B> = <X extends A = A>(v: X) => B

const a: F<never, never> = v => v // this line seems to be the error
const b: F<unknown, never> = a
const result: never = b(42) // whoops

I think the assignment to a is where the error happens, because <X extends A>(v: X) => X is assigned to <X extends A>(v: X) => B.

Other than that all the points you point out with the buggy type inference seems valid.

Looking forward for more enlightenment. Thank you!

[masaeedu]

@nightlyherb

Just so that we're on the same page, I'm aware that F<X, Y> = (x: X) => Y is covariant to Y and contravariant to X.

That being said I think F1<X, Y> = <X_ extends X>(x: X_) => Y or F2<X, Y> = <X_>(x: X_ extends X ? X_ : never) => Y are entirely different expressions, and I actually do think it's covariant w.r.t X (and Y).

I haven't thought very carefully about F2, but let's focus our attention on F1. FWIW it was probably a mistake on my part to include the second type parameter to F1 for the purposes of this discussion, and I should have restricted myself to the simpler type:

type F1<out A> = <X extends A>(x: X) => never

But since we've already started, let's stick with F1 as it is.

Now, what we're interested in is the question of whether F1 "is covariant" in its first type parameter.

There are a number of ways we can approach this question, but one way is to ask: what are the implications for the overall type system if we consider F1 to be covariant in its first type parameter?

The consequence I tried to illustrate above is that it becomes possible to inhabit the never type. Here is that demonstration again:

type F<out A, out B> = <X extends A = A>(v: X) => B

const a: F<never, never> = v => v
const b: F<unknown, never> = a
const result: never = b(42) // whoops

To avoid confusion resulting from the B parameter, here is an analogous example with a single type parameter:

type F<out A> = <X extends A = A>(v: X) => never

const a: F<never> = v => v
const b: F<unknown> = a
const result: never = b(42) // whoops

Now, why is this bad? Of course there are other ways in TypeScript to inhabit never, but these inhabitants typically represent programs whose meaning is a runtime blowup or error or infinite stuck evaluation. Modulo "programs that fail to evaluate", being able to inhabit the bottom/uninhabited/never type is typically an undesirable feature of a type system called inconsistency.

Once you have your hands on an inhabitant of never, the subtyping relation allows you to pretend it is an inhabitant of any type at all, and the ensuing behavior of the program is unspecified.

For example I could proceed as follows:

const whee: { foo: string } = result
const yay: string = whee.foo + "foo"
console.log(yay) // => "undefinedfoo"

In a sense the typechecker sort of just stops working to prevent the sort of problems you'd expect it to prevent. Another way to look at the problem is to interpret the types as propositions and inhabitants as their proofs. In this interpretation the problem boils down to being able to "prove falsehood", since from falsehood, everything follows.

---

Regarding your final edit:

I think the assignment to a is where the error happens, because <X extends A>(v: X) => X is assigned to <X extends A>(v: X) => B.

We don't have a <X extends A>(v: X) => X in the example. What we do have is (x => x) : <X>(x: X) => X, which can be suitably instantiated to yield a (x: never) => never, which is assignable where a <X extends never = never>(x: X) => never is expected.

Perhaps it's clearer if we write out the example like this:

type F<out A> = <X extends A = A>(v: X) => never

const pre: (x: never) => never = v => v
const a: F<never> = pre
const b: F<unknown> = a
const result: never = b(42) // whoops

[masaeedu]

Another (probably more persuasive) way to figure out whether something is covariant or contravariant is to try inhabiting the following two types:

type F<A> = <X extends A = A>(v: X) => never

const map
: <A, B>(ab: (a: A) => B, fa: F<A>) => F<B>
= (ab, fa) => b => undefined

const contramap
: <A, B>(ba: (b: B) => A, fa: F<A>) => F<B>
= (ba, fa) => b => undefined

And see which one you have more success with.

[reverofevil]

@masaeedu I think the example of something crashing in runtime explains it the best.

type F<out A> = <X extends A = A>(v: X) => void
const a: F<string> = v => console.log(v.toString());
const b: F<string | undefined> = a;
b(undefined); // Cannot read properties of undefined

[scorbiclife]

Thank you for the helpful response and pointers. I think I need to take my time to sort this out, thanks a lot and I'll come back with a better understanding, hopefully!

---

I did my homework. Now I'm not so certain about everything, so please take this with a grain of salt.

1. Typescript's generic functions seem to act like they're contravariant over the type parameter's type bound. I'm not entirely sure though.

   Playground Link

   // Assignment succeeds with F<unknown> -> F<string>
   // Assignment fails with F<string> -> F<unknown>
   
   const a1: <T extends unknown>(x: T) => T = (x) => x;
   const b1: <U extends string>(y: U) => U = a1;
   const c1: typeof a1 = b1; // error
   
   const a2: <T extends unknown>(x: T) => string = String;
   const b2: <U extends string>(x: U) => string = a2;
   const c2: typeof a2 = b2; // error
   
   declare const a3: <T extends unknown>() => T;
   const b3: <U extends string>() => U = a3;
   const c3: typeof a3 = b3; // error

   @masaeedu This seems like the {co,contra}variance of the types is independent to whether you can do a {co,contra}map on it. May I ask, did I mess up again, or is this another unsoundness, or is this the way it is? Anyhow thank you so much for the helpful discussion! ❤️

[masaeedu]

@nightlyherb I think it might be best to continue this discussion in a more relaxed setting (without the anxiety of repeatedly pinging a bunch of people subscribed to this issue). I've created a gist here and responded in the comments.

[scorbiclife]

Here's another attempt at representing generic values in TypeScript.

Sample Code

type Lens<in Ti extends { obj: unknown; val: unknown }> = {
  get: <T extends Ti>(obj: T["obj"]) => T["val"];
  set: <T extends Ti>(val: T["val"], obj: T["obj"]) => T["obj"];
};

type ArrayLens<in Ui> = Lens<{ obj: Ui[]; val: Ui }>;

const arrayLensExample: ArrayLens<unknown> = {
  get: (obj) => obj[0],
  set: (val, obj) => [val, ...obj.slice(1)],
};

const numberArrayLensExample: ArrayLens<number> = arrayLensExample;
const typeIsNumber = numberArrayLensExample.get([1, 2, 3]);

const stringArrayLensExample: ArrayLens<string> = arrayLensExample;
const typeIsStringArray = stringArrayLensExample.set("a", ["b", "c", "d"]);

Playground Link

Prerequisites for this to work

This assumes that for generic type F defined as F<in Ti> = <T extends Ti>(generic function having T as its type parameter) is contravariant to Ti. i.e. if Tsub is a subtype of Tsuper, F<Tsuper> is a subtype of F<Tsub>.

• This is the behavior I observed when I manually instantiated F with specific types. You can see that in this post I made a while before.

• Illustrative Example if F<Ti> = <T extends Ti>(x: T) => T,

  • string is a subtype of unknown
  • it seems logical that F<unknown> is a subtype of F<string> because
  • F<string> can be assigned to:
    • (x: string) => string
    • (x: StringSubType) => StringSubType
    • (x: never) => never
    • etc...
  • F<unknown> can be assigned to all of that plus even more types such as:
    • (x: number) => number
    • (x: unknown) => unknown
    • etc...

• I couldn't find unsoundness with this assumption, but I'm terrible at detecting unsoundness so we'll have to see about that...

• Another reason you might want to wait before using this seriously. As of Mar 19 2023, TypeScript can only check (and report errors of) specific instances of F. When you use the generic type F it doesn't check its variance at all and allows all variances over Ti. See my blunder above or #53210.

This is ugly! Why do you have to introduce arbitrary contravariance to do this?

Well, if this helps you in any way,

I intended the types to mean something like...

type Lens<in Ti> = <T extends Ti> {
  get: <T>(obj: T["obj"]) => T["val"];
  set: <T>(val: T["val"], obj: T["obj"]) => T["obj"];
}

type ArrayLens<in Ti> = <T extends Ti> Lens<T[], T>

Which are somewhat meaningful generic types.

Edit: Important Limitation

You cannot represent something like <T> Lens<(x: T) => void, T> because if you try to represent it as type SpecialLens<T> = Lens<(x: T) => void, T> then SpecialLens cannot be contravariant over T. Currently typescript doesn't error on type SpecialLens<in T> = ... so I guess it's another reason we shouldn't use this construct until #53210 is fixed.

[ChuckJonas]

Not having this feature makes it hard to write library code where you want to leverage generics in literal types and allow for relational type constraints around the use of those literals.

Examples

type Tool<P> = {
  name: string;
  parameters: P;
};

const runTool = <T extends Tool<any>>(
  tool: T, handler: (tool: T["parameters"]) => void
) => {
  handler(tool);
};

// it works if we inline it
runTool(
  { name: "string", parameters: { one: "hello", two: false }},
  (params) => {
    console.log(params.one, params.two);
  }
);

// but what if we need to move the literal to it's on declaration?

Workarounds:

1. Explicitly write out type parameters.: this can often be more work than writing the code itself.

2. Leave the object untyped: this doesn't provide the developer with type info/constraints until they go to use it.

3. Use Lens: This is a cool trick, but pollutes the type definitions with complexity that makes it not worth it (IMO).

4. Use an "identity" function: hurts DX as now you have to hunt down an additional function just to make your generic types. Also, I imagine this could have a non-trivial impact on performance in some cases.

Typescript Playground Illustrating all these issues

When the type system forces developers to actually write worse code, then it seems like an issue worth trying to solve.

[pjeby]

Another use case: decorators. I'm in the middle of implementing a bunch of functions that work as both a function wrapper (i.e. wrap(f)) and a method decorator (i.e. @wrap), supporting both legacy and TC39 decorator protocols. I'd like to be able to express this by just wrapping each plain F => F decorator in a function that returns a function that supports all three required overloads (function, function + context, class/name/descriptor):

interface FunctionDecorator<F extends (...args: any[]) => any> {
    (fn: F): F;
    (fn: F, ctx: {kind: "method"}): F;
    <D extends {value:F}>(clsOrProto: any, name: string|symbol, desc: D): D;
}

function decorator<F extends (...args: any[]) => any>(decorate: (fn: F) => F): FunctionDecorator<F> {
    return function<D extends {value: F}>(
        fn: F,
        ctxOrName?: string | symbol | {kind:"method"},
        desc?: D
    ) {
        if (ctxOrName || desc) return decorateMethod(decorate, fn, ctxOrName, desc);
        return decorate(fn);
    }
}

This works great, right up until you wrap a decorator function that's generic, and then it loses its genericity:

const leased = decorator<<T>() =>T>(fn => fn)  

// Type 'number' is not assignable to type 'T'. 'T' could be instantiated 
// with an arbitrary type which could be unrelated to 'number'.
leased(() => 42) 

In theory it's still there: the resulting decorator function is typed correctly as taking and returning a function of <T>() => T, but any specific function you pass in gets an error saying that what it returns isn't <T>, because T could be an arbitrary type. And there doesn't seem to be a way to say, "no, I want you to infer T", except by hand-writing out all three overloads (plus a butt-ugly implementation signature) for every function, which is both tedious and error-prone if you have a lot of these.

(As far as I can tell, this is because consts can't be generic, but please feel free to point me to the correct issue if this one isn't it.)

[scorbiclife]

Hello, TypeScript!

Most of what I'm going to write below is already mentioned in this issue thread. However, I do think some points would be helpful for people in need of this feature, so please be gentle even if this seems like repeating past discussions.

Summary:

1. You can "unhoist" the type parameters of the hypothetical "generic value" type to get a type that is already representable in current TypeScript. (As shown in the "workarounds" for the first post)

2. This type is assignable to every instantiated expression of the original generic type as far as I can test.

3. To resolve this issue it seems sufficient to simply add syntax sugar for this "unhoisting" process.

Edit: Maybe "inline" would be a better word than "unhoist"? Oh well, I already dumped a wall of text...

---

Let's have a recap about the problem we are trying to solve. Given a generic type such as:

type Lens<T, U> = {
  get: (obj: T) => U;
  set: (val: U, obj: T) => T;
};

We want to represent something like <V> Lens<V[], V>, which should be assignable to Lens<V[], V> for every type V. (For those that have types that work for some V but not necessarily for every type, visit #14466.)

For instance, the following should typecheck without errors:

declare const arrayLens: <V> Lens<V[], V>;
const numberArrayLens: Lens<number[], number> = arrayLens;
const stringArrayLens: Lens<string[], string> = arrayLens;
const neverArrayLens: Lens<never[], never> = arrayLens;
const unknownArrayLens: Lens<unknown[], unknown> = arrayLens;

Intuitively, I think of this as the intersection of Lens<V[], V> for all types V. (And existential types #14466 as the union for all types V.)

Anyway, if you see the first post, you can see @masaeedu used the following RHS expression that can be assigned to this hypothetical generic value type:

const arraylens: <V> Lens<V[], V> = {
    get: (arr) => arr[0],
    set: (val, arr) => [val, ...arr.slice(1)],
}

I became curious because this already has a representable type in TypeScript, as shown in the first post:

type ArrayLens = {
    get: <V>(obj: V[]) => V;
    set: <V>(val: V, obj: V[]) => V[];
}

const arraylens: ArrayLens = {
    get: (arr) => arr[0],
    set: (val, arr) => [val, ...arr.slice(1)],
}

So I thought it might be assignable to all array-like instantiations of Lens<T, U>, and indeed it is:

// Type checks without errors
const numberArrayLens: Lens<number[], number> = arraylens;
const stringArrayLens: Lens<string[], string> = arraylens;
const neverArrayLens : Lens<never[], never> = arraylens;
const unknownArrayLens : Lens<unknown[], unknown> = arraylens;

numberArrayLens.get([1, 2, 3]);
numberArrayLens.set(0, [1, 2, 3]);
stringArrayLens.get(["1", "2", "3"]);
stringArrayLens.set("0", ["1", "2", "3"]);

So ArrayLens seems like a valid representation for <V> Lens<V[], V>. Let's compare the two types:

type Lens<T, U> = {
  get: (obj: T) => U;
  set: (val: U, obj: T) => T;
};

type ArrayLens = {
    get: <V>(obj: V[]) => V;
    set: <V>(val: V, obj: V[]) => V[];
}

It's as if you assign T <- V[] and U <- V to the type arguments and "unhoist" the angle brackets for the type params.

If you think about it this unhoisting process is very natural. If ArrayLens = <V> Lens<V[], V>, then ArrayLens["get"] should be able to receive a V[] and return a V, for every type V. This is effectively a <V>(obj: V[]) => V. Same goes for ArrayLens["set"].

Other types behave in interesting ways. If you think about <T> { co: T; contra: (x: T) => number; }, covariance/contravariance over T forces the type to resolve to some trivial type (which is unusable most of the time). In this case, { co: never; contra: (x: unknown) => number; }

What's interesting is that this seems to work well in more complex cases as well. Let's have our last post from @pjeby as an example:

type AnyFunction = (...args: any[]) => any;
interface FunctionDecorator<F extends AnyFunction> {
    (fn: F): F;
    (fn: F, ctx: {kind: "method"}): F;
    <D extends {value: F}>(clsOrProto: any, name: string|symbol, desc: D): D;
}

// The original non-generic type
declare function decorator<F extends AnyFunction>(decorate: (fn: F) => F): FunctionDecorator<F>;
// Generic overload
declare function decorator(decorate: <F>(fn: F) => F): GenericFunctionDecorator;

interface GenericFunctionDecorator {
    <F extends AnyFunction>(fn: F): F;
    <F extends AnyFunction>(fn: F, ctx: {kind: "method"}): F;
    <F extends AnyFunction, D extends {value: F}>(clsOrProto: any, name: string|symbol, desc: D): D;
}

const decoratedGenericFunction: GenericFunctionDecorator = decorator(fn => fn);
const sampleDecoratedFunction: FunctionDecorator<(s: string) => number> = decoratedGenericFunction;

This typechecks without errors, so one could use a FunctionDecorator<F> and use it for both generic and non-generic functions.

Thanks for coming to my TED[1] talk.

[1] Typescript Enhancement Discussion

[pjeby]

Unfortunately, that seems entirely unrelated to the problem I posted. Try replacing (s: string) => number with <T>() =>T in your example, and then try invoking sampleDecoratedFunction(() => 42) (or any other constant value), and you'll get the same "Type 'number' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'number'" error as in my example.

My original code already worked fine with concretely-typed functions (like string => number), but neither it nor your example work with generic function types (e.g. <T>() => T), which was what I was posting about.

That is, the inability of TypeScript to express the genericness of a function that is a value, rather than an explicit function declaration. As far as I can tell, the only way to get an actually-generic function with type inference is to explicitly declare all of the overloads, every time you want to make one.

[scorbiclife]

Unfortunately, that seems entirely unrelated to the problem I posted. Try replacing (s: string) => number with <T>() =>T in your example, and then try invoking sampleDecoratedFunction(() => 42) (or any other constant value), and you'll get the same "Type 'number' is not assignable to type 'T'. 'T' could be instantiated with an arbitrary type which could be unrelated to 'number'" error as in my example.

This error seems to be related to a misunderstanding of TypeScript's type system and is unrelated to this issue. This code gives the same error:

const f: <T>() => T = () => 42;

I think what you intended with <T>()=>T is related to #14466.

As far as I understand it, <T>() => T is a type that can be thought of as "for all types T, the intersection of every () => T". This should be compatible with () => never.

Anyway, we can do the following to achieve what you intended (my bad for not including the specific example of yours) playground link

[pjeby]

As far as I understand it, <T>() => T is a type that can be thought of as "for all types T, the intersection of every () => T". This should be compatible with () => never.

And yet, if you write function x<T>(): T {} it's interpreted as generic. That is, you can declare a function generic, but not a value.

As for the specific example, it still doesn't work: the intent is to define decorators with type checking and inference, not to create a generic decorator that can be applied to literally any function. (e.g. leased() requires a function that can be called with zero arguments, which is why the aim is to have a const of type FunctionDecorator<F>, where F is a type parameter, rather than GenericFunctionDecorator, which is effectively FunctionDecorator<AnyFunction>.)

To put it another way: types and functions can be declared with type parameters, but values cannot. (Which is as I understand it the overall point of this issue.) In the specific case of decorators, it means that one must explicitly declare the three overloads for every such function, and can't use a higher-order function to wrap a simpler wrapping function as a multi-purpose decorator.

It might be that the issue can be resolved at some other level of abstraction, but at the superficial level of "you can spell it this way, but not this other way", it at least looks like the issue is one of being able to define types and functions as generics, but not values or consts.

[scorbiclife]

Edit: Oh, I see, did you mean something like this?

Note: I just discovered you don't need an overload.

[pjeby]

I don't need an overload for a return value, with your approach, it's true. But it fails if I want to write a decorator that requires arguments and has type constraints on those arguments. I'd like to be able to write:

const decorator1 = decorator</* constraints on what kind of function this decorator works with */>(fn => {
    /* implementation 1 */
});

const decorator2 = decorator</* constraints on what kind of function this decorator works with */>(fn => {
    /* implementation 2 */
});

// ....

for any number of decorators, instead of having to write out massive chunks of boilerplate and error-prone overload duplication like:

export function pooled<K extends string|symbol,T>(factory: (key: K) => T): (key: K) => T;
export function pooled<K extends string|symbol,T>(factory: (key: K) => T, ctx: {kind: "method"}): (key: K) => T;
export function pooled<K extends string|symbol,T,D extends {value: (key: K) => T}>(
    clsOrProto: any, name: string|symbol, desc: D
): D
export function pooled<K extends string|symbol,T,D extends {value: (key: K) => T}>(
    factory: (key: K) => T, nameOrCtx?: any, desc?: D
): D | Pooled<K,T> {
      /*
        several lines of duplicated logic for every single
        decorator, instead of being able to use a HOF
      */
      /* implementation 1 */
}

// Repeat **all** the same garbage for decorator 2...

It might be that my problem is more of a "I want to declare that a function implements an interface" problem than a "generic value" problem, but ISTM that being able to declare a generic value (i.e. one with type parameters) would fix it better, given that declaring a function implements an interface only gets rid of the overloads, not the duplicated implementation bits.

(Note that pooled as defined above accepts variants such as string => number, symbol => SomeClass, etc., and returns functions that are of the same type, rather than accepting any (string | symbol) => unknown function and returning a function of that type. Also some decorators will have other type constraints, such as that a certain parameter must be a WeakKey, etc. The point is to have a fully generic HOF for turning F =>F wrappers into functions with two extra overloads that support the TC39 and legacy/experimental protocols for method decorators for the corresponding function type.)

[scorbiclife]

Just for the record, I agree with you that it would be nice for TypeScript to support this feature. I do think that how to work around using currently available TypeScript is valuable information for some people as well (especially because this issue has been remaining open for 7 years), which is why I wrote my recent post.

Anyway, with that said, I think this could be a viable solution, for the subset of this issue, for now:

type AnyFunction = (...args: any[]) => any;
interface FunctionDecorator<F extends AnyFunction> {
    (fn: F): F;
    (fn: F, ctx: {kind: "method"}): F;
    <D extends {value: F}>(clsOrProto: any, name: string|symbol, desc: D): D;
}

// The original non-generic type
declare function decorator<F extends AnyFunction>(decorate: (fn: F) => F): FunctionDecorator<F>;

interface FunctionGenericDecorator<BaseF> {
    <F extends BaseF>(fn: F): F;
    <F extends BaseF>(fn: F, ctx: {kind: "method"}): F;
    <F extends BaseF, D extends {value: F}>(clsOrProto: any, name: string|symbol, desc: D): D;
}

// Note the usage of `() => unknown` instead of `() => number`,
// Because this decorator is supposed to accept *all* types of () => T;
// in other words, subtypes of () => unknown
const leased: FunctionGenericDecorator<() => unknown> = decorator(fn => fn);
// correctly infers type with no type errors.
const decoratedFunction = leased(() => 42);

// This is also assignable to instantiations of `FunctionDecorator<F>`
declare function decoratorConsumer<F extends AnyFunction>(decorator: FunctionDecorator<F>): void;
decoratorConsumer(leased);

This is flying close to the edge cases of TypeScript's type checker (see #53210) but I guess it's available right now. I'm just hoping TypeScript team doesn't break this in the future.

I also think it would be nice if TypeScript could add syntax sugar for similar functionality. (Related: my recent wall of text)

[pjeby]

You already showed that before, and yes it works for 1) parameter-less functions with a generic return value, or else it works for 2) arbitrary functions with no type checking. But since I only have one of the former and none of the latter, it doesn't really address the code duplication issue. I do appreciate your attempts at assistance, though!

[pjrebsch]

My use case for this feature would be to expose a set of partially-/fully-applied generic types from a library implementation which depends on them. The alternative is to require the consumer of the library to essentially redefine all of the library's individual generic types with the appropriate concrete types. This is not ideal as it increases the burden on the consuming integration and introduces the potential for writing all that out incorrectly.

What's bothered me the most about it is that it should not be the library consumer's responsibility to define the library's type concretions—it's the library's responsibility, but the library is limited by the lack of this feature.

Until it's officially supported, I've found an ugly workaround to accomplish what I want.

The Status Quo

I often use a pattern of "initializing" a library to be able to return a set of partially-applied functions based on the initialization parameters. Historically, I've just exported a bunch of generic types from the library and then define their corresponding concretions in the consuming application.

Depending on the complexity of those generic types, the type arguments you have to deal with can get messy.

/**
 * This represents a type we'll want to reference in the library's consuming application.
 * There might be a lot of types like this.
 */
export interface Family<Name extends string = string> {
  name: Name;
}

/**
 * Library initializer with contrived minimal example code to show intent.
 */
export const initialize = <Name extends string>(config: {}) => {
  /**
   * Some useful library functions.
   */
  const greet = (name: Name) => { console.log(`Hi ${name}, the config is: ${config}`) };

  /**
   * "Export" the library like a module.
   */
  return {
    greet,
  } as const;
};

/**
 * Somewhere in the consuming application...
 */
import { initialize, Family as FamilyGeneric } from 'library';

type Name = 'Alice' | 'Bob';

const Library = initialize<Name>({});

/**
 * Make concrete types corresponding to each relevant generic type.
 * Imagine there are many of these of varying complexity and dependence on each other.
 * The type arguments can get wild pretty quickly.
 */
type Family = FamilyGeneric<Name>;

The Hack-around

With this pattern, I've found a workaround to be able to refer to the types which were effectively made concrete within the initialization function, but which I can't access directly outside of the function.

[!WARNING] I believe that the code as written below will only work if you can consume the library as TypeScript directly (which I am doing in a monorepo), since it requires that you set both declaration and declarationMap to false. Without that, you get the error ts(4025): "Exported variable has or is using private name."

However, if you need declaration and declarationMap enabled, I believe you can still use this approach if you just keep the generic types defined outside of the initializer function and reference those generic types within the function to make the same concrete types as shown below. This results in more type parameter boilerplate, but the compiler shouldn't be upset about the internal type, and the extra code mess is still contained within the library instead of all the consuming applications.

export const initialize = <Name extends string>(config: {}) => {
  /**
   * If the compiler doesn't like this, keep this type out of this function body, 
   * and then define it again here according to the external definition.
   */
  interface Family<N extends Name = Name> {
    name: N;
  }

  const greet = (name: Name) => { console.log(`Hi ${name}, the config is: ${config}`) };

  /**
   * Group all of the types you want to "export".
   * Declare a constant to be that type.
   */
  const __TYPES__ = undefined as unknown as {
    Family: Family,
  };

  /**
   * The types constant "carries" the concreted generic types out of this function.
   */
  return {
    greet,
    __TYPES__,
  } as const;
};

import { initialize } from 'library';

const Library = initialize<'Alice' | 'Bob'>({});

type Types = typeof Library['__TYPES__'];

type Family = Types['Family'];  // = initialize<"Alice" | "Bob">.Family<"Alice" | "Bob">

With this, the consuming application no longer needs to be concerned with how to correctly build the library's generic types and maintain those concretions with future updates to the library. At worst, it may just need to define some aliases for the types it cares about.

I'm sure this has its own set of limitations around what can be done with the resulting types, but thought I'd share this in case anyone else finds it useful.