Curried function seems not typesafe with Typescript and ramda

Question

I have a function:

function myFunction(n: number, s: string, n2: number): boolean {
  throw ''
}

I partially call it using ramda 0.27.1:

const curriedStringNon = curry(myFunction)(123, 'string')

But then I missed some typesafety:

curriedStringNon(123) // <- this is allowed which is expected
curriedStringNon('string') // <- this errors as it should
curriedStringNon() // <- but why is this allowed?

I don't expect this to compile because myFunction cannot be called with only two args:

myFunction(123, 'string') // <- this also errors which is expected

From Ramda's point of view, that's not an error. You just get back the function. This has been a point of contention even among the core team, but I'd argue that it's the most logical behavior. — Scott Sauyet, Mar 04 '22 at 16:20
It actually shows a "Expected 1 arguments, but got 0" error - https://codesandbox.io/s/typescript-with-ramda-forked-nqud1g . Check your version of Ramda and the `@types/ramda`. — Ori Drori, Mar 04 '22 at 16:46
I wrote [an answer](https://stackoverflow.com/a/70687948) several months ago that has some bearing on this. — Scott Sauyet, Mar 04 '22 at 16:59
@ScottSauyet - yup got it. Thanks. If you make an answer I can mark it as correct. — sennett, Mar 05 '22 at 19:54
@OriDrori huh weird. Maybe something to do with ramda 0.27 vs 0.28? — sennett, Mar 05 '22 at 19:56
Might be, but it usually the types the have some differences. — Ori Drori, Mar 05 '22 at 19:59

score 2 · Accepted Answer · answered Mar 09 '22 at 21:39

As I said in the comments,

From Ramda's point of view, that's not an error. You just get back the function. This has been a point of contention even among the core team, but I'd argue that it's the most logical behavior.

and

I wrote an answer several months ago that has some bearing on this.

Curried function seems not typesafe with Typescript and ramda

1 Answers1