| 02:17 | <sirisian> | I feel like the decorator proposal needs a giant section explaining why the metadata has like public/private sections and such. It's probably intuitive to the designers, but reading the proposal it's not. I saw: https://github.com/tc39/proposal-decorators/issues/427 which brings this up also tying the metadata to the property. |
| 16:00 | <Jack Works> | why AsyncFunction is not exposed to the global scope? |
| 17:11 | <ljharb> | good question. some things would be a lot easier if it were. |
| 17:21 | <Ashley Claymore> | which things? You've got me curious 🙂 The downsides to needing to do const AsyncFunction = Object.getPrototypeOf(async () => {}); are not immediately clear to me. |
| 17:29 | <Jack Works> | I searched for async await proposal repo, and didn't find a decision of this topic. |
| 17:29 | <Jack Works> | Is this intentional? For what reason? Security? Or just forgot in the spec? 🤔 |
| 17:30 | <Ashley Claymore> | Maybe following precedence of generators? |
| 17:30 | <Ashley Claymore> | maybe there was a conversation for that earlier proposal? |
| 17:31 | <Jack Works> | But generators comes from ES6, don't have a repo 🤔 |
| 17:31 | <Ashley Claymore> | ah yes of course! |
| 17:32 | <Ashley Claymore> | harder to search notes |
| 17:33 | <Ashley Claymore> | https://esdiscuss.org/topic/why-generatorfunction-constructor-isn-t-directly-exposed-to-end-users#content-1 |
| 17:34 | <Ashley Claymore> |
|
| 17:35 | <Jack Works> | Well.. it's proven to be useful. Can we have a proposal to add them now? 😂 |
| 17:36 | <bakkot> | what did you want it for? |
| 17:40 | <Jack Works> | Extending generator prototype |
| 18:17 | <ljharb> | it requires syntax, which means you can't support older engines that way without eval. also, it's harder to do SES stuff |
| 18:52 | <Ashley Claymore> | Thanks, makes sense |
| 18:54 | <Ashley Claymore> | Tangentially related, for future browsers with ShadowRealm. Would sr.evaluate(str) be allowed even if eval was blocked by CSP? |
| 19:00 | <bakkot> |
this seems like something few enough people want that it's not worth cluttering the global namespace |
| 19:14 | <Michael Ficarra> | also in the absence of a convenient way to build protocols (I know, I will work on it), probably something we want to discourage for now |
| 21:21 | <sirisian> | Is someone here an expert on decorator history. (Not sure if Garett is here). I have a side question related to how/if the decorator syntax could change if function overloading existed. https://github.com/sirisian/ecmascript-types/issues/59#issuecomment-1065517382 Specifically if the return (value, context) => {} syntax holds some special use cases. Like are there situations where one runs code before the return that has a meaningful purpose? I'm not familiar with when the function runs vs when the returned function is executed. Is that used for certain techniques? |