Gabriel Scherer

In https://github.com/ocaml/ocaml/pull/13707 I implement `%atomic.field` on top of the current PR (https://github.com/ocaml/ocaml/pull/13404) implementing `%atomic.loc`; the type-based disambiguation code is more involved, as expected, but more importantly the interaction with inline...

@clef-men has a PR that implements atomic arrays at https://github.com/ocaml/ocaml/pull/14380. Above we had a decision on the usefulness of exposing both bound-checked and non-bound-checked (unsafe) atomic access operations on arrays....

I got into a similar issue with, I believe, the following setup: - I have 5.3.0 in my current global switch (set by default in .bashrc) - I am working...

> Note that they need to be of the same version since the cross compilers will contain the runtime of the non-cross compiler because the C toolchain that will be...

My overall impression: this looks like serious work that goes in the right direction, and I think we should eventually merge it. I don't have a good picture of the...

As mentioned [previously](https://github.com/ocaml/ocaml/pull/126#issuecomment-1582519924), there is broad maintainer consensus in favor of the feature. I suppose that the purpose of the RFC is more to discuss the proposed syntax and the...

Thanks! This suggest that we could forget about the `-directory` part of the RFC, unless I am missing something.

My intuition is that providing a location/span is likely to have various usability benefits in practice for some use-cases. (It's not even obvious what the 'position' of a function call...

I'm convinced that we should favor usability over performance here. The performance costs that we are talking about are mostly minor (how large already are the js_of_ocaml outputs that we...

Your summary is fine! I am clarifying my own opinion: after consideration and the further discussion, I am now convinced that we should use locations and not positions.