Good morning. I'm not going to be available until around noon, so if someone else from the Test262 Maintainer Group would like to give the update, that would be great!

ljharb: can you put the names in the notes

Rick Waldron: it was a comment you made in relation to https://github.com/tc39/proposal-rm-builtin-subclassing and i think i just linked it wrong

Ok, confirmed: we do not rely on Symbol.species in eshost or test262-harness.

Symbol.species is used in test262's harness files and tests themselves, for cross realm testing. That could be changed.

like any other if

yes, 0 === -0

thank you. well, in the context of slides, i'm confused that why it isn't match(expr) { if(expr): expr }

yeah fair, it's a confusing example

so to match an array with holes I'd need to do [undefined, undefined, "foo"]?

I have no problem with when (unused), I just don't see a use for default if you already have that

also what's the use case for the bare if one

what's the case for when (unused) {}

I'd just write when (_) if (whatever)

Symbol.match was a mistake

match (e as x), maybe

oh god are we going to have both Symbol.match and Symbol.matcher

we have that in previous design. we think it's useful but can also be added in the future match (e) as x {}

excited for us to say Symbol.matcher was a mistake in 6 years

oh god are we going to have both Symbol.match and Symbol.matcher

do any of the built-in prototypes implement the matcher protocol?

Symbol.decons

i think there's value in the exercise of writing out a grammar for a very syntax-heavy proposal

i also reject the notion that "initial spec text" means any text document that's published as a spec draft

hax is talking about:

he think

when (${String} with s): expr to check if it is a string is wordy

to check if something's a string you'd do if (typeof x === 'string'), no?

when (x) if (typeof x === 'string') is the obvious way to write this

it's not a use for bare if because you need to refer to the match-ee

Can when (${String} with x) match String wrapper object?

Can when (${String} with x) match String wrapper object?

ljharb: I have to disagree. My understanding is that fundamental spec quality should also match entrance for Stage 2.

and he think when (_) if (expr) can replace the bare if

we're going to get things that hopefully aren't too far off course from what any individual delegate's cohesive big idea is

pattern matching and decorators as our first 2 proposal topics? time constraints must've been rough this time around

I support the current decorator proposal, but the metadata part is sus and need more discussion

also what's the use case for the bare if one

same, also some concerns about the accessor keyword

how would "epics" help this? genuinely asking, no idea what those are

they say the accessor keyword is necessary and not blocking the future extension of the Grouping accessor proposal so I guess it is ok for me

often, when something like temporal has been presented i found myself checking out because i didn't have focus for the whole proposal. if we had a process that was like. Here is the big proposal and what it is trying to do, and it is composed of these parts. we are talking about part 1, which has it's own design concerns -- i would find this easier to think about

i think we have match (e) as x { in the current proposal (or maybe match (e as x) {, i forget which we agreed on)

I claim and and or have an obvious precedence relationship

yulia: Reading through old issues I found this, which convinced me that there are good reasons for accessor to exist as a keyword (instead of making decorated fields into accessors by default): https://github.com/tc39/proposal-decorators/issues/348#issuecomment-736889352

I know the &&/|| precedence is well-established, I strongly object that it's obvious; I've been programming for 20 years and I still always parenthesize when I'm mixing those, because I never remember what the precedence is.

TabAtkins: ok so my feeling is that it would be very useful to bind the name at the top level of the match, because otherwise there's going to be a bunch of match (expr) when (x) if (f(x)) ...; when (x) if (g(x)) ...; etc

do you use unnecessary parentheses when mixing +/- with * in arithmetic expressions, too?

I've never seen a proposal that had more venues for developer feedback than decorators

here is how I would write class-level metadata for decorators without explicit support:

let { decorate, finalize } = makeDecorator();
class A {
  @decorate
  property = whatever;
}
finalize(A);

where makeDecorator is a userland function that has an internal WeakMap or whatever. it's two extra lines. does this do the thing you want metadata to do?

so for the gnome use case linked above it would look like

let { registerClass, property } = GObject();

@registerClass
class MyClass {
  @property({ type: Boolean })
  x = false;
}

where the @property decorator would stash the necessary fieldname->type mapping somewhere where the @registerClass decorator could get at it

bakkot: is that really what we say about the current Realm for %name%s?

yulia: Would you consider the holistic dataflow discussions we’ve been having lately a TC39 “epic” about a broad feature?

My only qualm with Temporal is how hard it is to use for its main purpose (date arithmetic, specifically relational comparison).

A.isEarlier(B) is a bit harder to conceptualize than A < B, imo. And is very English-focused vs. compareTo.

Unfortunately, I'm unable to attend plenary this week. I wish I were able to be present to argue for Metadata's inclusion for Stage 3 decorators. Requiring an entangled decorator pair (one for class, one for member) is over complex and highly unmanageable.

bakkot: my concerns would be the same as rbuckton, that overlapping metadata would require multiple registers which could get confusing

but really all we need is a sidechannel, similar to the one you've demonstrated

it seems like a high cost when each decorator would generally not require a class level decorator

but that doesn't change the general idea of using a plain object has the metadata holder rather than constructing that in the background via the context.setMetadata method

IIRC that was the approach in the proposal. It's a design the champion and stakeholders have discussed for multiple years to meet those design goals.

to clarify, you could potentially place metadata related to a method on Symbol.metadata on the final method itself