Gabriel Scherer

I agree -- sorry I missed this earlier. Let's close optimistically. (We can always reopen if @jhjourdan explains that there is a bug.)

The suggestion here, I believe, is to have a clearer error message if users include toplevel directives within .ml files fed to the compiler. Currently they see: ``` $ ocamlc...

Where does the intuition for the `_mem` suffix comes from? I thought of `Atomic.fetch_and_add` (which is a way to describe post-incrementation), and wondered whether this could be `find_and_remove` and `find_and_replace`.

(I'm also happy with the benchmarks, thanks!)

@bclement-ocp has an alternate proposal, where we use an extension point to denote a (value, offset) pair, instead of just the offset. This would look like this -- adapting the...

I thought more about the suggestion of @bclement-ocp, and I see four different designs that are worth discussing. Running example: ```ocaml type t = { id : int; mutable state...

Thanks, this is useful feedback. I agree that (2) is simpler. It's also probably not too hard to implement (4) on top of (2) later if we decide to do...

There is now an implementation of this RFC -- the `[%atomic.loc foo.bar]` design evolved from the discussion, not the original description -- as a PR by @clef-men and myself: https://github.com/ocaml/ocaml/pull/13404...

Thanks @polytypic. Your reply got me thinking about how we can move from one design to the other. (The value-and-offset design and the offset-only design.) From the offset-only design, it...

Today I thought more about how we would go for design one (`('r, 'v) Atomic.Field.t`) and how it relates to design two (`'v Atomic.Loc.t`). As Leo pointed out, if you...