| 09:44 | <Rob Palmer> | Hello all, it is four days until the proposal advancement deadline for the April plenary meeting. The current agenda is very light and could be completed in half a day. Meaning we have three and a half days of capacity. |
| 10:40 | <rkirsling> | I have something for the agenda but I need to know how to make the PR first, so I'd love editor feedback or whatever on https://github.com/tc39/ecma262/issues/3295#issuecomment-2011714685 |
| 15:37 | <nicolo-ribaudo> | When there is a browser-specific bug that depends on how the engine implemented a given feature, does it make sense to open a test262 PR or is it's better to just have it as a test in the browser's code base? (concretely, https://bugzilla.mozilla.org/show_bug.cgi?id=1887677) |
| 15:38 | <bakkot> | personally I am in favor of more test262 tests |
| 15:40 | <bakkot> | as long as it's not so specific to one engine's internals that it is unimaginable anyone else would hit it, which this does not appear to be |
| 15:43 | <nicolo-ribaudo> | Oh lol, Babel versions up to a couple months ago would also compile that code wrong |
| 15:43 | <nicolo-ribaudo> | (for different reasons though) |
| 15:44 | <nicolo-ribaudo> | I'll submit a test |
| 17:43 | <bakkot> | thoughts on, could we add a "index to start searching at" argument to String.p.match and RegExp.p.test and friends without breaking the web? (so that you don't have to do the awful "mutate the lastIndex property of a /g or /y regexp object" thing) |
| 17:47 | <ljharb> | that would be awesome, but i'm not sure if we could get away with it. probably fine on matchAll and replaceAll, but the older ones are the ones i'm concerned with |
| 17:49 | <bakkot> | usual concern with adding extra parameters is use with .map but since these are methods they can't easily be passed to .map, and I can't think why else someone would be passing stuff here |
| 17:50 | <bakkot> | I guess if we wanted to be really safe we could have it be an options bag and ignore the argument if is not an object with a fromIndex property |
| 18:35 | <TabAtkins> | It would be really worthwhile to figure out how to do that, I use those args in Python moderately often and would def feel their lack in JS if I was doing more serious coding in it. |
| 18:36 | <Justin Ridgewell> | Would it work for non-global/sticky regexs? |
| 18:50 | <bakkot> | That would be the goal yes |
| 18:50 | <bakkot> | and for global/sticky I would want it to take precedence over the lastIndex property |
| 18:52 | <bakkot> | especially for global - e.g. for "xxxxx".match(/x/g, index) I would want it to return an array of only those matches subsequent to index |
| 18:53 | <bakkot> | the specification is easy because the machinery already handles starting from a given index, we just need to expose it in a better way |
| 18:54 | <bakkot> | maybe for global/sticky we could say that it throws if the lastIndex property is non-zero, similarly to how matchAll throws if given a non-g regexps |
| 18:55 | <bakkot> | though that's probably overkill |
| 19:50 | <Justin Ridgewell> | I think that’s overkill, just preference the param over the prop. |
| 19:50 | <Justin Ridgewell> | But definitey +1, that’d be great to have |
| 19:51 | <Justin Ridgewell> | Fixes an obvious bug I’ve hit when forgetting to reset the lastIndex before starting a global search |
| 20:25 | <littledan> | as long as it's not so specific to one engine's internals that it is unimaginable anyone else would hit it, which this does not appear to be |
| 20:38 | <shu> | littledan: we are encouraging that for v8 development with 2-way sync now in place (though more primitive than WPT's). it's still a judgment call on whether something is v8-specific or not, though |
| 20:43 | <shu> | the rule of thumb is probably "if it doesn't use internal testing functions, and doesn't require a specific set of shell flags to repro" |
| 20:45 | <shu> | but there is concern from infra folks about how long it takes the suite to run. i don't think there's anything we can do about that afaict |
| 20:45 | <shu> | (tbc they already think it takes too long to run and keep having to add shards to some configurations, like debug builds) |
| 20:46 | <bakkot> |
make your engine faster, obviously |
| 20:47 | <shu> | cmon i'm just a small little feature developer |
| 20:48 | <littledan> | but there is concern from infra folks about how long it takes the suite to run. i don't think there's anything we can do about that afaict |
| 20:50 | <shu> | I wonder if some of the templated tests might be slightly excessive, in terms of number of tests and amount of real coverage that they give. But it's always tricky to consider removing tests/putting them into a lower tier. |
| 20:50 | <shu> | like, unless infra literally tells me "we are out of compute money" i am just going to nod and say "ah sorry yes it is a large suite" |
| 21:41 | <ptomato> | I think we should encourage test262 tests even when it's regression tests for bugs, since these sometimes do hit multiple implementations in a similar way. (I've had arguments with maintainers in the past about whether these are allowed to go upstream. The new cheat code is to put them in staging if someone feels like arguing with you.) |
| 21:41 | <littledan> | ah sorry for my bad wording there; it was more about the historical situation |
| 21:42 | <littledan> | (what's in scope has changed over time for the better, I think) |
| 21:44 | <ptomato> | no doubt there are still places to improve, if so I'd rather hear about them 😄 |