I love this new syntax. Super awesome!! 👍

There's still the limitation that it's not possible to take an existing record and set an optional field to None.

This @optional is huge improvement in UX and expressivity even though there's the limitation!

This is ready to try now: #5423

Notice there's direct support for <C x=?y />.

Got it. I'll work on it!

Love the proposal, but I think it's simpler in surface area (and I think easier in usage) if for the optional values always an optional value is expected. So setting y would be

let v = { x: 3, y: Some(4) }

And if y is already optional value

let v = { x: 3, y: y }

Now people only need to learn the optional on the type definition site. And refactors are also easier, because if an optional value is part of a record but not yet @optional, then refactoring it would just be marking optional at the definition site. In the proposed version, we also need to change it everywhere it's being used to add the @optional annotation.

Love the proposal, but I think it's simpler in surface area (and I think easier in usage) if for the optional values always an optional value is expected. So setting y would be

let v = { x: 3, y: Some(4) }

And if y is already optional value

let v = { x: 3, y: y }

Now people only need to learn the optional on the type definition site. And refactors are also easier, because if an optional value is part of a record but not yet @optional, then refactoring it would just be marking optional at the definition site. In the proposed version, we also need to change it everywhere it's being used to add the @optional annotation.

Unfortunately that's not expressive enough to write JSX.
rescript-lang/syntax#517 (comment)

if an optional value is part of a record but not yet @optional, then refactoring it would just be marking optional at the definition site. In the proposed version, we also need to change it everywhere it's being used to add the @optional annotation.

Hmm, I guess you could still have a field being

{
  x: string,
  @optional y: option<int>
}

This way, if you really don't want to touch the existing code base, you could just do this and omit it in the places where you don't want it at all.

In general, if a field becomes optional, then there's no way to get field update and access work without changes, whatever the proposal.
One can optimize for one and not for the other.
And optimizing means losing the refactoring benefits of compiler errors.
So I think these are the trade offs and parameters one can play with.

The current proposal lets you keep all the updates unchanged, and requires changing lookups (as x.foo is now optional).

Ah I understand that this is also determining if a key appears in the object. Got it! In that case I think the current implementation makes sense, but having a syntax sugar would definitely be nice!

The task of adding surface syntax is up for anyone interested in having a go.
It should be pretty straightforward unless some issues such as conflicts come up.

Cool. What happens when ALL fields are optional? I don't know if it's possible type system wise, but it would be really nice if you can pass unit in this case, especially when we have a record with optional configuration.

Created an issue rescript-lang/syntax#544

Cool. What happens when ALL fields are optional? I don't know if it's possible type system wise, but it would be really nice if you can pass unit in this case, especially when we have a record with optional configuration.

It is possible for them to be all nullable. But there's currently no syntax to populate that value.

There's only a dirty trick one can use:

type t = { @nullable x: int }

let empty = { x: @nullable None }

which anyway is not literally the empty object.

To have an empty object, one needs some syntax, and a check that the compiler internally does not scream with some assertion failure or something.