Fix Type Inference in Curried Functions
The starting point of
curryFunction had all of the type arguments attached to the first function.
This means that they can't be inferred because they are always attached to the first function call.
In order to fix this, we have to spread out each type argument across different function calls:
0:00 Okay, the solution here is really interesting. We've got a curry function and Essentially what's going on here is if you hover over curry function itself you end up by seeing number unknown unknown in the type argument slots.
0:15 That's because all of the type arguments are actually attached to the first function here and what that means is that you basically can't be inferred from anything nor can V be inferred from anything because type arguments are always attached to a function call.
0:34 So what this means is that the fix is actually to move these on to in fact let me show you one more thing before I do that I can actually like make this work by passing in number number number.
0:47 Into here and so what you end up with is T UV number number number and so if I try and like put anything that isn't a number in here then it's going to yell at me because I'm filling up each of these slots on the first function, but this is the issue.
1:01 The way to fix this is actually move them so that they're on each function call here so instead of basically having number number number I then have number number and number here.
1:16 So the way that this then works is I'm basically passing in type arguments for each of these curried functions and of course I can actually remove these so what we get now is we get curry function
1:29 Which is inferring T that's the number that's being passed in which then returns a generic function which then grabs the you there. Which is being sort of like done there. I can't hover over anything there. Actually if I try to say first funk or yeah, this is actually the second funk because it's calling that one there then third funk is
1:51 Second funk calling it with a two and then const fourth funk is I really didn't think this through. Let's see three in fact, this isn't the fourth funk. This is actually the result. There you go. That does make sense so what's going on then second funk?
2:08 This is then a you which is then being like captured in there and then V is being captured inside V is being captured inside here. If I change this to a string for instance, then this result is going to be Tu number and V as a string so this is a critical idea when it comes to like generic inference is that each function can actually capture its own generic arguments
2:36 Sometimes you can be getting really bad inference because your generics are in the wrong slots so if this one is up here if you imagine that like this was just like a string then when this function is called you has nothing to hang its hat on and even when this is you then
2:53 This still doesn't have anything to infer from you can pass a type argument there as we saw but the proper way to do it is to have T on T U on U and V on V like this and this bit of knowledge is really key to understanding the way to structure, especially kind of chained arguments and really really complicated types. It's super cool