| 16:55 | <bakkot> | do we want to allow rest parameters in abstract closures? https://github.com/tc39/ecmarkup/issues/572 |
| 16:55 | <bakkot> | I guess I don't see any reason not to? |
| 17:18 | <shu> | ...i see no reason not to |
| 18:05 | <Michael Ficarra> | I'd say we already do |
| 18:18 | <bakkot> | abstract closures specifically, not AOs |
| 18:48 | <ljharb> | do we have any use cases in 262 rn that could take advantage of that? if not, i'd assume the only reason not to so far was "it hasn't come up" |
| 18:49 | <shu> | not that i'm aware of |
| 18:50 | <shu> | and yes i also assume only reason not to so far is because it hasn't come up |
| 18:50 | <shu> | i mean it's just implicit list creation, could always do it at the callsite |
| 18:53 | <Michael Ficarra> | that paragraph makes no distinction between parameter lists of AOs and parameter lists of ACs |
| 18:54 | <Michael Ficarra> | so to me it sounds like we're just missing tooling support |
| 18:54 | <jmdyck> | Seems like unnecessary complication to me. |
| 18:55 | <shu> | as in you'd prefer to do the manual List creation at the callsites, jmdyck? |
| 18:55 | <jmdyck> | yup. |
| 18:59 | <Michael Ficarra> | I'd say it's not motivated enough to add if we didn't already have it, but since we already have it, I'm fine using it in ACs |
| 19:05 | <jmdyck> | In what sense do we already have it? |
| 19:09 | <jmdyck> | Currently, ... is only used in the definition of built-in functions. |
| 19:10 | <Michael Ficarra> | see my screenshot above |
| 19:10 | <Michael Ficarra> | I read that as parameter lists, anywhere, support the ellipsis notation |
| 19:11 | <Michael Ficarra> | and, as a reader, if I saw it used somewhere, and I found the above explanation, I would consider it to apply |
| 19:21 | <jmdyck> | so we have it in the sense of a sentence that appears to license the use in any parameter list, but we don't have it in the sense of actual use in AOs/SDOs/ACs. We know that ecmarkup doesn't support it in ACs, does it support it in AOs/SDOs? |
| 19:22 | <jmdyck> | The same para also licences optional params in all param lists, and we do use those in AOs, but I seem to recall some sentiment that we'd be better off avoiding them in AOs. |
| 19:25 | <jmdyck> | And if you create an AC with a rest param and then pass it to CreateBuiltinFunction, that isn't handled by the phrase "using the provided arguments as the values of the corresponding parameters". |
| 21:00 | <Michael Ficarra> | the sentence "using the provided arguments as the values of the corresponding parameters" doesn't need to be generic, it just has to be coherent for all existing uses in the spec |
| 21:00 | <Michael Ficarra> | so if we want to pass such an AC to CreateBuiltinFunction, we'd need to update that sentence, but not before then |
| 21:16 | <jmdyck> | Yup, but passing such an AC to CBF is exactly what legendecas wants to do, so it's not like it's a hypothetical future problem. |
| 21:23 | <Michael Ficarra> | ah, fair |
| 21:57 | <jmdyck> | On second thought, I think that rest params are unnecessary complication for AOs/ACs that are explicitly invoked in the spec. But if you want to algorithmically ('dynamically') create a builtin function that accepts (and uses) an arbitrary number of args, then I think you kind of have to pass an AO/AC with a rest param to CBF. (You could maybe fudge it some other way, but I think it would be messy.) |
| 21:59 | <jmdyck> | (Currently, the spec's varargs builtins are all created elliptically in CreateIntrinsics, so it doesn't come up.) |