09:01
<yulia>
moving structured clone sounds like a great idea
09:51
<littledan>
moving structured clone sounds like a great idea
I like this idea too. Others opposed it historically, e.g., Mark has expressed opposition recently. I think it would be a complicated negotiation.
15:47
<Domenic>
I mainly just want to stop being on the hook for updating structured clone with new error types/builtins
15:47
<Domenic>
Like temporal objects are just not going to be structured cloneable I guess because I don't have the time to work on that
15:47
<Domenic>
An alternative would be if structured clone was explicitly remembered as a stage 3 cross-cutting concern criteria
16:00
<ptomato>
Domenic: I don't think you are on the hook for structured clone for Temporal objects? it was identified as a concern and there is a pull request for it: https://github.com/tc39/proposal-temporal/issues/548 / https://github.com/whatwg/html/pull/6284
16:01
<Jack Works>
https://github.com/Jack-Works/proposal-serializer
16:01
<Jack Works>
does anyone interested?
16:01
<Jack Works>
this is my try on the bringing user-extensible structured clone in to the language
16:03
<Domenic>
Domenic: I don't think you are on the hook for structured clone for Temporal objects? it was identified as a concern and there is a pull request for it: https://github.com/tc39/proposal-temporal/issues/548 / https://github.com/whatwg/html/pull/6284
Oh wow, somehow I totally missed that! Sorry, that's my bad. I was assuming the unfortunate precedent set by AggregateError/error.cause would carry over for temporal, but you did the right thing.
16:07
<littledan>
we haven't written the PR for Record and Tuple structured clone, but it's definitely on our todo list https://github.com/tc39/proposal-record-tuple/issues/45
16:08
<littledan>
Being friendly to contributors is a great way to encourage more involvement and avoid maintainer burnout
16:11
<littledan>
Oh wow, somehow I totally missed that! Sorry, that's my bad. I was assuming the unfortunate precedent set by AggregateError/error.cause would carry over for temporal, but you did the right thing.
I don't think there's any particular precedent here; TC39 delegates have been doing a lot of the HTML integration work for recent proposals.
16:13
<littledan>
We're talking about the process for host integration in TC39 proposals at https://github.com/tc39/Reflector/issues/375 (sorry, delegates/IEs only)
16:31
<bakkot>

I like this idea too. Others opposed it historically, e.g., Mark has expressed opposition recently. I think it would be a complicated negotiation.

shu suggested we might move the algorithm without exposing it directly in 262, at least initially, so it would just be a matter of making it the 262 editors' responsibility to handle ongoing maintenance for the JS parts of it; my hope was that this would alleviate Mark's concerns

16:45
<shu>
yes, the high order bit is to decouple any normative changes to JS wrt structured clone
17:20
<Domenic>
Aww https://github.com/tc39/notes/blob/master/meetings/2020-06/june-4.md#generic-comparison is sad, I didn't realize the spaceship operator worked so poorly in JavaScript. I really like it as a unifying concept.