[ANN] Enhanced Ergonomics for Record Types

Hi everyone!

We just published another blog post in our series covering the new features and capabilities coming in ReScript v11. This time it’s about how we’ve added type spreads and coercion to records, to make them more ergonomic to work with and let them get some of the conveniences of structural objects.

Check out the blog post and let us know what you think!

17 Likes

Really cool and very useful language feature! We have a lot of boilerplate code that could be avoided with this!

Will coercion change the shape of the object at runtime? Or are we just changing the type?

This sentence was not clear to me: “Please note: As for right now it is not possible to override fields in the target record type.”

1 Like

This sentence was not clear to me: “Please note: As for right now it is not possible to override fields in the target record type.”

I believe that means you can’t do this:

type x = {
  a: int,
  b: int,
}

type y = {
  ...x,
  b: float,
}
1 Like

Coercion does not change the runtime shape, it’s just at the type level.

@XiNiHa is correct for the second question - there can’t be multiple fields with the same name present when spreading.

Ah ok! Seems like a reasonable constraint. Perhaps the example would clarify this in the blog post!

I am not sure the impact, but wouldn’t that have consequences on the guarantees of runtime representation of records? (eg. you are not sure there are no extraneous fields when receiving a record).

Especially with interop with JS, in this new model there is no guarantee that there are some extra keys in the object that get’s passed to JS, and no way to enforce this at the type level anymore.

No that’s not what it means.
But it’s legit to expect that’s the meaning given how it’s phrased.
You can’t even add back the same field with the same type.

1 Like