Open gvergnaud opened 11 months ago
I notice that your interface and functionality is becoming more and more similar to free-types although the underlying implementation is very different. I am considering abandoning this project considering how well you are doing. I talk about a few challenges of implementing type constraints in length in my guide if you want to skim through it.
I wonder if we hit the same design limitations. How does this behave regarding variance in higher order scenarios for example? I also found conditional types to make TS detect excessively deep type instantiations in some scenarios where they are used to defuse type constraints, making it harder to compose types, which is why I default to intersection and provide different helpers for different situations.
folks at https://github.com/Effect-TS might be interested by an implementation enabling specifying variance. At current they use positional arguments with a specific variance for each, which is appropriate for their needs but makes the type lambdas awkward to use and read for the few power users that would want to define theirs. If the community could settle on one interface that is type safe and general that would be awesome.
Here is a POC for a slightly different take on hkts. Here are the main ideas
$
. This avoids the uncanny valley of having bothFn<...>
and sometimes with$<Fn, ...>
.$
can take many arguments and supports partial application:$<Add, 1>
,$<Add, 1, 2>
,$<$<Add, _, 2>, 2>
and$<$<$<Add, _, 2>, _>, 3>
all work.$<Fn>
on any function if you want the result, even if it's already fully applied.Fn<[arg0, arg1, ...]>
$
is type safe. You can't provide a type that isn't assignable to the constraint.Here is what using it feels like: