| 02:01 | <jridgewell> | That seems like a bug, honestly. |
| 02:02 | <ljharb> | i remember a bit of discussion on it as an intentional decision |
| 02:41 | <jridgewell> | Seems its https://github.com/tc39/proposal-async-iteration/pull/102 |
| 02:41 | <jridgewell> | With relevant slides at https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.p |
| 03:32 | <jridgewell> | This should be changeable |
| 03:33 | <jridgewell> | Justification slides at 8 and 9: https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_207 |
| 03:33 | <jridgewell> | These don't apply to `return Promise.reject()`, since any finalization would be able to run. |
| 03:34 | <jridgewell> | So it'd be a normal completion |
| 03:34 | <jridgewell> | We only need to ensure that the rejection is unwrapped before the iterator object settles |
| 06:06 | <towc> | are there any plans for named parameters in JS, handled like python would? I really dislike passing objects around when I don't have to, and when some parameters have no defaults |
| 06:07 | <ljharb> | unlikely. why do you dislike it? |
| 06:08 | <towc> | e.g.: `const add = (a, b, nanAsZero = false, undefinedAsZero = false) => ...; add(1, 2); add(1, 2, undefinedAsZero: true); add(1, 2, nanAsZero: true);` |
| 06:10 | <towc> | if I wanted optional named arguments, I'd have to do something like this: `const add = (opts = {}) => { const {a, b, nanAsZero = false, undefinedAsZero = false} = opts; ... }; add({a: 1, b: 2}); add({a: 1, b: 2, undefinedAsZero: true}); ...` |
| 06:10 | <ljharb> | i mean, you'd do `({ a, b, etc } = {})` but sure |
| 06:10 | <ljharb> | ie, you'd destructure inline |
| 06:11 | <ljharb> | also generally i'd say you want the required params to be positional |
| 06:11 | <towc> | or this, which I think is worse: `const add = (a, b, opts = {}) => ...; add(1, 2); add(1, 2, {undefinedAsZero: true}); ...` |
| 06:12 | <ljharb> | why is that worse? |
| 06:12 | <towc> | the signature is unnecessarily complicated |
| 06:12 | <ljharb> | it's extra curly braces |
| 06:12 | <ljharb> | how is that more complicated than adding an entirely new syntax |
| 06:14 | <towc> | I'm not sure, it feels like extra cognitive load, and acts as an obstacle to writing clean functions |
| 06:15 | <ljharb> | "clean" is very subjective |
| 06:15 | <ljharb> | from my perspective, kwargs would be less clean, and is extra cognitive load. object destructuring and defaults are cognitive load i already have to bear, since it's part of the language |
| 06:17 | <towc> | I'd like to write functions with object-named parameters, but then I'm worried the code users will be discouraged from writing the extra `{}` on the function call, and I start (unnecessarily) worrying about object memoization |
| 06:17 | <Bakkot> | towc: generally there's a pretty high bar for new syntax. it needs to make something very common significantly easier, or something which is effectively impossible possible. adding additional syntax for named parameters is just syntax sugar, so it would have to meet the "something very common significantly easier" bar, and my feeling is that it does not. using object destructuring is not significantly harder than named parameters |
| 06:17 | <Bakkot> | would be. |
| 06:17 | <ljharb> | considering that's how a very large amount of the js ecosystem already does it, i don't think it will discourage anybody |
| 06:19 | <Bakkot> | (also, yeah, agreed with ljharb: destructuring-as-named-params is common practice in JS these days, so I don't think you should worry about users not being comfortable with the `{}`.) |
| 06:20 | <towc> | an interesting application would be to add names of the positional paremeters you're targeting, in function calls, which python allows. This would make dealing with older APIs much easier, without needing to modernize those APIs, and keeping everything backwards-compatible |
| 06:21 | <towc> | in python, you can do `def fn(a, b): ...; fn(b=1, a=2)` |
| 06:21 | <towc> | naming positional parameters, even if keeping the same order, could add a lot of optional clarity to user code |
| 06:22 | <ljharb> | that example is already valid syntax (it creates a global variable) |
| 06:22 | <ljharb> | i think it would work with the colons, but then it falls to the "high bar" Bakkot referenced |
| 06:22 | <towc> | well, in js using `=`, sure, but we could have `const fn = (a, b) => ...; fn(b: 1, a: 2)` |
| 06:23 | <devsnek> | sometimes i do wish we could name parameters like that |
| 06:23 | <towc> | I think it's worth thinking about, but thank you for your time :) |
| 06:23 | <Bakkot> | apart from everything else, it is common practice for build tools in javascript to change variable names, which means if we added this to existing functions in a non-opt-in manner it would mean substantially every build process would be breaking its input, which seems... bad |
| 06:23 | <devsnek> | but i don't think overall it is worth it |
| 06:24 | <towc> | oh, good point |
| 06:24 | <towc> | seems more like a feature for typescript than js |
| 06:24 | <Bakkot> | TS does not intend to add non-type features, so they're probably not interested |
| 06:24 | <ljharb> | p sure TS won't add any new non-type-related features |
| 06:24 | <Bakkot> | you could write a babel plugin for it though! |
| 06:25 | <Bakkot> | wouldn't be too tricky I expect |
| 06:25 | <Sirisian> | heh, when writing my type proposal I had a few people ask me about named parameters. Haven't thought about them in a while. I even added an example to show I wasn't conflicting with desired syntax. |
| 06:25 | <Bakkot> | (I don't really recommend it, since it would make other people picking up your codebases harder, but it's a possibility depending on your priorities) |
| 06:26 | <devsnek> | well they say that |
| 06:26 | <devsnek> | oh i got scroll'd |
| 06:26 | <towc> | yeah, I think I'll just need to stick to obscure positional parameter names, because that's what the teams I've worked on have been doing, forever |
| 06:26 | <devsnek> | now if we had monads |
| 06:27 | <devsnek> | you could just safely and functionally get the arguments |
| 06:27 | <towc> | s/positional parameter names/positional parameters/ |
| 06:28 | <towc> | alright, thanks all, I'll be back with another failed idea in a few months, I'm sure :) |
| 06:28 | <devsnek> | keep 'em coming |
| 06:28 | <devsnek> | oh they quit |
| 06:31 | <Sirisian> | https://github.com/sirisian/ecmascript-types#named-arguments I think this is the example I saw a few times. Functions with lots of defaults. |
| 06:32 | <Bakkot> | I don't think you should really worry about it |
| 06:32 | <Sirisian> | yeah, I told other people it's so low priority it's not worth it. |
| 06:33 | <Bakkot> | destructuring is in all likelihood the only thing we will have for named parameters forever |
| 06:33 | <Sirisian> | Indeed |
| 06:35 | <devsnek> | you could also just use global variables |
| 06:35 | <devsnek> | `f(a=1)` and check the value of `globalThis.a` in `f` |
| 06:35 | <ljharb> | lol |
| 06:36 | <Sirisian> | Creative. |
| 06:38 | <Bakkot> | or just introduce a new calling convention: `with (f.args) f(a = 1, b = 2)`, where `f.args` is a proxy which emulates f's parameters |
| 06:38 | <Bakkot> | (don't even need a proxy I guess, come to think) |
| 06:39 | <devsnek> | i love it |
| 16:59 | <bradleymeck> | Bring back zones, but one per fn call |