Open keyvan-m-sadeghi opened 3 years ago
This is a good start to describe some uncontroversial syntax, but doesn't go far enough to describe behavior outside of the straightforward cases, which is where 99% of the difficulty is here. It seems like this belongs more as a comment at #1213?
Agreed @RyanCavanaugh. Main goal was to demo it's probably possible to introduce HKTs and Variadic Generic Types without imposing more cognitive overhead (syntaxes like <->
or ^2
). I changed the intro to clarify that it's only strawman at this stage, but the issue can serve as a reference when discussing new syntaxes. Already commented in #1213.
Suggestion
Pertaining to the discussion in #1213 and having looked at similar suggestions (borrowing ideas where appropriate), this is a strawman proposal (syntax only) on HKTs and Variadic Generic Types that adheres to existing syntax and mindset in JS/TS , hence named "idiomatic".
🔍 Search Terms
HKT Higher Order Types Higher Kinded Types Higher Order Type Functions Higher Order Function Generic Variadic Generic Types
✅ Viability Checklist
My suggestion meets these guidelines:
⭐ Suggestion
Higher Kinded Types
Suggested syntax:
Properties
f(x)(y)(z)
Variadic Generic Types
Suggested syntax:
Properties
📃 Motivating Example
I was looking at the code in the
streaming-iterables
package, the pattern of defining an_fn
and then overloading it with anfn
including a curried version seems a case of DRY, happens in all functions the package exposes.Below code was my attempt at a general currying overload implementation for the package:
This works well until
generics
come into play:SO Question
💻 Use Cases
Using this proposal, the example described in the previous section can be covered: