Gabriel Scherer

I haven't looked at the implementation. I wonder if @garrigue has an opinion?

I realize that this PR got stuck on the pipeline. Maybe we could merge it now? I think that we need to things: 1. @Octachron made some additional change suggestions....

See https://github.com/ocaml/ocaml/discussions/12015#discussioncomment-10104233 for a new discussion item on qualified binding operators (some of `Option.let/map`, `let/Option.map`, `Option.let+`, etc.). I believe that the proposed feature has value even in absence of qualification:...

In any case there are conflicts with the `Option.let/map` syntax, as discussed in the discussion in https://github.com/ocaml/ocaml/discussions/12015#discussioncomment-10111945 . (I would rather focus in this PR on the discussion of the...

We discussed this PR at the maintainer meeting today. People are generally in favor, but they would like to see support for the qualified syntax, `let/Option.map` (which desugars into `Option.(...

By "`mcomp` ignores univars", you mean that two univars are always considered potentially-compatible with the new approximation. (Note: there may be room to refine this, because when both univars *are*...

Note: I think the worry of @stedolan was not that some parts of the compiler would check types in different univar contexts, but rather that we could check two types...

I think that having a `Unpaired_univars` exception out of `unify_univar` would be a reasonable compromise: calls that expect to be in the same univar scope would handle it as a...

Thanks for the report! I agree that this is an issue worth fixing, but I haven't looked at your fix long enough to understand it yet.

I understand your fix. I would propose to write it as follows: ```ocaml let i_max = ref max_int and max = ref (-1) in Hashtbl.iter (fun i c -> (*...