Decide on the RFC for more general structural typing.

[cristianoc]

This is currently in master:
https://forum.rescript-lang.org/t/rfc-more-general-type-checking-for-structural-typings/1485/73

Ok to experiment with, but in need of more thorough testing/polishing.
E.g. the two types below printed in the error message are identical.

Other questions include how to write type annotations. And figure out whether or not this is a new type.

For v10.0 it might be best to mark it as experimental, or turn it off, or develop it further.

[cristianoc]

Actually the error is very long, and at the very end there is:

  Their internal representations differ:
  the first declaration uses @@obj representation.

So what needs to be done here is to implement the super_errors part of this error message, which is currently missing.
In super_typemod.ml there is:

      | Typemod.Error (loc, env, err) ->
        Some (Super_location.error_of_printer loc (report_error env) err)
      | Typemod.Error_forward err ->
        Some err

One case needs to be added for Not_included.

[cristianoc]

There's a wider question of what to do with super_errors, which are the Rescript error messages.
Currently they are patches on top of the OCaml error printing functions.
One possibility for cleanup is to just leave one kind of printing. That would prevent lots of bugs experienced in the past. And lots of places where ocaml-style errors still fall through the cracks.

[cristianoc]

Another question about @obj is why have that not the default for all records, and remove the @obj syntax altogether.
Would this break anything? It seems that in terms of typing, it only types more programs, not less. In terms of runtime representation, there's the question on whether something is making the assumption that unused fields exist and have value undefined vs not being there at all.

[cristianoc]

Another issue that came up is the one of empty objects (rescript-lang/syntax#517 (comment)).
What if you have a type where all fields are optional, and you don't want to pass any of them?

[cristianoc]

Related: rescript-lang/syntax#299
That was done for a different purpose. What's in common here, is that there were parsing issues. At the very least complications.
Also, if {} can be done and only one use can be chose, what should that be.

[cristianoc]

ooops, looks like the current @obj records are not quite enough: rescript-lang/syntax#517 (comment)

[cristianoc]

New design that takes care of expressivity including a number of concerns: #5423.

Concerns include:

• Is the new runtime representation dangerous? No problem, you need to opt-in by adding @optional annotations. Existing code is unchanged.
• What if I forget to pass some fields? No problem, only fields you opt-in can be skipped.
• Are there 3 kinds of object/records now? Not anymore. There are objects, and extended records. The records are extended with @optional attributes. Single concept, but more expressivity.