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
To give you more context, when rescript was originally created, it used the OCaml standard library as its standard lib, but it was not really convenient on a JS backend, so a Js library was created which aimed at providing 0-cost bindings to JS APIs. Over time, idioms in rescript changed and a new standard library was created, Belt, which focused on rescript types more than on JS APIs. The situation was not ideal since people want to use standard libs without having to think if the underlying type comes from an OCaml or a JS background, so it was decided to create a standard library that would cover everything, Core was born and was later renamed Std once it got shipped with rescript itself as it main standard lib.
Now that the situation is clear in v12 - Std is the standard lib for everything in rescript, is here to stay and is shipped with the compiler - Js lib is getting deprecated. So try to avoid its use.
Note: We’ll be deprecating all of the Js namespace, but we’re currently working to add an automatic migration for all of this. So once it’s deprecated, there’ll hopefully be a command you can run to have all of this migrated automatically.
right, the point i’m trying to make is that it’s not clear whether a type in rescript can be trusted to be compatible with js or not. how can i know that Date is, but Option isn’t (really)? what about Dict, is it a custom implementation of a dictionary or a plain js object? how can i know? in the long run, how can i know that Dict will remain a plain js object? this is important for ffi which expects js objects as dictionaries? maybe Dict should have Dict.toJsObject or similar? likewise, how do i know that Date is actually a js date and not some custom date implementation?
the question at its core is probably something like: how do i know which parts of the stdlib are pulled in from js (zero-cost ‘abstractions’) vs custom implementations?