TC39 Delegates on 2022-03-23

07:44	<Jesse>	I strongly suspect there's a number of remaining cases where there's a `!` which should be a `?` might be a dumb question, but why do we even annotate uses of AOs with `?` and `!`? If the AO is fallible, then probably every use of it should be flagged with `?`. Flagging a use of a fallible AO with `!`, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail. If an AO is, on the other hand, infallible, then every use of it should be marked with `!`. Marking a use of an infallible AO with `?` would be an editorial mistake, and flagging the use as `!` would be redundant. So the only informative case I can see is (1) fallible AO, (2) used in an infallible way
08:16	<annevk>	Historically at least the ? took care of unwrapping the return value, but I'm not really sure what the state of play is these days as there has been some refactoring
11:32	<Ashley Claymore>	Flagging a use of a fallible AO with !, to be meaningful, would require a proof that the use of the AO in that case (or cases) can never fail While I like the ~~rigidity~~<ins>safety</ins> of having a proof with each assertion in the spec, that sounds easier said than done. Maybe one day, as the spec becomes more and more machine understandable? I do think there is still value in the assertions, when reading the spec I have found it very helpful to immediately see that we believe a certain AO call will not fail. But yes this is done on trust of the spec authors
11:48	<annevk>	It's not like removing the assertions would magically make it more correct either. 🙂
13:34	<bakkot>	Jesse: turns out there are a lot of places where there is a fallible AO used in an infallible way
13:34	<bakkot>	that is, in fact, every use of `!` in the spec now
13:34	<bakkot>	(infallible AOs are not called with either `?` or `!`)
14:52	<Richard Gibson>	or, I should say the non-throwy-ness sounds right; I haven't looked for how it might be `undefined` I came back to this today, and the only use of GetSuperBase() (step 3 of MakeSuperPropertyReference) is immediately preceded by an "env.HasSuperBinding() is true" assertion, which confirms that [[HomeObject]] is not undefined (the only location I found where it could be is prevented by step 10.f of PerformEval; all others seem to be prevented by "… Contains \|SuperProperty\|" early errors). So GetSuperBase step 2 can be removed, and there is arbitrary flexibility between it and MakeSuperPropertyReference.
15:53	<Rob Palmer>	Reminder: There is a request for feedback on the Reflector for the upcoming real-life June plenary in Austin as part of OpenJS World conference. Please respond by Friday 25 March. https://github.com/tc39/Reflector/issues/423