Hyeseong Kim

Yes. I believe we already discussed somrwhete making the`@rescript/data` package

I think it depends on the goal of the Core. If it prefers thin, mostly zero-cost bindings, I'd like to split the layer rather than directly replace Belt (like Jane...

One possible fix is to add entry sorting at runtime, which will add serious performance degradation wherever optional fields are used (e.g. JSXv4) Another way is to initialize optional fields...

> Coercion for records also break this assumption (more fields can be on the object than what's represented by the record). IMO it should have runtime effects, not just be...

> Actually that was never true because of FFI. At least when using FFI explicitly, users can be quite careful about it. But in pure ReScript-produced code, this behavior is...

> Honestly I think these are just quirks we'll have to live with in some form if we want optional record fields (which we do) and coercion (which we also...

> This is definitely a good idea. I wonder however if anyone is using them. That type of comparison could be quite powerful (== for records anyway) but I wonder...

> More opinions on what to include/not include would be good. I'm still thinking about it. Maybe I need to do something similar in rescript-vitest, but without exposing it to...

One concern: Bundling error messages or source information from libraries used in the critical path is not a good idea and should be treated as a development-only feature. As we...

I like the idea of ​​using abstract types to inject metadata, but at least there needs to be an option for the compiler to change its configuration depending on the...