| 01:46 | <TabAtkins> | ljharb, others: Oh dang, Python just accepted a structural pattern-match syntax (PEPs 634/635/636). It's *virtually identical* to my proposal. I wrote up a comparison at <https://gist.github.com/tabatkins/2fb7278d9605daf3c53f425a36f3de4e>; (this is also linked from my proposal doc). |
| 01:51 | <ljharb> | i saw, but hadn't done a comparison yet, thanks |
| 02:07 | <Bakkot> | TabAtkins where is your proposal? |
| 02:07 | <Bakkot> | gist doesn't liink t |
| 02:07 | <Bakkot> | *link it, ugh, gotta get my keyboard fixed |
| 02:35 | <TabAtkins> | Oh yeah I didn't link back, huh |
| 02:36 | <TabAtkins> | Bakkot: https://gist.github.com/tabatkins/5c336285c7f6d7d6522561e97f4d98fb |
| 03:06 | <Bakkot> | TabAtkins neat! |
| 20:00 | <shu> | does anyone remember the history around the motivatioon for RegExp.prototype[@@split] special-casing empty strings? |
| 20:02 | <ljharb> | are there observable differences with vs without that special case? |
| 20:02 | <ljharb> | allen has said that he put a lot of effort into ensuring that the observable behavior of existing string regex methods didn't change in es6 |
| 20:03 | <shu> | ljharb: there is, in that for strings with length 0, the splitter regexp is executed _at_ the length (since lastIndex is 0). for strings with length > 0, the splitter is always executed at a lastIndex < length |
| 20:05 | <ljharb> | my guess then is that "that's how it used to work", so the special case was to preserve that semantic |
| 20:06 | <ljharb> | either that, or "we didn't think about consistency" explain most of the weird things in the regex methods |
| 20:07 | <shu> | there is a paragraph in the note that calls out the empty String behavior, but nothing in way of motivation |