| 18:35 | <peetk> | went over notes for the proposal review and tried to put all the action items in the conclusion. repeating those here in case anyone forgot what they committed to: -PKA will check with ACE on the status of JSON.parseImmutable. -RBN will take a new look at RegExp Buffer Boundaries in light of CDA’s belief that it may be a very important security feature. -SHS will reach out to KOT about the withdrawability of dynamic import host adjustment. -KM will check with SYG about Atomics.pause, and possibly bring it for Stage 4 next meeting. |
| 18:43 | <Chris de Almeida> | I also said we'd look at 'Atomic Operators' to see if there should be a clear prioritization from a sec perspective (vs 'buffer boundaries') |
| 18:48 | <Michael Ficarra> | regarding the RegExp proposals, I really want to get Clément Pit-Claudel and/or Aurèle Barrière from EPFL to present their work on a linear implementation of JS RegExps which is uniquely possible among the major programming languages' embedded RegExp feature sets |
| 18:49 | <Michael Ficarra> | being able to have a linear implementation is an incredibly valuable property that I would not want to lose by accident, even though implementations in major engines today do not take advantage of it |
| 18:50 | <Michael Ficarra> | that said, I am quite confident that buffer boundaries would not cause an issue, but I want to be very careful with future and in-progress RegExp proposals |
| 19:10 | <Chris de Almeida> | any concerns w/ the 'Atomic Operators' proposal in this regard? |
| 19:11 | <Michael Ficarra> | you're going to have to ask the experts about that one |
| 19:17 | <iain> | V8 has an experimental implementation of a non-backtracking allocator here. My vague impression (but somebody from V8 would know better) is that it mostly works, but it's enough slower than the backtracking implementation in non-pathological cases that it only really makes sense to use a backstop instead of the primary implementation, at which point that's a lot of extra complexity to expose just to cushion the blow for people who write bad regexps. |
| 19:45 | <rbuckton> | Is it that much slower than positive lookahead? Positive lookahead is already atomic. |
| 19:46 | <rbuckton> | Ah, nm. Thought you were referencing atomic operators, not linear regexp in general |
| 20:43 | <Michael Ficarra> | btw for anyone looking for more info about their work, here's their materials from when they presented to TG5: https://github.com/tc39/tg5/blob/main/agendas/2025/2025-08-27.md |