Unable to infer types in function passed to `map` about fluture HOT 13 CLOSED

Following some links, I found this comment:

Overloads, whenever possible, should always have a final overload that covers all of the cases in a more general way
-- microsoft/TypeScript#40413 (comment)

This makes it sound like perhaps the problematic overload can be rephrased for TypeScript to "fall back" to the "map on Future" case when it can't resolve the overload. I will investigate this option.

from fluture.

it brought this repo to mind as it's the HKT implementation that has made the most sense to me to date, but I'm not convinced it's any simpler than his solution. I learned a ton today! Many thanks to you both 🙏

That traverses down the type and replaces _<0>, _<1>, etc., which thus doesn't support conditional types, which is normally half of my use case 😄 . Creating the HKTs with it is a bit simpler, however, so if you're just using HKTs for a Functor-esque purpose like this, it's probably better.

from fluture.

I should note that chain can infer types just fine (i.e. same behavior as fluture 11.x), so this is specific to map

from fluture.

Hi @EricCrosson. Thanks for the report. I think it's because the second argument to map is overloaded with support for the ConcurrentFuture type besides the Future type:

TypeScript cannot infer types from overloaded functions (microsoft/TypeScript#32418 (comment)).

In Fluture v11, this overload was incorrectly specified at the first function argument:

This means that TypeScript always resolves to the first overload that matches the input function (as opposed to the type of Functor), which is the version of map used on Future (see #400). So in v11, it worked for Future instances, but not for ConcurrentFuture instances. This was fixed over several iterations: first #401 and then #403.

I believe this is a case where fixing one issue introduces the other, and vice-versa. I've also had trouble with TypeScript's inference from overloaded functions when I was trying to do #438, leading me to have abandoned it for now. I would love for this problem to be solved somehow, but no luck so far. We can leave this issue open for visibility.

from fluture.

Oh, and the reason my preference is to leave it at the current solution, and not go back to the v11 way (essentially dropping support for map on ConcurrentFuture), is because the problem caused by the current approach is easier to solve in userland, via a type annotation. In other words, it seems like the lesser of two evils.

from fluture.

@EricCrosson As a work-around, you could create a Future-specialized map function, eg:

import * as F from 'fluture'

export function map<RA, RB>(mapper: (value: RA) => RB):
  <L>(source: F.FutureInstance<L, RA>) => F.FutureInstance<L, RB> {
  return F.map (mapper)
}

///////////////////////////////////////////////

F.resolve(5)
    .pipe(map(value => value.toString()))

from fluture.

@Avaq, thank you for the quick response and suggested workaround!

I appreciate the historical context you have provided. There's a lot to read and think about, so I may take some time to digest all of this.

from fluture.

Another option I have been thinking about is to create more separation between the Future and ConcurrentFuture types, so that both can support their entire feature-set "out of the box", but I like the sound of the final overload much more

from fluture.

@EricCrosson I've started working on this, although have been unsuccessful in finding a solution. See #457.

from fluture.

I also asked for help with this issue on TypeScript's Discord: https://discord.com/channels/508357248330760243/740274647899308052/796759112607203399

from fluture.

Awesome, I didn't know there was a TypeScript discord! I'll check out your post there and the PR to see if I can help

from fluture.

Someone on the Discord channel found a solution. I committed it to #457. Perhaps you could install npm i fluture-js/fluture#avaq/map-ts and test if this has solved your issue? Note that this may not work with ts-node due to its reliance on CJS, but you can test with tsc.

from fluture.

Sure! I'm reading through the discord conversation now -- coolest back-and-forth I've seen in a while 😎

Where @tjjfvi mentioned

I've never fully grokked the other [HKT] encodings I've seen

it brought this repo to mind as it's the HKT implementation that has made the most sense to me to date, but I'm not convinced it's any simpler than his solution. I learned a ton today! Many thanks to you both 🙏

Testing fluture-js/fluture#avaq/map-ts locally

Yes sir! The example in my initial post compiles without a hitch, and my editor correctly infers that value is of type number. This ticket can be closed. Dynamite! 🧨

Consider me officially excited to upgrade my projects from fluture 11 to fluture 🚀

from fluture.