Vincent Laviron

I believe that for closures, we must forbid the GC from looking at a block that has been initialized but where the start-of-env field has not been set. Xavier's proposal...

The bug was also reported in #11948 (see the last few comments).

I've had an occasion to discuss with @shindere on this subject, and for clarification I'll restate my position here: I'm 100% in favour of reducing the dependencies of Dynlink, but...

@gasche I believe Github's optimistic parsing of the description of #13138 led it to close this issue, but as far as I can tell it's not yet completely fixed (#13152...

Currently we can only handle deprecated alerts on things that end up in typing environments. A lot of things end up there (most module components, variant constructors, record labels, ...),...

> Hm. Interesting. I think you're suggesting that we needn't copy an unboxed value in a closure capture if the closure is local (as a great many are). I think...

I'd suggest to look into `CamlinternalOO` if you want to see some existing uses of uniform arrays in the standard library. Given that this code is crucial to the correctness...

Coming back to the proposal: I believe that you can get a correct implementation by using `Obj.new_block` for `Uniform_array.make`, and regular array functions for all the rest. If you want...

> I would propose to add just 5 extra lines of code: I don't think you need them. On all platforms for which we support the native compiler, `Parraylength` is...

In my opinion this is very low priority. It's only a marginal improvement for a very marginal use-case that we hope will disappear in the not-too-distant future. I'll still mention...