this is a general reflection on rescript that hit me because we implemented a custom Dict type. there’s a number of types in the rescript stdlib, e.g. Result, Option, JSON etc. these are implementations that are not merely a transparent or zero-cost abstraction of js implementations/types.
this might be a controversial take, but it is actually rather confusing to have Dict and Option directly in the stdlib, because Dict, if you look at Stdlib_Dict is basically just a bunch of externs for js, whereas Option, looking at Stdlib_Option, is a full-on implementation of a type.
thus, we decided to prefer to use Js.Date.t for js abstractions, which makes more sense. my suggestion is that these js abstractions should be put together under Js., because they’re not at all the same thing as e.g. Option. i guess it could be the other way around: Date.t and Std.Option.t
what i’m trying to get at is that there’s a lack of clarity with regard to where one is drawing types into scope from, and this started mattering in our growing rescript codebase (total is about 80k lines, just under 20k lines is rescript so far).
if you (as i might expect) feel this is not feasible, i would wish for a feature flag that removed the relevant classes and forced you to refer to them by using the Js. prefix. this is also important because many of these types have very js-specific behaviors
thoughts?