TC39 Delegates
2021-09-01
plaintext logs
prev next
source on github
13:37
<Ashley Claymore>
change-array-by-copy methods dropped from 10 to 4 https://github.com/tc39/proposal-change-array-by-copy/issues/27
13:47
<bakkot>
do we want to take notes for the "Response to ECMA / LF Proposed Partnership | Michael Saboff" item?
13:47
<bakkot>
I'm never sure for the administrative rather than technical items
13:50
<Rob Palmer>
yes, take notes, but we won't make them publish them publicly
13:52
<Rob Palmer>
the jitsi is open - same passcode as yesterday
14:44
<littledan>
I also strongly support the "safety value" of permissive copyright agreements/forkability
14:49
<shu>
just FYI here's the list of ecma members: https://www.ecma-international.org/about-ecma/members/
15:08
<Michael Ficarra>
ceil, floor, round, trunc, really?
15:09
<bakkot>
I'd actually say that stage 1 shouldn't be about extending Math specifically, just about adding more math operations for bigints
15:09
<ljharb>
"bigint math" indeed doesn't necessarily mean it has to be on Math
15:09
<rbuckton>
It could just be on BigInt
15:09
<ljharb>
the challenge there is, "why aren't these things on Number too?"
15:10
<ljharb>
iow, perhaps most of the Math methods belonged on Number, but here we are
15:10
<ryzokuken>
maybe we could later add aliases on Number 😀
15:10
<rbuckton>
Also possible to introduce a separate global, i.e., MathN or BigMath, but I'd hate to have to do this over and over if we add more number types in the future.
15:11
<nicolo-ribaudo>
It could be namespaced, Math.BigInt.*
15:11
<ryzokuken>
what about mixedArrayWithNumbersAndBigInts.map(Math.abs)?
15:11
<ljharb>
 * would have to be Math.bigint.* then, thanks to Temporal.Now
15:12
<ryzokuken>
wait, isn't it a namespace too?
15:12
<ljharb>
lol nvm, i'm tired and confused myself
15:12
<ryzokuken>
so same capitalization
15:14
<ljharb>
re max/min, 1n < 3 works, so Math.max(1n, 3) should work. i see zero concern with "mixing" in max/min, because there's no accidental precision loss, which was the only motivation for mixing errors that i recall
15:16
<Michael Ficarra>
I fully support "maths operations for BigInts", not so sure about the choice of functions listed here
15:17
<bakkot>
yeah, +1 for excluding transcedentals
15:18
<Jack Works>
support for some kind of NS instead of bigMax and bigMin
15:18
<bakkot>
though also, +1 for hashing out the exact list in stage 1
15:19
<shu>
i don't know if it's bizarre that arbitrary precision math doesn't "just work"...
15:19
<ljharb>
max/min isn't "arbitrary precision", it's a form of > and <
15:20
<ljharb>
if i can do 999999999999999999999999999999999999999999999999999999999999999n > 1, why can't i put those in max or min?
15:20
<danielrosenwasser>

because there's no accidental precision loss

10000000000000000000000n < 10000000000000000000000.1

> false

🤨

15:21
<shu>
ljharb: yes, my comment is about unqualified "math"
15:21
<ljharb>
in that case the loss happens on the number creation, not part of the <
15:21
<nicolo-ribaudo>
You don't know the return type of Math.min(x, y) when x is a number and y is a bigint
15:21
<danielrosenwasser>
I don't really think it's a problem in practice, but it's not like most people know the behavior off-hand
15:21
<ljharb>
nicolo-ribaudo: the return type is T, the type of your inputs - number if all numbers or non-numbers, bigint if all bigints, number or bigint if both
15:21
<bakkot>
RangeError, surely?
15:21
<bakkot>
I guess TypeError makes sense from one perspective
15:22
<ljharb>
why would it be an error of any kind if < with them isn't
15:22
<ljharb>
bigint/number mixing errors are about losing precision by the mixing. this is not a problem for max/min, just like it's not one for comparison.
15:22
<Michael Ficarra>
ljharb: you can't < with 0 operands
15:23
<ljharb>
sure?
15:23
<Michael Ficarra>
so min/max with 0 arguments should do what?
15:23
<ljharb>
Math.max() is -Infinity, Math.max(x) is x, and 2+ operands is where it's useful, and also where it matters
15:24
<ljharb>
i don't see any issue with Math.max(...x) possibly returning either type. if you cared about that, you'd already be ensuring x has 1+ items.
15:24
<ljharb>
since bigint lacks an ultimate max/min value (infinity) it's nonsensical to put in < 1 items and expect a bigint back, no?
15:25
<Michael Ficarra>
yes, so RangeError
15:25
<ljharb>
if it were a bigint-only method, sure
15:25
<ljharb>
but in this scenario it's a bigint and/or number method.
15:25
<ljharb>
and it already doesn't throw an error, so it can't start now
15:26
<ljharb>
and making a new method, that still mixes (because not allowing mixing here is ridiculous), only to throw an error on 0 items (or maybe to satisfy some type system-like mental model?), doesn't seem sufficiently motivated to me
15:26
<Michael Ficarra>
I'm leaning toward new methods on BigInt here
15:26
<bakkot>
sqrt is easy I think, but it's the only obvious sometimes-irrational one which works
15:26
<bakkot>
and cbrt, of course
15:27
<ljharb>
for max and min specifically, i would be staunchly opposed to a bigint-only one. these methods only should allow mixing. and BigInt.max allowing both seems odd.
15:27
<sarahghp>
you can already sort a mixed array, right?
15:28
<bakkot>
ljharb: the only reason to allow mixing is if you have a list which has both bigint and numbers, which you should not have and it is not clear to me that the language ought to have explicit support for
15:28
<sarahghp>
so then Max and Min is logical
15:28
<ljharb>
i don't understand "should not have"
15:28
<ryzokuken>
me neither, why should you not have mixed arrays?
15:28
<Michael Ficarra>
sarahghp: are you referring to the default sort comparator? you can sort anything
15:28
<Jack Works>
Oh but I have some question about BigInt or Decimals in general
15:29
<ljharb>
 * also the language already has explicit support for it - mixedArray.reduce((a, b) => a + b) works fine, eg.
15:29
<Jack Works>
what if I do 1m/3m? Can I get a infinite precise decimal number to represent 1/3 in Math?
15:30
<ryzokuken>
Jack Works: that's an open question for the bigdecimal proposal
15:30
<ryzokuken>
but for decimal128 that's not as big as issue
15:30
<ryzokuken>
or for fractions
15:30
<sarahghp>
sarahghp: are you referring to the default sort comparator? you can sort anything
I mean the default sort on array works, and so, as a practitioner, I would expect max and min to work as well.
15:30
<bakkot>
the default sort on array uses strings
15:30
<HE Shi-Jun>
sounds like we need Fractions? syntax like 1/3r
15:31
<bakkot>
that is, sorts by string order
15:31
<ryzokuken>
yeah, either fractions or decimal128 would avoid the 1/3 issue
15:31
<sarahghp>
yes I know why it works, but I am saying from DX not an internal reason why it would be expected to work
15:31
<ryzokuken>
but then there's other issues that bigdecimals solve... it's a complicated tradeoff
15:32
<bakkot>
I do strongly think that a bigSqrt should truncate to a bigint rather than returning a number or decimal or anything
15:33
<ryzokuken>
+1 for stage 1.
15:33
<HE Shi-Jun>
not sure we really need bigMin/bigMax, it seems Infinity is ok for empty... because the worst case is just throw TypeError so no need to have bigMin/bigMax if it also throw TypeError 😂
15:33
<Tierney Cyren>
always love to see improved math
15:34
<Jack Works>
and for example, in 6.1.6.2.3 BigInt::exponentiate, it doesn't say what will happen if the result is too big to represent. Should the engine give a rounded/approximated result or should the engine throw a TypeError?
15:34
<HE Shi-Jun>
and for example, in 6.1.6.2.3 BigInt::exponentiate, it doesn't say what will happen if the result is too big to represent. Should the engine give a rounded/approximated result or should the engine throw a TypeError?
I suppose it should throw TypeError or OOM ??
15:35
<Rick Waldron>
RangeError
15:35
<bakkot>
I think it currently OOMs
15:35
<Michael Ficarra>

sarahghp: I wouldn't call this "working":

[10n, 2].sort()
> [10n, 2]
[10n, 200].sort()
> [10n, 200]
15:35
<bakkot>
which, presumably we could fix
15:35
<bakkot>
(could, not should)
15:36
<Rick Waldron>
bakkot: implementations all throw RangeError exceptions.
15:36
<HE Shi-Jun>
Michael Ficarra: sort (without pass comparator) is always strange 😂
15:36
<bakkot>
Rick Waldron: oh, huh, good to know
15:37
<bakkot>
my recollection is evidently incorrect then
15:37
<sarahghp>
Michael Ficarra: in this case "works" stands for "does not throw error" 😆. Since > < works/works on a mixed array too, I think it's an argument for why it's surprising when Math functions throw on BigInt
15:37
<Rick Waldron>
bakkot: 262 specifies it.
15:37
<bakkot>
huh!
15:37
<Rick Waldron>
https://tc39.es/ecma262/#sec-numeric-types
15:37
<bakkot>
I did not think we ever specified what to do when you hit implementation limits
15:37
<Rick Waldron>
T::exponentiate(x, y) -> T, may throw RangeError
15:37
<bakkot>
I thought we just assumed infinite memory etc
15:37
<bakkot>
TIL.
15:37
<Michael Ficarra>
sarahghp: but < and > don't Tostring, I'm confused how this is related at all
15:40
<sarahghp>
Michael Ficarra: I'm saying that from a practitioner perspective, given [].sort() and < and > work on mixed types, it is surprising that max and min do not. I do understand why it makes sense internally.
15:43
<bakkot>
POO: can we get another note taker?
15:43
<bakkot>
I'm distracted currently
15:44
<bakkot>
missed most of Shu
15:44
<nicolo-ribaudo>
I can help until the break
15:44
<Josh Blaney>
I can help
15:46
<Tierney Cyren>
am I hearing someone's discord notifications lmao
15:46
<Tierney Cyren>
I keep thinking I'm getting pinged
15:46
<ryzokuken>
lol same
15:46
<HE Shi-Jun>
same :)
15:48
<Richard Gibson>
Math.max(1, 1n)?
15:49
<bakkot>
Richard Gibson: first-wins, I think
15:50
<Michael Ficarra>
same for Math.min?
15:51
<bakkot>
presumably
15:51
<bakkot>
it should be equivalent to "stable-sort by <, then take the first element"
15:52
<bakkot>
or, equivalently, a loop which does if (cur > max) cur = max
15:55
<Michael Ficarra>
max = cur, surely
15:57
<bakkot>
uhhh yeah that one
15:57
<jschoi>
https://github.com/js-choi/proposal-bigint-math/issues/3
16:06
<ptomato>
shu: to expand on something ljharb said in the last remark, there's a lot of transitive code that depends on this pattern, but arguably there's also a lot that should but does not yet, because they haven't realized it's a problem
16:07
<ptomato>
(was going to put this as a reply on the queue, but we were out of time)
16:07
<shu>
i hear you, and that helps convince me this is of higher importance
16:08
<ljharb>
re "holistic": imo, pipeline + method extraction syntax + getIntrinsic would make for a much more ergonomic approach, on top of which perhaps a very ergonomic syntactic solution could be developed if it were warranted
16:08
<shu>
but you know, what i hear is also not that this is impossible today, just that it sucks to have to write
16:08
<ljharb>
very true
16:08
<ljharb>
altho CSP makes some of it impossible (but, "make syntax-reachable intrinsics just be global" would address that part)
16:09
<shu>
don't put that evil on me
16:09
<shu>
i want to remain not touching csp
16:12
<shu>
ljharb: oh one thing i forgot to say was i probably don't want enumeration
16:12
<shu>
so preference from me is separate proposal there
16:12
<jschoi>
re "holistic": imo, pipeline + method extraction syntax + getIntrinsic would make for a much more ergonomic approach, on top of which perhaps a very ergonomic syntactic solution could be developed if it were warranted
I plan to collaborate with you and hopefully HE Shi-Jun on a simple method-extraction proposal (https://github.com/js-choi/proposal-bind-operator/).
16:13
<jschoi>
I plan to propose it next meeting.
16:14
<ljharb>
looking forward to it
16:15
<ljharb>
ljharb: oh one thing i forgot to say was i probably don't want enumeration
i agree "that preference" means it should be a separate proposal
16:15
<TabAtkins>
Do all the chairs have edit access to Reflector issues? I just learned of the HackMD for the agenda because it was left in the comments for the reflector issue and not put in the initial post as well.
16:16
<ljharb>
all the delegates do
16:16
<shu>
i thought they didn't like posting it because it's usually under significant flux
16:16
<shu>
it's a source of truth in the sense that that's the document they use to coordinate among themselves and to resolve rescheduling conflicts
16:17
<ljharb>
note that some people may not like it if you edit their comments, so best to only do it with explicit permission; for the record everyone is always free to fix my typos, update URLs, add missing info, things like that, as long as it's correct :-p
16:17
<TabAtkins>
i'm hearing in TDZ that it shoudl be trusted over the tcq, so I'm not sure
16:17
<shu>
it should be is my understanding
16:17
<ljharb>
i've only ever used TCQ as a source of "what's happening now", as opposed to relying on it to predict the future
16:17
<shu>
right
16:17
<bterlson>
TCQ hasn't been updated with the agenda items we will bring forward, will work on that
16:20
<shu>
bterlson: am i up next? i.e. is it possible to accommodate adam klein's constraint request? it was added pretty late so understandable if not
16:20
<bterlson>
checking
16:21
<bterlson>
shu: confirm you mean the fixed shape item?
16:21
<shu>
i do, yes
16:22
<shu>
adam is unable to make 10-11 AM PT, so if we switch my two items to the last hour that resolves that. just not sure if possible
16:26
<leobalter>
shu: in this case I'll need to sync with Caridy too as he should join for this discussion.
16:26
<bterlson>
shu: I think we can make it work, plan to present 1100 PDT
16:26
<bterlson>
leobalter: hopefully that will work for caridy?
16:27
<leobalter>
bterlson: I hope so, let me ping him
16:27
<bterlson>
rbuckton: would you be able to present regexp at 1000 PDT?
16:29
<leobalter>
I understand we have overflow for this meeting, but in this case, and I'll miss discussing Jordan's topic "Tightening host restrictions to improve testing". I believe this relates to EcmaScript improvements/fixes and I'm biased to prefer that over new features, but my same bias also wants some of the Stage 1 features.
16:29
<leobalter>
time is unfair
16:32
<bterlson>
The emerging plan is thus: 1:00 EDT RegExp feature parity rbuckton (with ljharb tightening host restrictions as backup in case Ron cannot present), 2:00 EDT fixed shape for objects shu, 2:45 small resizable buffers shu
16:33
<bterlson>
will update TCQ in a few moments
16:34
<shu>
great, thank you!
16:36
<shu>
sorry for last minute request
16:36
<Rob Palmer>
TCQ is now updated. And HackMD
16:36
<Rob Palmer>
Next is Ron Buckton with RegExp Feature Parity
16:38
<yulia>
please go to the reflector for the result from this morning's session
16:39
<yulia>
i will get dinner
17:03
<Rob Palmer>
Yulia's Reflector post: https://github.com/tc39/Reflector/issues/397
17:06
<Michael Ficarra>
I have no interest in just importing regexp features wholesale
17:07
<ljharb>
i like some of these features, but parity for the sake of parity does not sound like a good thing to me
17:08
<Michael Ficarra>
same
17:08
<Michael Ficarra>
and we should not be forced to take on unwanted features because some of them are good
17:08
<Michael Ficarra>
these could all be individual proposals
17:14
<littledan>
I think it'd make more sense to choose a specific scope, for bringing something to Stage 1
17:14
<littledan>
like one of these inner proposals
17:14
<Michael Ficarra>
sounds like that's what Ron is looking for now
17:14
<jschoi>
It seems like Ron is proposing forming something like a subcommittee to investigate regex gaps with regard to other languages, with individual subsequent proposals for identified gaps.
17:15
<littledan>
OK, that sounds good to me. I'm happy to see discussion reopened here
17:15
<Michael Ficarra>
the feature that lets you change the flags in the middle of the pattern scares me quite a bit
17:15
<littledan>
yeah, that's how the committee reacted last time Brian brought it up
17:15
<shu>
well, if ron is actually proposing another TG he should be explicit?
17:15
<Michael Ficarra>
the context-dependency in the regexp grammar is already hard enough for people
17:16
<littledan>
well, if ron is actually proposing another TG he should be explicit?
I guess this would be more of a temporary ad-hoc set of calls?
17:17
<shu>
stupid question
17:17
<shu>
why are textmate grammar parsers not rewritten to simply not use regexps
17:19
<Justin Ridgewell>
why are textmate grammar parsers not rewritten to simply not use regexps
Without writing a whole scripting engine?
17:19
<shu>
maybe it's because i don't know what textmate grammars do
17:19
<shu>
textmate grammars themselves have regexps to define what an e.g. identifier should be?
17:19
<jschoi>
Basically. https://macromates.com/manual/en/language_grammars
17:19
<Michael Ficarra>
we don't need any of these textmate things because we have a language around our regexps, our language isn't just regexp
17:19
<Justin Ridgewell>
https://github.com/textmate/javascript.tmbundle/blob/master/Syntaxes/Regular%20Expressions%20(JavaScript).tmLanguage
17:20
<Justin Ridgewell>
VIM syntax parsers are very similar
17:20
<bakkot>
there's been a proposal for regex composition, which seems strictly better than this define thing
17:20
<Michael Ficarra>
yep
17:20
<littledan>
(also lots of people like RegExp.escape better)
17:21
<littledan>
Context-Free Expressions!
17:21
<shu>
at the whole-stack level, it seems easier to extend TextMate grammars to have functions in place of regexps than to... keep extending regexps?
17:24
<jschoi>
TextMate grammars are a de-facto standard, so it’d have to be a de-facto extension from one vendor to do that, heh…
17:24
<shu>
that seems cheaper to me than changing JS
17:25
<littledan>
I don't see why JS should have part of a TextMate interpreter built-in, even if TextMate won't change
17:25
<littledan>
I think it's more like, TextMate may show that some things are useful
17:25
<littledan>
rather than that, we should completely align
17:26
<shu>
i'm not saying that, i'll try to explain better when the queue item comes up
17:28
<Michael Ficarra>
totally agree with Waldemar here about the x flag
17:30
<jschoi>
I think that Ron’s review of existing regex functionality is very broad, impressive, and useful—if only to see precedent and existing practice, although of course JavaScript should not adopt features from other languages wholesale.
17:31
<jschoi>
I do know that lots of people in Perl have happily used whitespace and comments in regexes with a flag for decades. Regex whitespace and comments help them quite a bit…although whether that’d work in JS now is tough.
17:32
<HE Shi-Jun>
agree, I really want whitespaces and comments in regexp 😃
17:34
<ljharb>
i want those too, but "i want to be like perl" is not a thought i can ever recall having
17:34
<HE Shi-Jun>
Regexp is actually a sublanguage , so I also support a RegExp TG like Chip post in the queue 😂
17:38
<Michael Ficarra>
to clarify, what I was referring to earlier when I said "with few exceptions, proposals are for single features", I was thinking about Rick Waldron's Math functions proposal which brought in a lot of new things at once but was all done as a single proposal
17:38
<bterlson>
ljharb: The buffet was presented in 2015 believe it or not
17:39
<bterlson>
https://esdiscuss.org/notes/2015-11-18
17:39
<Michael Ficarra>
was that at the MSFT meeting?
17:39
<Michael Ficarra>
oh, I guess not, not in November
17:39
<jschoi>
Yeah, this is the impressive website. rbuckton: I think this is great as a general reference, something like a CanIUse.
https://rbuckton.github.io/regexp-features/
17:39
<bterlson>
It wasn't, but I don't remember where it was
17:43
<bterlson>
shorter ljharb: this already has stage 1, bring the individual proposals now?
17:45
<ljharb>
yes, exactly that
17:46
<rbuckton>
So, roll this into "regexp buffet" and break down the proposals?
17:48
<ljharb>
yes
17:51
<shu>
i usually don't consider terseness a top goal
17:53
<rbuckton>
By terse I mean, better than assembly. A goal of any high level language is to remove unnecessary complexity where possible to improve expressivity and readability
17:55
<ljharb>
with a program containing regexes, often the unnecessary complexity is removed by moving logic away from using regexes
17:56
<jschoi>
“Now you have two problems”…
18:00
<bterlson>
I think textmate is just a convenient generalization, not a motivation in and of itself, fwiw. There exists a set of use cases that textmate grammars are very good at (if frustrating to use) that would also be useful for many JS use cases as well.
18:01
<bterlson>
I continue to be sad that a dfa-based engine with all-matches semantics isn't being discussed more
18:01
<Michael Ficarra>
bterlson: I dunno, when implementing parsers in JS, you shouldn't be trying to shove as much of the code into regexps
18:01
<Michael Ficarra>
you have this whole language to use
18:02
<bterlson>
parsing with regexp isn't a motivator
18:02
<bterlson>
scanning, though...
18:02
<bterlson>
sure you could implement these things using js code and a while (pos < str.length) loop but
18:02
<Michael Ficarra>
you don't need recursion in your regexps for scanning
18:02
<rbuckton>
I agree that regexps can be complicated, but they can also significantly cut down on equivalent javascript code in quite a few cases.
18:03
<bterlson>
I'm not going to argue specifically for recursion, but it's safe to say in general that parsing JS is also not the motivator behind these :)
18:03
<ljharb>
less code !== less complexity
18:03
<Michael Ficarra>
rbuckton: but why? you have nice debugging tools for JS and nice high-level language features
18:03
<rbuckton>
Recursion is a huge stretch, to be fair. I'd really like support for subroutines as it improves readability.
18:04
<Michael Ficarra>
the DEFINE feature was a perfect example of something we definitely do not need because we have a language outside of the regexp
18:04
<Michael Ficarra>
if the whole language was the regexp, fair, those are nice features, but that's just not the case
18:06
<rbuckton>
I've written ISO8601 date/time parsers, its a lot easier with DEFINE. Without it you end up with a lot of string concatentation + new RegExp(..). Writing it as pure JS is a mess :/
18:06
<Michael Ficarra>
okay and what's wrong with the string concatenation?
18:06
<rbuckton>
(part of the reason the DEFINE example was an ISO8601 date)
18:08
<devsnek>
i am so hyped for shared memory
18:08
<rbuckton>
okay and what's wrong with the string concatenation?
You mention debugging. String concat a bunch of regexp patterns together to achieve what you could with DEFINE, then look at the regexp in the watch window and its unreadable.
18:09
<rbuckton>
i am so hyped for shared memory
I am as well. May be a longer term goal but really need code sharing/shared functions as well.
18:10
<devsnek>
i wish webkit pushed more on their shared memory strawman
18:10
<TabAtkins>
Rather than building variables into regex, couldn't we have an escape-hatch in regex similar to ${} that lets you sub in arbitrary sub-regexes?
18:10
<rbuckton>
Rather than building variables into regex, couldn't we have an escape-hatch in regex similar to ${} that lets you sub in arbitrary sub-regexes?
That's Callouts and they're not great.
18:11
<rbuckton>
Unless its just Regexp.tag with string interpolation, which is still hard to read in a watch window.
18:12
<TabAtkins>
Yeah suppose it's just Regexp.tag. My fear is that the moment you want to do anything slightly more complex with the definition, you'll have to fall back on string interpolation anyway
18:14
<rbuckton>

My primary wishlist for RegExp syntax is, in order:

  1. Modifiers (?imsx-imsx) and (?imsx-imsx:subexpr)
  2. Possessive Quantifiers/Atomic Groups
  3. Conditionals (?(cond)yes|no) (even w/o DEFINE)
  4. x mode and comments
  5. Subroutines
  6. n mode
  7. \R
  8. \A, \z, \Z
  9. Rercursion (but not bullish on this one)
18:16
<ljharb>
i think out of that list, for me it's 4,6,7,8, and maybe 2,1
18:16
<HE Shi-Jun>
It allow create struct objects in JS, so I don't understand why this proposal is for wasmGC -> JS ?
18:16
<Michael Ficarra>
for me it's 8, 7, 2, and... that's probably it
18:18
<ljharb>
i think comments are critical
18:18
<ljharb>
ime any regex longer than like 10 characters tends to be unreadable, and i always have to write an "x mode" version of it in a multiline comment so it's annotated
18:18
<Michael Ficarra>
was waldemar's argument not convincing, ljharb ?
18:18
<devsnek>
ron you're asking for turing completeness
18:18
<HE Shi-Jun>
Plain structs seems just sealed object... so what's the diff between this with @seal class Box {} ?
18:18
<ljharb>
Michael Ficarra: i must have missed it
18:19
<rbuckton>
Can achieve 8 with 1, which is one reason I find 1 more useful. \A is (?-m:^), \z is (?-m:$)
18:19
<Michael Ficarra>
ljharb: we can't have x mode in literals because of the grammar, and if you're using the RegExp constructor, you can just concat strings and put comments between them
18:20
<rbuckton>
x mode improves readability by making whitespace insignificant. Its more than just x-mode comments
18:20
<TabAtkins>
yeah, x mode is real critical imo, i use it constantly in python both for whitespace and comments
18:21
<asumu>
It allow create struct objects in JS, so I don't understand why this proposal is for wasmGC -> JS ?
The struct objects created in JS would (at least initially, in this minimal proposal) not be importable as Wasm GC structs as there isn't enough type information. The intention is that this proposal helps explain how the Wasm GC struct gets reflected as a JS object.
18:21
<Michael Ficarra>
... you both know that you can put whitespace between concatenations too
18:21
<ljharb>
string concat is not workable; that's not statically analyzeable (linting) or syntax highlightable (human review) and it's too easy to have bugs caused by dynamic string creation
18:21
<TabAtkins>
Python even makes it easier to do comments outside of the strings, since it auto-concats consecutive strings, but it would still be decently uglier to write
18:21
<nicolo-ribaudo>
Could someone give an example that shows why x in (possibly multiline) literals is impossible?
18:21
<ljharb>
iow if it can't be done in literals then i think it can't be done, but doing it in literals is the sole value prop
18:22
<Michael Ficarra>
ljharb: what do you propose we do then? x mode doesn't work with our grammar
18:22
<ljharb>
is there a spec for x mode that makes that a foregone conclusion?
18:22
<TabAtkins>
"doing it in literals is sole value prop" strong disagree from Python experience
18:22
<ljharb>
i certainly don't understand the grammar well enough to disagree with that assertion, but it seems overly strong at this early stage
18:22
<Michael Ficarra>
we could have x mode affect non-lineterminator whitespace
18:23
<Michael Ficarra>
but I think people would expect it to allow you to split the regexp across lines, too
18:23
<Michael Ficarra>
which we cannot do
18:23
<devsnek>
why can't we split it across lines
18:24
<Michael Ficarra>
it would already be valid syntax
18:24
<nicolo-ribaudo>
No, regexps cannot currently contain line breaks
18:24
<Michael Ficarra>
I didn't say it would be a regexp
18:24
<nicolo-ribaudo>
Then, an expression cannot currently start with / (if it's not a regexp)
18:25
<devsnek>
can one of the people saying this is ambiguous please say which production(s) it is ambiguous with
18:26
<Michael Ficarra>
hold on, let me try to come up with the ambiguous case that waldemar posted earlier
18:28
<rbuckton>

Which is easier to read?

// inline (taken from ecmarkdown)
/^<[/!]?(\w[\w-]*)(\s+[\w]+(\s*=\s*("[^"]*"|'[^']*'|[^><"'=``]+))?)*\s*>/

// string concat (could use String.raw`` but its even harder to read)
new RegExp(
  // start of tag
  "^<[/!]?" +
  // tag name
  "(\\w[\\w-]*)" +
  // attribute(s)
  "(\\s+" +
    // attribute name
    "[\\w]+" +
    // attribute value
    "(\\s*=\\s*(\"[^\"]*\"|'[^']*'|[^><\"'=``]+))?" +
  // repeat attribute
  ")*" +
  // end tag
  "\\s*>");

// x mode
new Regexp(String.raw`
  # start of tag
  ^<[/!]?

  # tag name
  (\w[\w-]*)

  # attribute(s)
  (\s+

    # attribute name
    [\w]+

    # attribute value
    (\s*=\s*("[^"]*"|'[^']*'|[^><"'=``]+))?

  # repeat attribute
  )*

  # end tag
  \s*>
`, "x");
18:28
<rbuckton>
Ugh with element's rendering of tagged templates in a fenced code block :/
18:29
<rbuckton>
Better format here: https://gist.github.com/rbuckton/856f61c4b3d9dbd8a048d0a2e99cfe73
18:30
<Josh Blaney>
as a note, the person speaking is not in the delegates text file
18:30
<rbuckton>
String concat means double-escaping, or prefixing String.raw for every line, which reduces readability and makes it easier to make mistakes.
18:31
<littledan>
the previous speaker was Asumu Takikawa
18:33
<littledan>
The string part is excellent. Just being able to postMessage a string to a Worker cheaply is a huge.
18:33
<littledan>
(and this doesn't require a spec change)
18:40
<ljharb>
+1 for mark's perspective
18:42
<devsnek>
idk i get rust send/sync vibes from this, which is a good thing
18:49
<devsnek>
what is this meeting software called
18:49
<devsnek>
oh jitsi
18:50
<Rob Palmer>
(my jitsi was not locked on a user - it was just... jitsi)
18:53
<Rob Palmer>
15:52-15:57
19:03
<ptomato>
do we take notes of this item?
19:03
<shu>
the incubator call chartering? usually not
19:03
<ptomato>
ok, will delete this item unless anyone objects quickly
19:04
<shu>
don't think it matters if there're already notes
19:04
<shu>
just saying if it's missing, it doesn't matter if it's missing
19:04
<ptomato>
they're somewhat bot-garbled
19:04
<shu>
yeah, deletion sgtm
19:04
<ptomato>
but I can leave them too!
23:14
<shu>
since the two incubator call topics this time aren't proposals, i'm not sure who should be added to the stakeholders list
23:14
<shu>
PTAL at the new charter (https://github.com/tc39/incubator-agendas/issues/20) and add yourself if you're interested in one of the topics
23:50
<bakkot>
how often do you figure someone calls codePointAt with a negative index
23:50
<bakkot>
can we make that wrap