Relax the generation of `t_n`
tmattio opened this issue · comments
ts2ocaml
generates types for all of the arrity possible of a given type.
However, in practice, the types are stricly equal and have the same arrity as the type t
.
Additionnally, bindings generated seem to always use the type with highest arrity.
So I would propose that:
- We don't generate types if they have the same arrity as
t
- (optionnally), we only generate
t
as it seems compatible with how other generated bindings will use the module.
Additionnally, bindings generated seem to always use the type with highest arrity.
This is not true in general. I've seen so many .d.ts files in the wild which actually use the default type parameters.
I'm against removing t_n
types. It ensures other bindings can choose the correct arity without actually parsing the original definition.
I'm against removing t_n types. It ensures other bindings can choose the correct arity without actually parsing the original definition.
Could this be provided as an optional argument? I'm consistently removing them as I find no use for them and they make the API more convoluted for end users.
I will consider that. I wish there were a way to prevent types and other things from appearing in editor autocompletions without making it inaccessible, though (pushing t_n
types to Internal
is an option but then the Missing
module type would start looking ugly).
@tmattio Also, I have to say that removing t_n
types from your bindings is really, really bad idea considering the future of this tool. ts2ocaml has to emit t_n
types for the Missing
module types (since it has no easy way to know the arity of external types), so the bindings with t_n
removed can't be easily passed to the Make
functor and would require massive manual definitions of t_n
types on the users' end.
Or we can just discard the whole idea of Missing
module and let the users fix the output by manually adding open
s (which is the thing ts2fable do).
Yeah, I'm just starting to think this is actually a good idea. Let's get rid of functors and the Missing
module type.
Or we can just discard the whole idea of Missing module and let the users fix the output by manually adding opens
That's what I have been doing, so getting rid of Missing
works for me 🙂
Now we have an option --safe-arity
to customize this behavior since 1f0ed1e .
--safe-arity=full
(default) generatest_n
types in the module, and tries to uset_n
type if the type is unknown (e.g. from another package)--safe-arity=provide
only generatest_n
types in the module--safe-arity=consume
only tries to uset_n
type if the type is unknown--safe-arity=off
disables any usage oft_n
types
(note that --safe-arity=consume
and --safe-arity=off
will still generate t_n
types if there are type parameters with default types. these options only turn off unnecessary t_n
types)
I think I might have forgotten to implement
We don't generate types if they have the same arrity as t
when --safe-arity=consume
and --safe-arity=off
. I will review it later...