assoc typing issue

[wclr]

assoc<T,U>(prop: string, val: T, obj: U): {prop: T} & U;

{prop: T} ? Unfortunately TS is not ready not handle such case with dynamic typing yet.

microsoft/TypeScript#1295

[wclr]

Following https://gist.github.com/donnut/fd56232da58d25ceecf1

assoc(prop: string) too requires use kind of CurriedFunction interface in signature, but this:

    interface CurriedFunction2<T1, T2, R> {
        (t1: T1): (t2: T2) => R;
        (t1: T1, t2: T2): R;
    }

seem not will work for all cases where params, but:

    interface CurriedFunction2<T1, T2, R> {
        <T1, T2, R>(t1: T1, t2: T2): R;
        <T1>(t1: T1): <T2, R>(t2: T2) => R;
    }

will work as allows to extract params from type chain:

assoc<T, U, R>(prop: string): CurriedFunction2<T, U, R>

For example such case:

const map = (func: (some: string) => (x: number) => 1) => {
  return func('xx')(1)
}

const map2 = (func: (some: string, other: string) => '1') => {
  return func('xx', 'x')
}

// will work only with proposed changes
map(R.assoc('xxx'))
map2(R.assoc('xxx'))

If adding params to assoc<T, U, R>(prop: string) is no good (i'm not sure why) then there should exist curried interface without params:

    interface CurriedFunction2WithoutTypeParam {
        <T1, T2, R>(t1: T1, t2: T2): R;
        <T1>(t1: T1): <T2, R>(t2: T2) => R;
    }

@donnut what do you think about this issue?

[KiaraGrouwstra]

Thanks. It seems most of the remaining issues concern currying/composition, and this suggestion might address a key part of that. I'll try to update the definitions based on this.

[KiaraGrouwstra]

I tried adding all of the outstanding issues as tests, and manually tried your suggested typings to see how it would affect the results.
Outcome: the suggested change solves your case (other open issues appear unrelated), but breaks some old tests. It appears that adding your suggested version in addition to (-> after, not before) the original version addresses both your case and the otherwise broken tests.
I'll update the script and make a PR.

Update: I was trying to see how this might work for bits where the returned value is a curried function -- in those cases the generics could only be passed at the initial function. It seems that version also makes your tests pass, and would give me a way to generalize this concept to the other cases as well. Feedback welcome.

[wclr]

Ok, thanks, will see how it will work out.

[KiaraGrouwstra]

By now, #73 pushed me in the opposite direction, showing that redefined generics are in fact bug rather than feature. I've now re-diagnosed your actual issue, and it does in fact seem to be the same problem about generics within curried functions as reported in #78, and I suppose the composition-related ones #86, #92, and #101.
I'll revert the earlier work-around, and will try to look for a proper fix along with those other issues.