also, what happened with the "set method argument internal slot" discussion? i had to drop off

Ashley Claymore: can you share with me the test case you used to identify SM gc behavior?

I'd like if we rename this splitn to String.prototype.part (or parts)

(sounds like Luca Casonato got stage 1? :D)

Could you add that to this issue? https://github.com/lucacasonato/proposal-reversible-string-split/issues/6

But basically, if we use a flag argument in .split(), I don't think we should significantly change the existing semantics/behavior of the proposal. .split(..., 2) should still always trigger (up to) 2 splits, with the option just controlling whether we get the remainder or not included in the array.

If people already don't know about the second argument, how will they find a completely separate method?

That also avoids all the regex questions, since the answer remains "act exactly as normal, just include the remainder as a final item"

Ugggggh I didn't realize the N is literally "length of the returned array" even when regex capture groups are used, that's worthless.

for n >= 0, i presume

then why did we even expose an immutable binding inside the class? I'm unconvinced

to replicate this feature with ergonomic brand checks, i think the user would have to assign to the brand field at each return point in the constructor

which fwiw is also subpar, it's just that self-recursion is much rarer than accessing the constructor's statics

only because someone might get a hold of this during the constructor even if the constructor throws, right? if you assume the ctor/initializers don't throw it's equivalent?

ugh weird

It seems that both do, which is weird. Things in computed property names are both in the class and not in the class?

Hax's proposal makes it pierce function boundaries

rbuckton: I just realized that I'm going to miss the Enum proposal because I have to go get my kid from school.

Mathieu Hofman: can you confirm the conclusion we have captured in the notes is correct

Looks right to me. And PR has been updated.

Ashley Claymore: isn't that just "add a statement at the end of the try" tho

Ashley Claymore: there's been proposals for like a catch.error meta-property you could use in finally which would tell you what the error is in that case

Also there's not a way to only freeze prototype right, though I think there is a proposal for that right?

override mistake be damned?

We (three champion) haven't has meeting for that, but we chatted about it yesterday and we tend to make class.hasInstance in computed property syntax error. Though as current spec text, (if I really figure out all things) i believe it's allowed but always give u false, because at that time, no one have the class so no instance of it.

It's not always false. You can define a function inside a computed property name expression, squirrel it away somewhere, and call it later.

Also there's not a way to only freeze prototype right, though I think there is a proposal for that right?

if you can get someone else to own the breakage fallout bugs on v8, sure

I have ideas to tame the override mistake beast, but I need to familiarize myself with previous attempts first

bakkot: you're right, that is the one way it's unlike; and given that it's impossible via the callback, we all decided to accept that difference. but that doesn't mean further avoidable deviation is a good idea

shu: how is it a lever? people are already doing this all over the place

For example:

const Color = { Red: 0, Green: 1, Blue: 2 };
const data = { color: Color.Red };
fs.writeFileSync("foo.json", JSON.stringify(data));

Writes {color:0}, which isn't helpful when maintaining config files, while:

const Color = { Red: Symbol(), Green: Symbol(), Blue: Symbol() };
...

Would be safer at runtime, but would fail to stringify.

How is this not solved by const Color = { Red: 'red' , ..}