Gabriel Scherer

@Octachron I believe that we forgot to merge this and should just click "merge" now that #13712 has been merged, right?

I pushed two additional commits, one to remove a pre-existing paragraph that mentioned the previous "non-aliasable" criterion, and another to clarify that variants and records are also affected by the...

I took @Octachron's comments into account and rebased the PR against trunk.

I propose a design for atomic record fields in a RFC: https://github.com/ocaml/RFCs/pull/39

Bad news for Murmur3: [Breaking CityHash64, MurmurHash2/3, wyhash, and more...](https://orlp.net/blog/breaking-hash-functions/) (in particular: [Universal collision attack on MurmurHash3](https://orlp.net/blog/breaking-hash-functions/#universal-collision-attack-on-murmurhash3), which is what OCaml currently uses.)

My impression is that it is a usability problem that there is no way to get the current `Random.State.t` without making a copy of it. Having that feature available would...

In case someone is interested in implementing this, could you say just a bit more about how this would have to be done? Here is what I *think* I understand:...

So if I understand correctly, Jane Street has merged [a PR](https://github.com/ocaml-flambda/flambda-backend/pull/1337) (late August 2023) that changes the implementation of module strengthening in a way that improves performance in some module-heavy...

My understanding is that the fact that the effect is unhandled is *not* the bug that is worrying here -- this more of an implementation or design choice, due to...

Ah, but this suggests that the bytecode issue in the toplevel needs a separate fix. If you were willing to send your amazing investigative powers in this direction as well,...