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
tas 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 opens (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_ntypes in the module, and tries to uset_ntype if the type is unknown (e.g. from another package)--safe-arity=provideonly generatest_ntypes in the module--safe-arity=consumeonly tries to uset_ntype if the type is unknown--safe-arity=offdisables any usage oft_ntypes
(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...