| 02:45 | <devsnek> | tfw first day of new job is the same day as tc39 |
| 03:09 | <rkirsling> | ouch |
| 03:25 | <devsnek> | if no one else wants to take the extends null item i'll move it to next meeting |
| 03:33 | <ljharb> | are the choices basically, 1) do nothing, let things suck; 2) allow `new class extends null {}` to work by making `super()` a noop when it'd be invoking `null`? or is there a third choice |
| 03:57 | <devsnek> | ljharb: 1) do nothing 2) super noop 3) remove extends null somehow |
| 03:57 | <devsnek> | maybe not compatible |
| 03:57 | <devsnek> | web compatible* |
| 04:02 | <ljharb> | how could we do that |
| 04:03 | <ljharb> | since i could do `let f = function () {}; class C extends f {} ; f = null; new C()` |
| 04:03 | <ljharb> | or do you mean a runtime error as part of construction |
| 04:03 | <devsnek> | idk |
| 04:03 | <devsnek> | i don't want to do that |
| 04:03 | <devsnek> | but its technically an option |
| 04:03 | <devsnek> | i'd like to lean on previous consensus here and actually figure out something that works though |
| 04:04 | <devsnek> | super noop seems ideal to me but there is a conflict |
| 04:04 | <devsnek> | some people say super() with extends null should throw, some say super(), if syntactically valid, should never throw |
| 04:05 | <ljharb> | i say the latter, and i'm aware of at least one person who says the former |
| 04:05 | <ljharb> | but the former pretty much guarantees extends null can never work |
| 04:05 | <devsnek> | yeah |
| 04:06 | <devsnek> | so i put a nice 30m chunk to discuss it |
| 04:09 | <devsnek> | fun issue that bradley just opened 😅 |
| 16:53 | <ljharb> | devsnek: looks like https://github.com/tc39/ecma262/pull/2216 now just needs to address 3 more small comments |