| 00:34 | <jmdyck> | Those 4 BigInt ops are outside the table because they return completions. |
| 00:38 | <jmdyck> | Pulled out in https://github.com/tc39/ecma262/pull/2547 |
| 05:53 | <ljharb> | thanks, gotcha. it's a shame that we can't just do return ? operation() because of completion record reform :-) |
| 10:59 | <jmdyck> | I think we can. Like, I think step 6's body could have been "Let operation be <table>. Return ? operation(lNum, rNum)." I'm guessing 2547 didn't do it that way because the increase in DRYness wasn't worth the visual cost. |
| 11:05 | <jmdyck> | (I.e., completion record reform doesn't prevent return ? operation() in step 6, it just prevents combining step 6 + 7. I think.) |
| 13:58 | <Michael Ficarra> | oh I forgot that I'm on PTO next week, so I won't be at the Sept 11th editor call @shu |
| 14:48 | <shu> | ljharb: Michael Ficarra i didn't +1 https://github.com/tc39/ecma262/pull/3409's change to boolean |
| 14:48 | <shu> | you talked about it but i didn't think you were changing it for the PR |
| 14:49 | <shu> | i'd prefer the 2-state enum back |
| 14:49 | <Michael Ficarra> | oh I thought you were okay with it from your comments on the call |
| 14:49 | <Michael Ficarra> | yeah it's fine to put it back, I was fairly neutral about it |
| 14:49 | <shu> | no, i just didn't say anything while you were talking about it |
| 14:50 | <shu> | because i didn't get the sense you actually wanted to change it |
| 14:50 | <Michael Ficarra> | it seems that will obsolete https://github.com/tc39/ecma262/pull/3419 |
| 14:51 | <ljharb> | oh i thought you did in the call. want me to change it back to an enum? |
| 14:51 | <Michael Ficarra> | yeah to me it sounded like Jordan was positive about it and you and I were both neutral, so I just went with it |
| 14:51 | <shu> | yes |
| 14:52 | <ljharb> | I’ll add it into 3419 (if jmdyck doesn’t get to it first) |
| 14:52 | <shu> | oh i thought you did in the call. want me to change it back to an enum? |
| 14:59 | <bakkot> | I would be on board with changing almost all boolean parameters to enums tbh |
| 15:35 | <Michael Ficarra> | FYI @bakkot this came out of me remarking that this case is atypical in that a boolean is just as good as an enum |
| 15:35 | <Michael Ficarra> | or at least an enum with poorly chosen names |
| 15:35 | <Michael Ficarra> | if we did like no-validation and validate-as-property-keys, then the enum is better |
| 16:07 | <ljharb> | yeah generally i'd prefer an enum too, this case a boolean seemed like it'd help imply a third state wouldn't be accepted :-) |