Allow currying of generics

First thing: I know there are a lot of question and good answers about how to write, curried functions. What I am requesting here is to be able to curry generics.

This seems related to #10571, but I thing its a slightly different proposal.

For this example we use this interface and this simple Instance

interface Interface {numberKey: number, stringKey: string}
const instance: Interface = {numberKey: 1, stringKey: "a"}

What is expected

It would be greate to be abled to write a function like this

// 1. Take a key name and a value
// 2. Return a function, that takes an object, 
//    that has a key that matches the given value
const getTransformerA = <I><K extends keyof I>(key: K, value: I[K]) =>
        (input: I) => input

// We now we should be able to use it like this
const transformerA1 = getTransformerA<Interface>( 'numberKey', 123 )

// And we expect an error here
const transformerA1 = getTransformerA<Interface>( 'stringKey', 123 )

The advantage of this, is that we get a return function, that is guaranteed to work with a certain interface, before we call the return function. Which is especially useful in cases, where we could loose typing, but still want to ensure compatibility with an interface.

But this syntax doesn’t work and I seem unable to find a workaround.

[essenmitsosse]

const transformerA1 = getTransformer<Interface>( 'numberKey', 123 ); // or this, if the syntax filled in _

This would indeed almost be the same. The main difference to what I was looking for was the function making it a bit more clear which parameters should be set (the interface) for the function to properly work, while the other two parameters should never have to be set, because there should be almost not case where it would be necessary to set them.

Like I said, the main advantage of the whole construct is, to have kind of type-saftey in cases, where the typying will be lost - meaning we want to ensure the function is compatible with an interface, before we call it (otherwise we could just go for Version B).

Leaving the underscores there would definitely work and not kill anyone, but neither would repeating the string (Version A).

But non of these version seem really descriptive to me, about how the function is supposed to be used. The definition of K ist just in the type parameters because thats where we define generics. Not because we want it to be a parameter.

So maybe thats also the real issue here - Type parameters seem to serve two usecases (1. allowing configuration, 2. allowing interference), making it hard to see as a user of a function how it is meant to be used.

[c-vetter]

Before finding this, I have tried to tack this very idea onto #26242 because I think both try to solve overlapping issues and making them them work hand in hand would be worthwhile.

@essenmitsosse and others interested in this feature may want to chime in soon since #26242 has recently been added to the project team’s agenda.