2020-05-01 [07:51:52.0000] Hi everyone - I'm curious about https://tc39.es/ecma262/#sec-script-semantics-runtime-semantics-evaluation Step 15 [07:52:48.0000] Anyone know why it's like that? [08:07:46.0000] jorendorff: i think you mislinked w/e you wanted to show [08:08:00.0000] darn [08:08:18.0000] Thanks, I meant https://tc39.es/ecma262/#sec-runtime-semantics-scriptevaluation [08:36:37.0000] jorendorff: why it asserts that the stack is not empty? [08:36:45.0000] Yes [08:37:01.0000] because the context from realm init should be on the stack [08:38:34.0000] What is "realm init"? [08:41:54.0000] InitializeHostDefinedRealm creates an execution context and pushes it onto the stack [09:14:19.0000] huh. ok, and another spec, like the HTML spec, can pop that execution context and keep it around? [09:14:50.0000] is it ever actually used? [09:15:10.0000] it's weird because it seems like we should've asserted that on entry [09:15:21.0000] but also because I don't understand what this is for [09:21:40.0000] https://github.com/tc39/ecma262/pull/1597#discussion_r296465769 may help [13:41:33.0000] That is helpful. [14:00:31.0000] why do we have tests that allow ID_Continue characters as the start of IdentifierName [14:00:55.0000] mathiasbynens: ^ [14:00:57.0000] presumably they are also ID_start? [14:01:12.0000] they are not [14:01:23.0000] link the test? [14:01:29.0000] language/identifiers/part-unicode-9.0.0.js [14:11:28.0000] that looks like a bug, yeah [14:13:06.0000] no wawit [14:13:09.0000] it's just hard to read [14:13:22.0000] it starts with `_` [14:13:57.0000] hmmm [14:14:30.0000] i guess that's why it wasn't matching ID_Start [14:15:44.0000] the message in the test is wrong though [15:13:31.0000] CreateDynamicFunction lists a bunch of conditions to throw syntax errors for [15:13:49.0000] but i'm thinking that maybe step 20.d covers all of them [15:16:25.0000] the supercall one at least is not, because it's an error for full functions, not for either parameters or the body [15:16:36.0000] my guess is that this is true for the others, without having looked [15:20:45.0000] oh hm [15:20:48.0000] that's kind of annoying 2020-05-02 [22:27:22.0000] I was going to ask this years ago, but is Andreas Rossberg in this channel? Is he still part of TC39? He's on this list: https://github.com/orgs/tc39/people [10:22:22.0000] Hi all, could someone point me to the spec diff tool again? [10:25:26.0000] ryzokuken: https://arai-a.github.io/ecma262-compare/ [10:26:04.0000] Bakkot: precisely what I was looking for! Thanks a ton. [10:27:09.0000] but also, oof. It won't work for ECMA 402 😭 2020-05-03 [14:30:09.0000] Bakkot: is the idea behind the early error checker in shift parser that its like array.reduce except an ast instead [14:32:10.0000] that is the idea behind reducers in general, yes [14:33:16.0000] you can never be too sure when the word monad comes into play [14:33:59.0000] do we actually talk about monads? [14:34:08.0000] I know we talk about monoids but those are less esoteric [14:36:15.0000] ah you're right it says MonoidalReducer not MonadalReducer [14:36:55.0000] yeah [14:37:29.0000] *monadic [14:38:27.0000] i'm trying to figure out how i want to do early errors in my parser [14:38:42.0000] the main issue so far is that every parse function is an entry point 2020-05-04 [22:08:47.0000] surprisingly useful https://gc.gy/56273905.png [22:09:53.0000] devsnek: tbh that `.spec` thing seems like it'd be a pretty handy standalone npm package [22:10:03.0000] well its not magic [22:10:19.0000] it uses the `// #sec-xyz` comment above every function in engine262's source [22:10:24.0000] ah ok [22:10:30.0000] i agree though [22:10:38.0000] i wanted to add something similar in node's repl [22:10:47.0000] for js stuff and node stuff [22:10:58.0000] though it would've been mdn not the spec in that case [22:14:54.0000] i'd want it for the spec :-p [22:30:08.0000] new proposal? :D [22:30:14.0000] the ultimate reflection mechanism [22:30:43.0000] actually I guess to qualify as "ultimate" it would also need to include an interpreter for spec-ese [22:31:12.0000] Array.prototype.flat.__doc [22:33:01.0000] `Set.prototype.add = spec.evaluate(spec(Set.prototype.add).replace('If value is -0, set value to +0', 'If false'))` [22:37:15.0000] oh gosh [06:58:54.0000] littledan, I was looking at the operator overloading proposal. Would it be fair to say a lot of the complexity in the proposed syntax is due to a lack of function overloading? I understand it's stage 1. [06:59:38.0000] I don't understand how function overloading would relate to it. it's true that the proposal's contents are largely about the dispatch semantics. [07:00:04.0000] I don't think you'd want function overloading to behave with the restrictions that operator overloading is defined to have [07:00:36.0000] The static kind of design? [07:01:16.0000] (I'm not fully clear on the implementation specifics, was just reading the issues). [07:18:59.0000] Would it be insane to use a TS-like syntax https://github.com/sirisian/ecmascript-types#classes-and-operator-overloading I'm not really clear on the big picture of what slows things down in V8 and such in regards to operator overloading. Is it being able to define new operators on individual instances that would require lookups and be unworkable? So the operators must be on global class types and all or nothing for all instances? [07:20:15.0000] (Also I realize that Symbol doesn't work. I added that a while ago when someone suggested it. Apparently that's a bad idea). [08:32:29.0000] Bakkot: so `spec.evaluate(str)` would return a function object that, when called, performs the algorithm steps in `str`? [08:32:48.0000] that would be the idea! [08:32:55.0000] (to be clear this is not a serious proposal) [08:37:39.0000] yeah, it didn't sound entirely serious. Still, I think it'd be possible. [08:51:37.0000] Bakkot: i'd feel more comfortable with a spec.evaluate if we first sat down and worked through the meta-machinery [08:52:49.0000] ecma261.5, the ecma262 metalanguage [08:53:55.0000] working on it [08:54:09.0000] michael ficarra and I have a preliminary linter integrated with ecmarkup [08:54:28.0000] so we can start enforcing stuff like "variables are defined before use" and so no [08:54:54.0000] i'm interested in what the linter thinks about lets-in-branches [08:55:16.0000] (that rule isn't implemented yet, to be clear, but should be pretty straightforward) [08:55:30.0000] i'm interested in the policy question [08:56:00.0000] for now I'd want to start with allowing them, since they're in the current spec [08:56:13.0000] and if we eliminate them we can update the linter to enforce that [08:56:27.0000] I don't actually mind them much though [08:56:34.0000] yeah i like them tbh [08:56:53.0000] at least the fairly structured version where two branches both introduce the same alias [08:57:45.0000] I think there might be a place or two where there's a "If Foo let X be *" without a corresponding else, and later usages of X also guarded on Foo [09:04:51.0000] that also seems fine to me [09:04:59.0000] and could be checked by the linter with sufficient sophistication [09:30:44.0000] littledan: I had an idea about operator overloaded where you try to make it as scoped as possible [09:30:59.0000] devsnek: Yes? [09:31:13.0000] sort of like `let x = with operator xyz { a + b }` [09:31:30.0000] this lets it be fairly dynamic [09:32:05.0000] you can put as much in the block as you want but overloaded operations tend to happen in clumps so they should stay fairly small [09:33:03.0000] devsnek: Would that be a do expression? [09:33:13.0000] it could be, yes [09:33:24.0000] (I mean, what were you picturing? what else would it be?) [09:33:28.0000] I haven't formalized this idea that much [09:33:46.0000] if we have do expressions it would make sense to (ab)use them here [09:33:59.0000] I mean, to me, curly brackets with code in them feel like they should have statements in them [09:34:11.0000] if it's an expression, I'd imagine parentheses [09:34:13.0000] a + b is an expression statement [09:34:16.0000] right [09:34:29.0000] so yeah it uses completion [09:34:30.0000] so, it'd work as a do expression [09:34:53.0000] if we're OK with using completion values, that'd be fine. I guess no one has driven this to Stage 2, but it seemed like dherman made good progress last time it was discussed [09:35:00.0000] but anyway since it encourages small scoping, you can make the protocol more dynamic [09:35:17.0000] hmm, I don't think I follow that part [09:35:30.0000] I think we need to be static just for the integrity goals anyway [09:35:38.0000] since you're only paying for dynamic behaviour inside the block [09:36:27.0000] "paying for" makes sense when thinking about performance cost, but the integrity things are sort of considered serious either way. The intention isn't that you're opting into chaos mode, but rather into something contained [09:36:49.0000] integrity? [09:37:16.0000] see "predictability" in https://github.com/tc39/proposal-operator-overloading/blob/master/README.md#design-goals [09:37:40.0000] hm I think I feel exactly the opposite [09:37:47.0000] hmm how so? [09:37:50.0000] they should be dynamic and changeable imo [09:37:56.0000] why? [09:38:03.0000] more javascripty I guess [09:38:08.0000] that's why I like this language [09:38:10.0000] lots of people have told me specifically, operator overloading shouldn't happen in JS because then it'd be too dynamic and changeable [09:38:22.0000] so, I was trying to respond to that and find something contained [09:38:38.0000] all I've heard is that dynamic shouldn't happen because of performance [09:39:19.0000] so, I guess I've been a little sloppy about keeping quotes around, but I've personally heard more concerns than just that [09:39:28.0000] fair enough [09:39:29.0000] let me see what I can dig up [09:39:35.0000] I really don't like the static stuff though [09:39:54.0000] I mean, for example, ljharb at the last TC39 meeting was saying operator overloading would make JS more confusing, wasn't he? [09:40:17.0000] I think that's mostly about wide scoping of the overloads [09:40:30.0000] if you have these narrow scopes it's very obvious when it happens [09:40:40.0000] although you still have the issue of forgetting to scope [09:40:56.0000] you could also look at the responses here: https://twitter.com/littledan/status/1024958066066898944 [09:41:42.0000] so, i was specifically trying to defend against certain "attacks" against integrity in this proposal. Probably I didn't do a good enough job explaining this in the repo, since people keep asking me the same questions about making more dynamic [09:41:49.0000] so that's something for me to work on [09:42:57.0000] I think operator overloading works better when it's by intention instead of by operator [09:43:17.0000] like how in rust you implement deref, not the star operator [09:43:46.0000] I think people saying "operator overloading is bad" tend along that pathway [09:44:35.0000] hmm, do you have ideas for what that would mean concretely, given the operators we have in JS? [09:46:27.0000] I don't know if I have a concrete answer [09:49:28.0000] it occurs to me that people use macros for this in rust, which is almost like my scoping idea [09:49:47.0000] let x = vec_ops! { a + b } [09:52:08.0000] yeah, I think that's a good thing to look into, but at the same time, I feel like it's appropriate that the operator overloading proposal uses "+" to identify overloading things like a+b [09:52:35.0000] and, I don't think this has to do with the responses to my tweet, which were half about operator overloading making all JS code opaque and confusing [09:52:50.0000] so the concern was on the usage side, not the definition side [09:53:23.0000] yeah that's what I mentioned above, with small scopes making it clearer where this happens [09:53:46.0000] Sirisian: If we can think of a more intuitive, TS-like syntax, then I'd be all for using it. I was thinking about using decorators somehow, but I was also thinking about avoiding the dependency [09:53:54.0000] of course if scopes are involved you run into the problem of forgetting to use one [09:54:10.0000] rbuckton has some ideas about nicer syntax too, but I can't figure out how the details would fit together [09:55:35.0000] could also use some modified operator form [09:56:01.0000] a @X+ b to add a and b together using X's rules [09:56:29.0000] littledan, Do you still work on V8? Was curious. [09:56:42.0000] not really, but my coworkers in Igalia do [09:57:03.0000] i think you've still got some TODO comments in v8 [09:57:06.0000] devsnek: That wouldn't meet the goals of letting us generalize BigInt and Decimal [09:57:11.0000] yeah, I think I left a lot there... [09:57:24.0000] I codesearched myself the other day and yeah [09:57:29.0000] sorry [09:57:31.0000] 1n @BigInt+ 1n [09:57:41.0000] lol you're definitely not the only one who leaves todos [09:58:05.0000] devsnek: By "explain", I mean make it as if BigInt were a feature added through operator overloading [09:58:59.0000] I'm not sure that's inherently possible [09:59:09.0000] if we require additional syntax at or around usage sites [10:16:06.0000] I'd probably explicitly mention using operator overloading for polyfilling types like you mentioned. Personally I want to polyfill all the types in my proposal. const a = new uint32(5); a /= 2; :O Once thought only possible with BigInt. Truly a paradigm switch. Complex numbers, vectors, and matrices. Should probably just make an explicit list of use cases and examples. [10:20:44.0000] Also maybe I missed something, but I didn't understand the a.contents stuff in the code sample. [11:03:25.0000] Just looked at it again. I thought it was extending the other library vector when I skimmed it. I get it now. [11:38:41.0000] Bakkot: yes there are cases like that ("If Foo let X be *" without a corresponding else, and later usages of X also guarded on Foo) [15:00:16.0000] devsnek: The idea has been that you'd imagine there would be an "operator overloading prelude" for the built-in types. It's an action item I have (from Mark) to actually write this prelude, to prove it's possible. [15:01:05.0000] is that tangible to user code? [15:01:35.0000] Sirisian: Yes, i've been trying to accumulate use cases, and I'd appreciate your help in that. Feel free to make a PR to the explainer to add more use cases [15:01:56.0000] devsnek: No, in general, you can't reflect over code in JS... how would it be tangible? [15:02:16.0000] if its not tangible then explaining it doesn't matter [15:02:27.0000] I don't know what you mean by being tangible [15:02:34.0000] maybe I'm not explaining the sense of "explaining" very well... [15:02:46.0000] js code can observe that there is a prelude and that it contains BigInt and Number [15:03:05.0000] well, you can observe it by doing arithmetic calculations on BigInt and observing that it works rather than throwing a TypeError [15:03:13.0000] that's the exact same way that you'd observe it for your own types [15:03:19.0000] ok so then again [15:03:23.0000] there's no point to defining a prelude [15:03:28.0000] the goal is that you can do your own BigInt-like thing, and it'd really work [15:03:30.0000] because we're talking about behaviour not declarations [15:03:51.0000] not sure what you mean. "defining a prelude" is a design-level exercise [15:03:58.0000] (like writing spec text or explainers) [15:04:24.0000] i'm not sure how that matches the goal of explaining how bigint works [15:05:00.0000] let's talk about this another time. I don't really know how to get across this concept of "explaining". I'll think about it some more. [15:05:32.0000] "explaining" is a kind of TC39 jargon that predates me in committee; maybe it's not the best word [15:05:45.0000] i thought it meant representing some behaviour in a way that js code can also interact with [15:05:50.0000] like toStringTag [15:06:26.0000] if js code can't interact with the prelude it doesn't matter whether the prelude exists or not, its just some imaginary thing [15:08:40.0000] so, ES6 explained a bunch of things in a way that also added tons of dynamism and reflection. For reasons that I tried to explain, we don't really have the option of adding all that dynamism in this case. But the core of "explaining" isn't dynamism or reflection, but the idea that the thing that's built-in is also something that you could do in user code. That's something real too. [15:09:06.0000] (you might consider things without dynamism/reflection bad, or that this feature isn't worth it, but that doesn't mean that it isn't "explaining") [15:09:40.0000] to me it is like saying we're adding toStringTag but then not getting rid of [[ClassName]] [15:09:55.0000] or [[Class]] or whatever it was called [15:10:06.0000] like the magic is still there, on a separate layer from the stuff js can do [15:10:22.0000] bigint magically works in any scope and there's no js equiv [15:10:38.0000] Well, there's some things that would have to be pretty special forever, like how + works with strings and non-strings. But I think most of the arithmetic operations should be completely explainable in terms of this general mechanism [15:11:06.0000] BigInt would work with this "prelude" theory. That's the one special case [15:11:17.0000] if the prelude is invisible to js it doesn't exist [15:11:52.0000] it's a concept, sure. (does anything really exist?) [15:11:57.0000] no i mean [15:12:00.0000] bigint is still special [15:12:05.0000] in the same way [15:12:37.0000] yes, but it's special in just one way; it's not *as* special. That's how I'm defining the design goal, the only way that I can see this matching up with the need to have the operator overloading declarations be scoped [15:12:50.0000] would the small scope version allow operator stuff to be less static? [15:13:02.0000] its like if you said "every time a function is invoked, a parallel universe is created where the function is evaluated" [15:13:04.0000] ljharb: In my opinion, no. Do you think it would? why? [15:13:06.0000] personally the second-class nature of the current operator (and decorators) proposal is a big sticking point for me [15:13:21.0000] from the perspective of js you could never observe such a thing [15:13:26.0000] so it doesn't matter [15:13:37.0000] devsnek: with a dep graph where half of the operators are transpiled and half are native, it'd be observable, no? [15:13:58.0000] you can't observe "use strict", but we stick it in modules implicitly... I'm not really sure what you're talking about, why this is a goal [15:14:06.0000] which [15:14:06.0000] what are you talking about [15:14:10.0000] you can add use strict to code [15:14:19.0000] that is an observable change to js code [15:14:27.0000] yes, just like adding `with operators from` delcarations [15:14:33.0000] i don't mean reflection [15:14:42.0000] i mean what humans using js can observe and interact with [15:14:53.0000] from that perspective bigint is just as magical [15:15:00.0000] right now there could already be a prelude with your behaviour [15:15:07.0000] adding or removing it doesn't change anything [15:15:27.0000] BigInt is built-in. The idea is that it's special in a well-scoped way, limited to just what you could do with a prelude, not that it's *arbitrarily* special [15:15:53.0000] that's the design goal I'm working towards. You can disagree about whether it's a worthwhile goal, but that's what I'm trying to communicate. [15:16:06.0000] your goal doesn't make sense to me [15:16:10.0000] OK [15:16:51.0000] i can't judge whether it is worthwhile or not because it appears to me to be a non sequitur [15:18:06.0000] ljharb: my idea with the scoped version i talked about above is that it would allow more dynamicness [15:18:52.0000] meaning like, a protocol? [15:18:58.0000] yeah [15:19:07.0000] no need for anything static [15:19:51.0000] but dan said the static-ness was partially because people wanted it to have integrity [15:20:16.0000] what kind of integrity [15:20:33.0000] like, how + should be commutative? [15:20:35.0000] or something else [15:20:43.0000] i assume it means you can't patch someone's overloads [15:20:52.0000] which seems rather unjavascripty to me [15:21:02.0000] unless you've frozen it, i agree [15:22:02.0000] that's an expectation i have for builtins, but not for user code [15:23:53.0000] they have configurable: false for toStringTag [15:24:20.0000] toStringTag is a special (bad) case that i don't see as related to operators [15:28:05.0000] devsnek: you can't patch someone's overloads today [15:28:30.0000] like you can't redefine what "+" means in my code [15:28:36.0000] there aren't overloads today [15:28:40.0000] so why would... we want to... start letting people do that? [15:29:12.0000] I don't think "let other people change the semantics of my code" is really a goal anyone on the committee has [15:29:13.0000] that's exactly what operator overloading is trying to do [15:29:18.0000] no it is not [15:29:22.0000] let other people define the semantics of my code [15:29:26.0000] no? [15:29:31.0000] not without my explicitly opting in [15:29:34.0000] whether people can do it once, or more than once, doesn't seem that different to me [15:29:54.0000] that's the same as referencing any property on any object tho [15:30:04.0000] you opt in to using that property, and it's possible it could be changed later [15:30:12.0000] (when you don't destructure it, obv) [15:30:32.0000] and assuming it's not frozen, which in this proposal it would be [15:30:34.0000] so hey, all is well [15:31:03.0000] so you mean like, it's a symbol protocol, but the syntax for declaring it freezes it? [15:32:10.0000] if so, that does seem reasonable to me; anyone can participate but the default/ergonomic behavior makes it robust [15:44:23.0000] I think it also destructures when entering the block, so it's defensive twice [15:44:27.0000] don't remember exactly though [15:44:32.0000] it was a very early stage design [15:45:40.0000] ah, yeah, it reads the Operators property and that thing can only be made by a built-in Operator factory which produces immutable values, cool [15:46:06.0000] anyway obviously someone can just define the overloaded functions themselves in a way which has their behavior change over time [15:46:23.0000] point is, you have to opt in to using someone else's operators, and random third-party code can't just muck with it 2020-05-05 [23:57:45.0000] It didn't occur to me that you can name a class "Number". [00:12:49.0000] ad-hoc example I was thinking about earlier for operator overloading: https://pastebin.com/pjRgwK4u uses extension classes. (Basically a class with just operators is merged into previous declarations). 2020-05-06 [19:24:14.0000] Do you think anyone actually creates a "class Number {}" in their code? Would it be a breaking change for a proposal to depend on such syntax for "extending" the Number object? [19:54:42.0000] it's a breaking change regardless of whether it breaks anybody, but I'd bet money that it does exist out there [20:45:00.0000] yeah that's a totally reasonable thing to write [20:45:28.0000] (maybe not totally) [21:10:55.0000] it's definitely reasonable in a non-top scope [21:50:18.0000] Sirisian: `class extends Number` is how you extend the number object? [21:50:38.0000] Sirisian: if you mean, mutating it, it would be an absolutely horrific idea imo to provide any encouragement, let alone syntax, for mutating objects you don't own [22:05:48.0000] ljharb, This was in the context of adding operators to a class. Was trying to think of a simple syntax that used extensions classes like in my above example. (The extensions would only work for defining operators). I guess in C++ if I remember it would be like creating a friend to a free function operator overload, but in that you need access to the class to define the friend to access private variables. [22:10:17.0000] i'm not sure what "friend" would mean in JS [22:20:19.0000] In any case I'd need a way to refer to I guess the intrinsic object as the specification calls it. I don't think there's an elegant syntax that could be made for that. Starting to see why proposal uses the syntax it does. [05:15:05.0000] String.isWellFormed(str), String.prototype.isWellFormed, or meh? [06:21:15.0000] likely friend in JS just means having a shared private id in scope [06:21:32.0000] you can do that with nested classes currently, but not across source texts [06:54:09.0000] the operator overloading proposal was designed to meet multiple different integrity goals, described in the explainer. It feels like the discussion here was focusing on a subset of them. [09:44:02.0000] annevk "well formed" in this context meaning "valid UTF-16"? [09:47:32.0000] Bakkot: yeah, well-formed seems to be the term used for UTF-8 in ECMAScript [09:48:16.0000] Bakkot: lone surrogate detector is also fine, I don't really care about the specifics [09:48:33.0000] https://github.com/whatwg/encoding/issues/174 has context [09:50:57.0000] seems reasonable to me; cc mathiasbynens [10:34:33.0000] sgtm too [14:39:46.0000] anyone who has graphic design experience please weigh in on https://github.com/tc39/ecmarkup/pull/178 [14:40:06.0000] I am not a graphic designer and do not want to try to figure out what the correct graphic design is for this [14:40:18.0000] or like UI/UX design really, not graphic design [14:43:06.0000] if any v8 people around: are you aware of how v8 handles stack traces for errors thrown with inlined functions in the stack? [14:57:22.0000] Bakkot, Standard convention for an accordion independent of left/right position is points right is closed and points down is open. That said I've seen the up/down used also. If it's on the left the former convention is more clearly correct. The trick is to pick one and make it part of your identity like tabs/spaces. [15:01:33.0000] rickbutton: there is a bit of data on sharedfunctioninfo which maps inline locations to usable source positions [15:02:20.0000] thx! ill look there devsnek [15:02:39.0000] rickbutton: actually i lied its OptimizedCompilationInfo [15:04:26.0000] cool [15:37:28.0000] rickbutton: is there a specific thing you're trying to do? [15:38:12.0000] rickbutton: https://source.chromium.org/chromium/chromium/src/+/master:v8/src/execution/frames.cc;l=1534?q=OptimizedFrame::Summarize&ss=chromium&originalUrl=https:%2F%2Fcs.chromium.org%2F is what iterates the inlined frames 2020-05-07 [22:07:36.0000] has anyone ever seen someone write `if (x) try { ...` [22:30:26.0000] i rarely see if's without curlies anymore, since heartbleed [22:32:02.0000] lol [00:22:18.0000] rwaldron, what's the status of https://github.com/tc39/test262/tree/master/implementation-contributed ? 2020-05-08 [20:53:36.0000] audio worklets remind me how nice it would be for that blocks proposal to become a thing [05:34:07.0000] youniesmahmoud: welcome 2020-05-11 [09:48:02.0000] mfw `return promise` can throw in async generators but not async functions [10:32:00.0000] devsnek: example? [10:32:12.0000] ljharb: `return Promise.reject()` [10:33:01.0000] why would that throw [10:33:11.0000] `return` performs an await in async generators [10:33:24.0000] https://gc.gy/56923403.png [10:34:18.0000] yeah that's pretty weird [10:35:08.0000] otoh does anyone actually `return` in a generator? [10:35:16.0000] i do [10:35:21.0000] but its not that common [10:35:25.0000] why? [10:35:31.0000] (sincerely; I'm curious what the use case is) [10:35:37.0000] my engine262 evaluator is built on generators [10:35:42.0000] not the async kind though [10:36:02.0000] yes that is very weird [10:36:27.0000] Bakkot: https://github.com/engine262/engine262/blob/parser/src/runtime-semantics/IfStatement.mjs#L21 [10:36:27.0000] what does `return` do for you there? [10:36:55.0000] its how i return values [10:37:02.0000] i use it like a normal return [10:37:14.0000] hmm [10:37:29.0000] I guess my question is, presumably this bottoms out somewhere where it isn't just generators deferring to generators [10:37:33.0000] and that is the part I am interested in [10:37:50.0000] https://github.com/engine262/engine262/blob/parser/src/helpers.mjs#L141-L153 [10:38:57.0000] https://github.com/engine262/engine262/blob/parser/src/abstract-ops/function-operations.mjs [10:39:03.0000] oops [10:39:03.0000] https://github.com/engine262/engine262/blob/parser/src/abstract-ops/function-operations.mjs#L124-L127 [10:39:35.0000] aha [10:39:36.0000] neat 2020-05-12 [19:01:06.0000] That seems like a bug, honestly. [19:02:13.0000] i remember a bit of discussion on it as an intentional decision [19:41:21.0000] Seems its https://github.com/tc39/proposal-async-iteration/pull/102 [19:41:36.0000] With relevant slides at https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.p [20:32:30.0000] This should be changeable [20:33:09.0000] Justification slides at 8 and 9: https://docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_207 [20:33:45.0000] These don't apply to `return Promise.reject()`, since any finalization would be able to run. [20:34:03.0000] So it'd be a normal completion [20:34:26.0000] We only need to ensure that the rejection is unwrapped before the iterator object settles [23:06:59.0000] 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 [23:07:25.0000] unlikely. why do you dislike it? [23:08:56.0000] e.g.: `const add = (a, b, nanAsZero = false, undefinedAsZero = false) => ...; add(1, 2); add(1, 2, undefinedAsZero: true); add(1, 2, nanAsZero: true);` [23:10:35.0000] 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}); ...` [23:10:52.0000] i mean, you'd do `({ a, b, etc } = {})` but sure [23:10:56.0000] ie, you'd destructure inline [23:11:13.0000] also generally i'd say you want the required params to be positional [23:11:39.0000] or this, which I think is worse: `const add = (a, b, opts = {}) => ...; add(1, 2); add(1, 2, {undefinedAsZero: true}); ...` [23:12:05.0000] why is that worse? [23:12:19.0000] the signature is unnecessarily complicated [23:12:39.0000] it's extra curly braces [23:12:58.0000] how is that more complicated than adding an entirely new syntax [23:14:49.0000] I'm not sure, it feels like extra cognitive load, and acts as an obstacle to writing clean functions [23:15:00.0000] "clean" is very subjective [23:15:29.0000] 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 [23:17:05.0000] 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 [23:17:37.0000] 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 [23:17:38.0000] would be. [23:17:40.0000] considering that's how a very large amount of the js ecosystem already does it, i don't think it will discourage anybody [23:19:02.0000] (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 `{}`.) [23:20:41.0000] 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 [23:21:03.0000] in python, you can do `def fn(a, b): ...; fn(b=1, a=2)` [23:21:53.0000] naming positional parameters, even if keeping the same order, could add a lot of optional clarity to user code [23:22:08.0000] that example is already valid syntax (it creates a global variable) [23:22:41.0000] i think it would work with the colons, but then it falls to the "high bar" Bakkot referenced [23:22:50.0000] well, in js using `=`, sure, but we could have `const fn = (a, b) => ...; fn(b: 1, a: 2)` [23:23:22.0000] sometimes i do wish we could name parameters like that [23:23:26.0000] I think it's worth thinking about, but thank you for your time :) [23:23:26.0000] 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 [23:23:27.0000] but i don't think overall it is worth it [23:24:02.0000] oh, good point [23:24:22.0000] seems more like a feature for typescript than js [23:24:48.0000] TS does not intend to add non-type features, so they're probably not interested [23:24:50.0000] p sure TS won't add any new non-type-related features [23:24:59.0000] you could write a babel plugin for it though! [23:25:08.0000] wouldn't be too tricky I expect [23:25:30.0000] 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. [23:25:36.0000] (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) [23:26:02.0000] well they say that [23:26:10.0000] oh i got scroll'd [23:26:22.0000] 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 [23:26:57.0000] now if we had monads [23:27:23.0000] you could just safely and functionally get the arguments [23:27:24.0000] s/positional parameter names/positional parameters/ [23:28:26.0000] alright, thanks all, I'll be back with another failed idea in a few months, I'm sure :) [23:28:56.0000] keep 'em coming [23:28:58.0000] oh they quit [23:31:39.0000] https://github.com/sirisian/ecmascript-types#named-arguments I think this is the example I saw a few times. Functions with lots of defaults. [23:32:38.0000] I don't think you should really worry about it [23:32:59.0000] yeah, I told other people it's so low priority it's not worth it. [23:33:20.0000] destructuring is in all likelihood the only thing we will have for named parameters forever [23:33:33.0000] Indeed [23:35:12.0000] you could also just use global variables [23:35:29.0000] `f(a=1)` and check the value of `globalThis.a` in `f` [23:35:48.0000] lol [23:36:45.0000] Creative. [23:38:19.0000] 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 [23:38:33.0000] (don't even need a proxy I guess, come to think) [23:39:24.0000]