| 08:54 | <littledan> | I'd be happy to run the meeting on the 18th while Shu is absent. We can chat about capabilities and the module registry then, working it out together as a group. I really like Mark's thoughts around that. I think Nicolo also has some thoughts. |
| 18:19 | <Mathieu Hofman> | We probably also should close the loop on the Matrix discussion above about coloring of unsafe functions, and how Atomics/Reflect APIs should work with shared object in unsafe contexts |
| 20:34 | <littledan> | We probably also should close the loop on the Matrix discussion above about coloring of unsafe functions, and how Atomics/Reflect APIs should work with shared object in unsafe contexts |
| 20:34 | <littledan> | I thought we all agreed, no coloring |
| 20:35 | <littledan> | (Not sure how Atomics or Reflect should work, though) |
| 21:47 | <Mathieu Hofman> | I think we all agreed no function coloring for now, but multiple of us expressed we wanted to leave the option open for the future. If we make Atomics and Reflect behave differently in unsafe vs safe contexts, function coloring could explain that. |
| 22:53 | <rbuckton> | Though we don't necessarily need to justify special behavior for builtins, but coloring could explain that later, if we decided to extend it elsewhere in the language |
| 22:54 | <rbuckton> | Also, while I'd like a better DX for unsafe function bodies, I can live with that coming later in a follow on. |
| 22:57 | <rbuckton> | But both Atomics and Reflect need to work, whether that is magically or blindly. |