| 06:38 | <sirisian> | I know this is a very very old topic. Whatever happened to const parameters? function f(const a){}. I might need that as an assumption to one of my ideas, but was it not possible? It seems straightforward, but I feel like I'm missing some technical issue perhaps that stopped it from being put in when const was. |
| 06:39 | <Jack Works> | I sometimes like it, but it really isn't easy to encourage people to use it. |
| 15:46 | <jmdyck> | It's been 2 weeks since the TC39 meeting, time for Notes to be published? |
| 18:49 | <nicolo-ribaudo> | Question about Annex B.3.4 (https://tc39.es/ecma262/#sec-variablestatements-in-catch-blocks): Why does the text before the note only modify |
| 19:15 | <littledan> | sorry can you use a content warning for such questions? |
| 19:16 | <nicolo-ribaudo> | I was seriously considering doing it 😬 |
| 19:19 | <shu> | i don't understand the question |
| 19:23 | <shu> | oh i think maybe i understand the question |
| 19:24 | <nicolo-ribaudo> | Is that section only changing the semantics for function declarations in eval, or also outside of eval? |
| 19:26 | <shu> | i think in practice it's for both |
| 19:26 | <shu> | wouldn't function declarations outside of direct evals already be covered by LexicallyDeclaredNames? |
| 19:27 | <shu> | but function declarations inside direct evals need special handling because top-level function declarations in direct evals only introduce var bindings in the outside scope in B.3.2 semantics anyway... or something like that? |
| 19:30 | <nicolo-ribaudo> | Oh because 11.b of functions in eval ("If replacing the FunctionDeclaration f with a VariableStatement that has F as a BindingIdentifier would not produce any Early Errors for body, then") never produces an early error, so it's different from non-eval functions... |
| 19:30 | <nicolo-ribaudo> | Thank you! |
| 19:32 | <bakkot> | the fact that b.3.2 (formerly b.3.3) semantics are specified with "as if" has caused no end of pain |
| 19:32 | <shu> | i still have a big bone to pick with specifying any semantics as counterfactuals |
| 19:32 | <shu> | terribly confusing |
| 19:32 | <bakkot> | in both chrome and FF (but not JSC) try {} catch (e) { function e(){} } is in fact an error |
| 19:32 | <bakkot> | and I am genuinely unclear on whether that's correct per spec |
| 19:33 | <shu> | i think the spirit of it is correct |
| 19:33 | <shu> | anyways i hope for safari to 1) grow its market share a lot and 2) never implement annex B FiB semantics correctly |
| 19:34 | <shu> | in a few years we rip it out |
| 19:34 | <bakkot> | I guess it's correct because of the "also occurs in the LexicallyDeclaredNames of Block." rule actually, yeah |
| 19:34 | <bakkot> | it's an error not because of the synthetic b.3.2 var binding but because of the normal lexically scoped binding |
| 19:34 | <shu> | yes |
| 19:35 | <shu> | we should ask if ESMeta folks model the Annex B counterfactuals |
| 19:35 | <shu> | first, develop a possible-worlds interpretation of the universe according to ecma262 |
| 19:37 | <bakkot> | if anyone who has not yet burned out their entire brain thinking about this stuff would like to do so, https://github.com/tc39/ecma262/issues/2019 and https://github.com/tc39/ecma262/issues/913 are still open I think |
| 19:39 | <shu> | i recommend that if you are not already an annex B FiB abyss gazer, please do not start |
| 19:39 | <shu> | go play video games or anything really |
| 19:39 | <nicolo-ribaudo> | Go play outside |
| 20:50 | <jmdyck> | shu: ISTR that esmeta ignores Annex B. (Can't find an explicit statement to that effect though.) |