TC39 Delegates on 2023-09-25

00:46	<bakkot>	I do not love the thing where the agenda is structurally set up so that proposals are higher priority than larger discussions
00:46	<bakkot>	seems like it ought to be the other way around
02:02	<littledan>	well, overflow from last meeting is highest priority, so you can always get a time slice for discussions, just every two meetings
02:03	<littledan>	also if a discussion should block a proposal, it can always be bumped up (on a case by case basis)
02:06	<littledan>	historically, we adopted this prioritization back when we were trying to get out of the pattern of spending all day on some very circular philosophical discussions which should not have blocked proposals
02:24	<littledan>	if there's a particular discussion that we should prioritize, maybe note that in schedule constraints?
02:25	<littledan>	(personally, when I've put discussions on the agenda in the past, I actually wanted them to be deprioritized generally)
02:26	<littledan>	I was thinking about the old `.{` operator recently, in terms of how it could potentially be used for extraction and injection as an RCU (read/copy, update) mechanism in the shared structs proposal (or possibly as a follow on). I started tinkering with various ideas for the syntax, and while I have something fairly consistent in mind, I came across a wart related to spread and rest assignments in destructuring syntax: `a = { ...b }; // spread properties of 'b' ({ ...x } = y); // take the rest of the properties and put them in 'x'` One of the ideas I had for `.{` was doing named spread/rest in extraction/injection, in which you would want extraction and injection to be mirrored, and you could either use spread or rest in either operator: `b = a.{ x, ...y }; // pick 'x' as 'x', and pick up the rest as 'y' b = a.{ x, y... }; // pick 'x' as 'x', and spread out 'y' a.{ x, ...y } = b; // assign 'x' from 'x', and take up the rest as 'y' a.{ x, y... } = b; // assign 'x' from 'x', and spread out 'y'` Which makes me wonder if spread should have been written as `foo...` This is definitely interesting, but also makes me a little scared about whether or not people will be able to understand it well
02:27	<rbuckton>	It's less that I would propose the more complex bits initially (if at all), but that I wanted to explore the syntax fully to make sure it remained consistent.
05:10	<littledan>	Rob and I are about to do an AV test in a few minutes. If you want to help out, DM me and I will respond with a Zoom link
06:11	<bakkot>	if there's a particular discussion that we should prioritize, maybe note that in schedule constraints? well, concretely, I would like to get to the Stop Coercing Things discussion, since it affects the design of all future proposals
06:11	<bakkot>	And since we started but did not finish the discussion last meeting
06:12	<littledan>	I'm fine with deprioritizing my various "withdraw" topics; they can wait until next meeting
06:12	<bakkot>	But I do not have any related schedule constraints
06:16	<littledan>	I think "I want this to happen this meeting rather than a future meeting" is a constraint you're expressing about the schedule... anyway if you don't think this prioritization is a good fit for one section to document the need, maybe you can document it in a new part of the agenda
06:17	<littledan>	I want to discuss your topic but ultimately there are going to be a lot of different points of view people have about why their topic should be prioritized; if these are all collected in one place, then it will be easier for the chairs to go and solve as many for as many prioritization inputs as possible.
08:32	<Michael Ficarra>	bakkot: You can always jump to the higher-priority "shorter discussions" section by selecting a 30-minute or less time box
08:33	<Michael Ficarra>	we designed the agenda like this on purpose and I like it how it is
19:38	<TabAtkins>	...I'm reading the Temporal docs, and in the `round()` method they say: When there is a tie, round away from zero like ceil for positive durations and like floor for negative durations. This is the default, and matches the behaviour of Math.round(). But `Math.round()`, uh, doesn't do that. `Math.round(-1.5)` is -1; it ciels on the half values.
19:39	<TabAtkins>	(I was very confused when I read that because I was pretty sure I specified CSS to use ceil semantics on the halves by default, and I did so because that was JS's behavior. And indeed: https://drafts.csswg.org/css-values/#round-func)
19:40	<TabAtkins>	https://tc39.es/proposal-temporal/docs/duration.html#round for the Temporal docs reference, scroll down a bit to get to the rounding modes
19:44	<ptomato>	waaaaat
19:44	<Kamil Ogórek>	I think this is mostly wording issue from my understanding. `Math.round(-1.5)` performs "floor-like" operation in a sense that it rounds to the nearest "bottom" value. It's not taking the sign into account in the explanation here though.
19:45	<Kamil Ogórek>	Obviously -2 is "bottom" for -1.5, but it's 1 for "not signed" -1.5
19:46	<ptomato>	I guess Tab is saying that the behaviour of `Math.round` corresponds to `halfCeil` and not `halfExpand`?
19:46	<ptomato>	(to use the rounding mode terminology)
19:50	<Kamil Ogórek>	It looks exactly like that. It always rounds towards +Infinity, for both, positives and negatives now
19:55	<ptomato>	I think Intl.NumberFormat has a default rounding mode of halfExpand too, with this same rationale. I'm not sure which came first, whether Temporal based its default on NumberFormat, or the mistaken belief that Math.round corresponds to halfExpand
20:48	<TabAtkins>	Yes, `Math.round()` defaults to `halfCeil` behavior, not `halfExpand` as the Temporal docs state.
20:49	<TabAtkins>	I don't think it's a misunderstanding on my reading - the docs are pretty explicit about the behavior. They're just wrong about it being "like `Math.round()`", which might be something that they want to fix.
20:50	<TabAtkins>	(Either in the docs, because `halfExpand` is desirable as the default, or in the spec, because `halfCeil` is the actual default behavior in `Math.round()`.)
21:14	<Kamil Ogórek>	I didnt mean to say you read it wrong, but rather that maybe person who wrote it used too much of a mental shortcut, which led to a real mistake :)