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

assoc typing issue #90

Closed
wclr opened this issue Sep 1, 2016 · 5 comments
Closed

assoc typing issue #90

wclr opened this issue Sep 1, 2016 · 5 comments

Comments

@wclr
Copy link
Contributor

wclr commented Sep 1, 2016

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 wclr changed the title assoc assoc typing issue Sep 1, 2016
@wclr
Copy link
Contributor Author

wclr commented Nov 5, 2016

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
Copy link
Member

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
Copy link
Member

KiaraGrouwstra commented Dec 9, 2016

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
Copy link
Contributor Author

wclr commented Dec 9, 2016

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

@KiaraGrouwstra
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants