since we won't have time to discuss temporal's stage this meeting, i guess we'll see either way :-)

the question is NOT about whether there are only editorial changes remaining, it is about whether the remaining changes are considered "major", which is subjective

Duncan MacGregor When comparing floats there is the same beahvior: 1 < NaN is false, 1 > NaN is false, and 1 == NaN is false, so compare cannot return neither -1, nor 0, nor 1.

Ah right. Too used to comparison methods which return an int and so cannot return NaN. It is also worth noting that things like Array.prototype..sort() turn a Nan value as +0.

The .sort behavior seems good with the .compare behavior: "I don't know how to compare these two things, so I don't shuffle them around"

The .sort behavior seems good with the .compare behavior: "I don't know how to compare these two things, so I don't shuffle them around"

I do not see any route to convincing browsers that the juice is worth the squeeze on Decimal, other than the incremental route of proving it out first in API form.

agree, and I disagree with the characterization that we are having a meta discussion on process. we are talking about this proposal and what appear to be blocking possibly based on stage 2.7 or 3 entrance criteria rather than stage 2

Eemeli's comment makes it sound like it's a foregone conclusion that a new primitive is not possible

That's an unfair characterization. A lot of folks making this claim are making assumptions about what's currently working and what isn't working in the spec.

waldemar: What do you think about "conditional Stage 2" on fixing those spec issues?

That's fine by me.

the polyfill is not being developed in a way where it intends to compete with other decimal libraries

So I can say that operator overloading is a significant implementation overhead in Ruby, and we try very hard to boil it away as much as we can. It's tempting, but it has real downsides.

It would probably have to be lexically scoped to restrict the overhead to where you need it

Question to implementers, when bigint was added along with its necessary operator overloads, how much of an impact on performance did that have for other javascript code that didn't make use of bigint?

AFAIK, none

I don't understand what you mean by "user-defined primitive capability"?

It would still be an object though so it's not really a primitive. It just looks kinda like a primitive unless you squint

For the purpose of this discussion, I mean some bespoke syntax to declare a user-defined "primitive" type, much like a class, except it isn't Object.

(c.f. Project Valhalla etc)

Trigger warning, please. 😀

Oh, the area where we would likely see a performance degradation is if people can define new cases involving the existing primitives.

Yeah, I DEFINITELY don't think we can let users change e.g. number + number

Yeah, I DEFINITELY don't think we can let users change e.g. number + number

But if I have a matrix type I'd definitely want to be able to define number * matrix… This is where the dragons are.

But if I have a matrix type I'd definitely want to be able to define number * matrix… This is where the dragons are.

You don't pay the cost of operator overloading for all Objects, only this different thing. If you want to define a "primitive"-like type with operator overloading, you use this and not Object. Implementations only have to plumb this through once and it is a catch-all for any "primitive"-like type we might want to include in the standard library as well.

You don't pay the cost of operator overloading for all Objects, only this different thing. If you want to define a "primitive"-like type with operator overloading, you use this and not Object. Implementations only have to plumb this through once and it is a catch-all for any "primitive"-like type we might want to include in the standard library as well.

Lack of guaranteed identity seems like a relatively small problem.

Yeah, I could see object <op> primitive calling some overload too

But maybe that's different for other engines

My understand was that the with operators from ... syntax that littledan had proposed was primarily to address performance concerns raised by some implementations

My understand was that the with operators from ... syntax that littledan had proposed was primarily to address performance concerns raised by some implementations

with operators from means a lot of requirements for bookkeeping. But it's easy to see when you're not inside of those things and you can use the ICs which don't have support for the new operator overloaded things

The whole point of ICs is that you only generate the cases you've seen though. So, I'm a bit surprised that would help anything.

oh sorry I don't mean ICs, I guess I mean paths in the interpreter or something

I think the thing I wouldn't like about trying to add operator overloading to JS as currently defined is that we do various coercions on the two arguments and then perform the operation. Ruby and Python both tree all this stuff as a simple method call, so it is simply up to the left operand what is done to the right operand.

Why is it necessary to do coercions?

So at the moment we do GetValue and then ToPrimitive (which of course we don't actually need to do most of the time).

yeah but this is the first to introduce an import syntax, right?

The fact those are just used in operator coercion means we'd need to come up with a new way to spec that, and work out whether we look for overloads before or after doing those conversion.

there's so many of these module proposals

Sorry about that, the space is huge and we ended up trying to split it in "independently motivated incremental changes", but maybe it ended up not being the best way 😅

I'm legitimately still confused 😭

Let's talk about that during lunch? :)

yes, please help me

Going back through meeting notes I have found the first reference to operator overloading and decimal here in section 9.iv.b "Decimal for stage 0". keith_miller .

It's much older (2002-04): https://web.archive.org/web/20161227042517/http://www.mozilla.org/js/language/js20-2002-04/core/operators.html

sent an image.

is there any reason not to just merge it right away?

I guess I don't understand the point of having normative text that has no requirement?

The notes should be for context; reading the normative text should be enough to build an implementation, even if we can't have tests for it

Example: step 7 of https://tc39.es/ecma262/#sec-suspendthisagent

Example: step 7 of https://tc39.es/ecma262/#sec-suspendthisagent

what is p1/p2 in the slide?

what is p1/p2 in the slide?

That's definitively observable though. So it has actual requirements and is testable.

If we have such auto correlation incantation, could it also apply to normal class?? 😃

The question is: if you were to delete the green notes, would your implementation still behave the same as if you are implementing it by also taking the green notes into account?

Should they be considered non-spec compliant?

The first box would have to be something like: "Implementations are expected to implement a pause or yield instruction if some version of the best practices of the underlying architecture recommends such instructions in spin loops."

ok, so then i don't understand Mechanism 1 I think

No, how could it? Classes aren't shareable.

If that's the consensus then I don't have a problem with normative should. Although, I would prefer a recommends but maybe should is well defined enough in TC39?

no, it's like, at startup, thread A sends a message to thread B containing some magical reference to the Point class, and thread B hooks up that reference to its Point class

we'd still need some "key" for each shared struct?

ok - i still don't quite see how this isn't exactly the same as the auto correlation key

either seems fine to me, I don't know what the difference is tbh

ok - i still don't quite see how this isn't exactly the same as the auto correlation key

(and, I have forgotten a bit) and if you don't import on a worker, and you recieve a shared struct... you can read them like they're just POJOs with a null proto?

To clarify for myself.. if you don't have auto correlation, but you have imported the module on main and worker... it's just that points which are post-messaged will have no prototype; right?

Not just postmessage. You can just set a shared struct value into a field on an existing shared struct

right, this is why the only thing needed with postMessage is this one-time setup

manual correlation does not have to weaken privacy

Yeah, do we know how it was thought it would?

well, currently Wasm doesn't need to correlate types because it's all structural. But if it gets some nominal capacity, why not transmit it by postMessaging WebAssembly.Module instances? I guess the thing is, they don't contain any reference to their Realm/Agent right now.

What restricts a module to contain only a single shared struct definition?

littledan: I think auto-correlation could handle privacy just fine.

I think nicolo-ribaudo 's handshake mechanism would also handle it fine. It's "even more lexical".

My concern with manual correlation (i.e., based on postMessage/exemplars) is that realm B could wire up a struct from realm A into a struct definition that exposes private state, so you have to guard against malicious code being able to spawn a Worker (CSP helps on the web, but not in NodeJS) that can be used to hijack a struct.

How would auto correlation work across languages in a way that doesn't require either language to hold objects specific to the other language (as each language may run without the other existing)

Does it need to work across languages? If JS private state is a uniquely JS mechanism, then WASM could interact with the struct via FFI calls into JS.

Does it need to work across languages? If JS private state is a uniquely JS mechanism, then WASM could interact with the struct via FFI calls into JS.

My concern with manual correlation (i.e., based on postMessage/exemplars) is that realm B could wire up a struct from realm A into a struct definition that exposes private state, so you have to guard against malicious code being able to spawn a Worker (CSP helps on the web, but not in NodeJS) that can be used to hijack a struct.

Does it need to work across languages? If JS private state is a uniquely JS mechanism, then WASM could interact with the struct via FFI calls into JS.

some form of nominal correlation would be useful for Wasm, especially if Wasm wants to interact with JS in various threads and give prototypes to its objects

Does wasm really have no notion of private data for objects?

Does wasm really have no notion of private data for objects?

some form of nominal correlation would be useful for Wasm, especially if Wasm wants to interact with JS in various threads and give prototypes to its objects

if you use forgeable type description, of course. Manual correlation has to be based on non forgeable type descriptors that need to be explicitly shared with the realm in the first place

Mathieu Hofman: you're engaged in the nuts & bolts of how correlation could work. great! but i'm more interested in working through the very high level, "i feel this is unsafe" objection

you do some tearoffs that can exfiltrate private data and import them from the wasm side

What do you consider to be a "non forgeable type descriptor"?

IMO the only interest to private data is to have it shared, so that it can be used for encapsulation

Do we, as a committee, think JS privacy is a security feature? Would it be unforgivable if private state isn't really private at the realm boundary? If we could have struct S { #x; ... } in realm A mapped to struct S { x; ... } in realm B, would we consider that a security vulnerability?

yes, yes, and yes. if I understand your example correctly, the private field on A being accessible from B, I would consider that a security vulnerability

But I also do not hold that private state is a security feature.

would you agree that encapsulation is a security feature?

that risks devolving into arguing what "security" means so i think of it in terms of SLAs and who's responsible for hitting those SLAs

forgetting about security for the moment, the private field on A being accessible from B, is it not problematic that this is violating privacy/encapsulation in general?

all bugs are problematic, i'm explaining the real world consequences of how problematic it's considered

yeah that's an interesting typo that only an English speaker could make

Yes, ICU and JS implementations tend to implement this historical part

Could somebody re-explain to me this comment? 😅 Do databases use timezones that are not the timezones we are using in temporal?

leftmostcat (UTC-7): I would like to start a proposal for declarative custom time zones. Would you be interested in co-championing this with me? I don't have the domain expertise in iCalednar/jCal/JSCalendar to turn their schemas into spec text, but if you (or someone you know) is interested in doing that part, then I'd be eager to help turn that into reality.

I would be.