2020-06-01 [17:24:37.0000] (whining aside though, it'll probably be beneficial to have a more structured schedule for a bit, lol) [19:09:26.0000] devsnek: congrats! Don’t stress out to much, it will probably be better to focus on the onboarding and take some rest if necessary instead of much of TC39 stuff. Don’t let the FOMO take out your energy. [07:47:10.0000] morning all [07:51:45.0000] mornin' [07:55:01.0000] TCQ: https://tcq.app/meeting/KfmX [07:56:41.0000] meeting info link in the topic is outdated. should be https://github.com/tc39/Reflector/issues/279 [07:58:28.0000] thank you Rob :) [07:59:33.0000] did anyone create notes docs already? happy to update the short URLs again [08:01:36.0000] mathiasbynens they're in the reflector, yeah [08:01:49.0000] also reminder to all not to link the notes here, in this publicly logged channel [08:02:11.0000] i don't see them in https://github.com/tc39/Reflector/issues/279 [08:02:34.0000] i see, #294 [08:06:48.0000] good morning everyone :-) [08:08:31.0000] Good morning! :) [08:08:45.0000] if you call on me next, I can give my standard IPR disclaimer [08:08:55.0000] I imagine Istvan's thing is not what was being asked about [08:09:09.0000] akirose: ^ [08:09:15.0000] akirose: your headphones 😂 [08:09:22.0000] so fetch [08:09:38.0000] +1 [08:10:00.0000] littledan: you kind of look like you're interrogating us with that light :p [08:10:16.0000] heh I don't have my awesome coworking space setup [08:10:49.0000] my partner is planning on building a nice planter behind me and hanging up some of his art so it can show up in my video calls, but I guess we didn't plan for the light [08:11:51.0000] that sounds nice though :) [08:13:30.0000] did you just say mancy [08:13:43.0000] mancy [08:36:25.0000] i'm confused about this slides sharing [08:36:31.0000] *i* can control the slide? [08:36:55.0000] oh no [08:37:00.0000] deep powerpoint integration probably [08:37:02.0000] that is too much power [08:37:06.0000] wait when i'm jumping around [08:37:13.0000] am i making it jump around for other viewers, or just myself [08:37:14.0000] it's not jumping for us [08:37:15.0000] ok [08:37:17.0000] whew [08:37:23.0000] you can peek ahead [08:38:15.0000] I assume that doesn't work for Google Slides [08:38:50.0000] I would assume that yes [08:39:05.0000] you can always export your slides in ppt [08:40:20.0000] presumably one would need to actually have ppt lying around for that to do you any good [08:40:29.0000] I don't think I have used a machine with ppt since high school [08:41:11.0000] oh, teams is a ppt viewer apparently, neat [08:45:16.0000] fwiw i literally just uploaded Istvan's ppt that he had emailed to the chair straight to the teams client [08:45:26.0000] no ppt.app launched [08:46:43.0000] phew, irc is working again [08:46:47.0000] (for me) [08:48:33.0000] draft schedule link added to reflector#279 [08:54:36.0000] these editorial improvements are awesome! [08:55:41.0000] +1 [08:56:22.0000] +1 [09:01:53.0000] thanks littledan :-) [09:23:35.0000] akirose: *green heart emoji* been feeling similarly [09:23:55.0000] 100000% [09:26:32.0000] is tcq showing everything or just stuff for today [09:26:43.0000] everything [09:26:51.0000] we chew through as much of it as we can [09:27:03.0000] it may not yet be fully populated but that is the intent [09:27:36.0000] cool [09:27:53.0000] do we have that hackmd schedule this time around [09:28:03.0000] this channel is public and should not have the notes doc linked in it [09:28:17.0000] devsnek: we do [09:28:22.0000] robpalme ^ [09:28:23.0000] devsnek: the hackmd is on the reflector issue for the meeting, its at the top, "Draft Schedule" [09:29:26.0000] robpalme: Bakkot should we move today's notes to another URL? [09:29:39.0000] ehhhh it's probably not worth worrying about [09:29:48.0000] i can move it [09:29:51.0000] either at lunch or eod [09:30:07.0000] thanks [09:30:13.0000] any preference? [09:34:07.0000] yeah, I agree that late agenda items should be deprioritized [09:35:02.0000] Isn't today a holiday in parts of Europe? [09:35:42.0000] ryzokuken: it is [09:36:03.0000] that's likely the issue, I guess 😅 [09:44:55.0000] jridgewell I am glad/impressed you know those NamedEvaluation details off the top of your head [09:45:00.0000] I just reviewed this change and I still don't [09:45:07.0000] note that ease for polyfill doesn't correspond to ease for impl [09:45:24.0000] shu: to clarify, chrome is shipping it with or without the inferred name? [09:45:44.0000] ljharb: without currently, because it's not in the spec [09:45:49.0000] thanks [09:45:54.0000] ljharb: if it is added, there is plenty of time to add it in before it hits stable [09:46:28.0000] gotcha [09:46:38.0000] drousso: you had thoughts on the issue thread btw [09:46:47.0000] ya [09:46:53.0000] i don't feel strongly [09:47:15.0000] i am slightly towards "no" because of the short circuiting behavior [09:47:46.0000] short circuiting behavior actually leans towards yes, I think [09:48:10.0000] because with short circuiting it desugars to `a && a = function(){}`, which gets named [09:48:43.0000] the tricky part is that while that is the desugaring, it's not the current code you would write [09:48:47.0000] or `if (a) { a = function () {} }` which also gets named [09:51:10.0000] +1 to what rkirsling [09:51:11.0000] said [09:51:19.0000] personally, I don't see the size of the Babel output, or the desugaring, as a very strong argument one way or another [09:51:39.0000] it's more about the general pattern that, in these sort of direct syntax assignment cases ending in = or :, you do name assignment [09:51:56.0000] (sorry for caucusing before...) [09:52:31.0000] yeah, agreed with littledan [09:53:55.0000] sorry, the conclusion was yes, go ahead with named evaluation? [09:54:29.0000] sounds like yes, infer the name, as long as implementors can commit to implementing that [10:08:45.0000] petition to consider shorter lunch breaks the next three days [10:09:06.0000] esp considering we're not all eating lunch at the same times when remote [10:09:07.0000] I just had breakfast, so I'm not going to eat lunch, so I'm just sitting around [10:16:16.0000] is iterator helpers happening now [10:16:33.0000] It's a tech check [10:16:52.0000] We're on break till the new hour [10:17:06.0000] ah ok [10:18:15.0000] ***Note-takers and Note-readers*** Today's notes have been migrated. Please find the new link here: https://github.com/tc39/Reflector/issues/279 [10:29:53.0000] i'm gonna mention this when we reconvene, but… we have way, way more time on the agenda than we have meeting time. use that information as you will. [10:33:50.0000] folks in the breakout room feel like a one-hour lunch break doesn't really make sense under all-remote conditions [10:36:57.0000] rkirsling: as in, it's too long? [10:37:16.0000] yeah [10:38:08.0000] as in, like, even if you're in the appropriate time zone you might not need that long of a block of time when you're connected remotely anyway [10:38:24.0000] I dunno, I just finished cooking lunch, don't have that much time to eat :-P [10:40:35.0000] The difference being it's ok to mute yourself and eat as presentations are going on [10:40:44.0000] It's a little different than when we're in person [10:40:57.0000] shorter break time sgtm [10:41:27.0000] Also the side discussions are much louder in-person, so having a long lunch break was nice [10:50:39.0000] michaelficarra: are you around? [10:56:24.0000] Is anyone here well-connected enough to get us an invitation to Clubhouse for the hallway track? https://www.wired.com/story/what-is-clubhouse-why-does-silicon-valley-care/ [10:58:29.0000] "a new social network more exclusive than Berghain" AHAHAHAHAHAHAHAH [10:58:40.0000] we are restarting in 1 minute! [11:02:03.0000] starting now! [11:04:56.0000] if there are questions about iterator helpers stuff i can address i'm watching the channel here but not actively listening to the call [11:07:11.0000] ppt integration seems much worse than the share-screen integration [11:11:35.0000] akirose: `Intl.DurationFormat` is today according to https://hackmd.io/@tc39-chairs/rylG45f2L#1300-CDT, but it's not on the agenda. [11:11:36.0000] yep.. [11:12:02.0000] these slides are really good [11:13:31.0000] Upstream iterator was never started either though [11:13:42.0000] enclosing finally blocks around the current yield pause point are called by generator return FWIW [11:14:13.0000] eesh, i didn't realize the slides were advanced, i was stuck on slide 5. guess i'll open the link myself [11:14:14.0000] iterators don't get started [11:14:18.0000] generators get started [11:14:23.0000] ... I think [11:14:35.0000] iterator is just a protocol [11:14:41.0000] there's no behaviour [11:14:49.0000] but the protocol doesn't involve a "start" phase, I think [11:14:59.0000] right [11:16:07.0000] Sure, but depending on .return to close upstream iterators isn't guaranteed either [11:16:18.0000] s/close/"return" [11:17:19.0000] not guaranteed, but it seems very strange to have a builtin which unconditionally prevents you from doing that [11:17:28.0000] rather than deferring to the upstream [11:18:51.0000] Bakkot: Well, you might think of the first .next() call is more or less a "start" phase [11:20:03.0000] ryzokuken: working on it. bterlson & robpalme are debugging something [11:20:21.0000] littledan: sure, but I wouldn't really expect that [11:20:25.0000] you can call .return before .next [11:20:42.0000] so it is reasonable to implement an iterator which is opened when it is obtained [11:20:46.0000] not when it is first queried [11:20:48.0000] right, this case is weird [11:20:52.0000] and the builtins should work with that [11:20:54.0000] akirose: thanks. [11:21:16.0000] (I wouldn't expect to have .return/.throw at all, and have previously proposed that we remove all that from the iterator protocol, but maybe it's too late now) [11:21:33.0000] there are many more slides [11:21:43.0000] To me its inconsistent to have a built-in that differs in behavior from what a user could normally accomplish with a generator. [11:21:44.0000] whatwg streams make use of them, I think [11:22:11.0000] rbuckton why? generators are a convenient way of creating iterators, but not the only way [11:22:33.0000] Of course, generators are essentially "lazy" since no code runs until the first call to `.next()`. [11:22:43.0000] jridgewell: it's iterator helpers, not iterable helpers [11:23:10.0000] There's a constructor, no? [11:23:23.0000] `new IterableHelpers(set)` [11:23:24.0000] Bakkot: I thought that was pretty new/not universally shipped. But iterator .return/.throw has been shipped everywhere for years [11:23:32.0000] michaelficarra: I still think targeting *iterator* and not *iterable* is the wrong abstraction. [11:23:33.0000] jridgewell: no [11:23:34.0000] rbuckton: every iterator-producing method in the spec already differs in that behavior. [11:23:36.0000] littledan yeah, it's new. seems useful though! [11:23:43.0000] jridgewell: set.values().map() [11:23:50.0000] ES6 itself wasn't consistent between iterator-producing methods, and "what generators do" [11:23:57.0000] re: "spec will be long", fwiw we could cut down the duplicate spec text the way we do for typed arrays and errors [11:24:13.0000] jridgewell: no, though there is Iterator.from [11:24:22.0000] Bakkot: i tried that, its still very long [11:24:28.0000] because each one has very different logic [11:24:28.0000] I would have almost preferred `new Iterable(set.values()).map()`. [11:24:55.0000] Does `Iterator.from` call `@@iterator`? [11:24:59.0000] yes [11:25:01.0000] yep [11:25:04.0000] 👍 [11:25:28.0000] Removed myself from the queue [11:25:51.0000] devsnek: hm, that's surprising to me [11:25:55.0000] Yield macro just calls GeneratorYield or AsyncGeneratorYield [11:25:59.0000] no new machinery there [11:26:02.0000] devsnek were you using abstract closures? [11:26:12.0000] Bakkot: i considered abstract closures [11:26:19.0000] i didn't come up with anything fantastic there [11:26:35.0000] because with abstract closures you would just specify a State record and an abstract closure and .next would just invoke the abstract closure [11:26:47.0000] it's only flatmap which would be more than that, I think [11:27:08.0000] i don't want to make something that needs special cases [11:27:13.0000] meh [11:27:14.0000] I don't hate option 1: is there really a need to forward return/throw? [11:27:15.0000] just from a principled perspective [11:27:17.0000] I wrote package that essentially has these helpers over iterables: [11:27:17.0000] ```js [11:27:17.0000] const { from } = require("iter-query"); [11:27:17.0000] from(set.values()).map(...) [11:27:17.0000] ``` [11:27:18.0000] It makes a lot more sense to me at that level, though I understand the want to attach these to `%IteratorPrototype%` for convenience. [11:27:18.0000] it's editorial [11:27:21.0000] i think we need good ways to add stdlib behaviour [11:27:26.0000] without special casing everything [11:27:42.0000] I don't really think we should be optimizing for the spec being short [11:27:56.0000] s/don't really think we should/strongly believe we should not/ [11:27:58.0000] agreed [11:28:08.0000] I'm personally a fan of something like Option 1 (or at least, that uses `[@@iterator]`) [11:28:08.0000] it's not about being short as much as its about being consistent [11:28:24.0000] as long as the user-observable behavior is consistent, I don't know why we would care that much [11:28:32.0000] option 3 is polyfillable btw [11:29:25.0000] michaelficarra it seems important that `.throw` and `.return` forward to the underlying iterators, personally [11:29:45.0000] like `iter().map(x => x)` should be as close as possible to `iter()` [11:29:58.0000] option 3 doesn't directly forward but it keeps the state consistent [11:30:10.0000] it will call the methods, i mean [11:30:27.0000] what is the difference between 2 and 3 other than editorial? [11:30:52.0000] in 2 they are plain objects that are iterators [11:30:57.0000] in 3 they are actual generators [11:31:10.0000] ah, but specced using spec machinery instead of JS code? [11:31:14.0000] yeah [11:32:39.0000] personally I like option 3 the best, and agree with this goal of avoiding special-casing. [11:33:11.0000] (just because we used one-off solutions each time in the past does'nt mean we need to keep doing that forever in the future...) [11:33:17.0000] I really don't think the presence of the methods should be conditional [11:33:21.0000] ljharb ^ [11:33:24.0000] +1 [11:34:26.0000] is bradford on IRC? [11:34:28.0000] michaelficarra: i can understand that position for sure. but also APIs that consume iterators might be checking for the presence of those methods now, and taking simpler code paths when they're absent, so it might have an impact [11:34:55.0000] agreed it might have an effect but I agree with michaelficarra anyway [11:36:48.0000] Bakkot: what do you think about async abstract operations [11:36:52.0000] abstract closures* [11:37:08.0000] devsnek hmmm [11:37:12.0000] no inherent problem with them I guess [11:37:20.0000] would need to be defined [11:37:28.0000] from outside, it'd just be a regular one that returned a promise [11:37:30.0000] seems fine to me also [11:37:46.0000] no, more than that [11:37:58.0000] but that part of the spec could use our going over anyhow [11:38:07.0000] the part that actualy does the continuation wrapping in a promise [11:38:25.0000] it would definitely require spec work [11:39:28.0000] I still wish the helpers went through `[@@iterator]` so they could be copied to other objects that are iterable. For all built-in iterators as well as generators, `[@@iterator]()` just returns `this`. Just depending on the presence of a `next` method makes me think of all of the issues with `then` we've had in the past. [11:40:08.0000] shu: i know it'd need lots more for "inside" the async abstract closure - i meant like from the callsites [11:40:24.0000] unfortunately I don't think we're going to come to a clear decision before this timebox is over :-( [11:40:52.0000] rbuckton: the main concern is preventing people from getting into patterns that rely on @@iterator being reusable when it isn't [11:40:58.0000] ystartsev: Wait so would something like Symbol.generatorInitialize solve option 1? [11:41:13.0000] what is Symbol.generatorInitialize [11:41:15.0000] that is called when the generator function is first called [11:41:26.0000] robpalme sorry got dropped [11:41:27.0000] to validate args and stuff? [11:41:31.0000] what were you asking me? [11:41:32.0000] keith_miller: how would i do that syntactically tho with regular generators [11:41:33.0000] yeah [11:41:33.0000] ping jorendorff for that [11:41:37.0000] pinging* [11:42:43.0000] You'd have to have something like (function* myGenerator() { ... })[Symbol.initializeGenerator] = function init() { validate(arguments[0]); } [11:42:50.0000] not saying it's pretty [11:43:00.0000] ljharb: but it would let you do stuff [11:43:30.0000] oh no that wouldn't solve it actually [11:43:34.0000] at the risk of making all calling of generators slower? [11:43:36.0000] Ah, ok [11:43:40.0000] because you wont be able to forward properly [11:43:46.0000] I think you just write a function which invokes and generator and returns it [11:43:58.0000] ystartsev: the initialize could set up the forwarding [11:44:04.0000] function f(){ validate(); return function*(){}(); } or whatever [11:44:13.0000] ljharb: I mean initializing generators is already crazy slow [11:44:13.0000] lol [11:44:13.0000] that's what option 3 does [11:44:19.0000] right [11:44:25.0000] and I think userland code would do the same thing if they want this [11:44:29.0000] yep [11:44:35.0000] would do this? [11:44:53.0000] Or would make their equivalent of the polyfill? [11:44:57.0000] well actually what i want is a way to create a generator that has no initial yield [11:45:24.0000] I mean sure, this is just a hacky way to get that [11:45:28.0000] I don't think complicating generator functions even more is a good solution to this [11:45:40.0000] oh no i don't think we should do that as part of this [11:45:50.0000] none of these options ask for that [11:46:38.0000] I mean option 3 is effectively asking VMs to do it [11:46:45.0000] Options 2 and 3 seem to be regular functions that could return generator instances, which seems a better solution [11:46:51.0000] so... for me there's no difference but I'm an implementor [11:47:17.0000] Giving more magic to generator functions makes the transform muchhh more complicated [11:47:36.0000] did we get consensus to use option 3 there? [11:47:37.0000] I already don't want to maintain the regenerator transform [11:48:03.0000] we didn't really get a conclusion here right? [11:48:10.0000] yeah that was weird [11:48:18.0000] wow how did we get this far down on the agenda? [11:48:30.0000] time constraints? [11:48:53.0000] afaik the point of that presentation was to get consensus on how we should proceed [11:48:55.0000] I'm not sure how option 3 forward the arg of first next call (which function.sent need)? [11:49:09.0000] haxjs: StartIteratorHelper calls .next() once [11:49:20.0000] which is why %SyncMap% starts with a Yield() [11:51:02.0000] Can't find it in https://gist.github.com/jorendorff/35504c2553170be98fc2810ccf60c608 🤔 [11:51:15.0000] haxjs: the value is lost there [11:51:22.0000] that's not option 3 [11:51:28.0000] That's Option 1, I think [11:52:09.0000] Iterator.prototype = { [11:52:09.0000] map(mapper) { [11:52:09.0000] let it = SyncMap(this, mapper); [11:52:09.0000] it.next(); [11:52:09.0000] return it; [11:52:10.0000] } [11:52:10.0000] }; [11:52:29.0000] haxjs: more or less, yeah [11:56:34.0000] re: iterators [11:56:39.0000] i have opened this issue: https://github.com/tc39/proposal-iterator-helpers/issues/97 [11:56:45.0000] keith_miller: re your queue item; they already can't, because they're inside an expression position [11:56:56.0000] ljharb: ?? [11:57:15.0000] I'm saying it's the same result as an eval [11:57:15.0000] do you all think we could revisit this for 5 min on thursday? [11:57:34.0000] keith_miller: ah, k [11:59:58.0000] brad4d: an IIFE wouldn't necessarily preserve `super`, `arguments`, `this`; nor `await`, and it would make control flow questions complicated [12:01:13.0000] an arrow iife preserves `super`, `this`, `arguments` [12:01:30.0000] is it really desirable to return / break from a do {} expresssion? [12:01:35.0000] yes [12:01:43.0000] imo no, but some folks think yes [12:01:51.0000] Arrow won't preserve `yield` [12:01:55.0000] or `await` [12:02:11.0000] i really want control flow from do expressions [12:02:25.0000] You can use `await async () => { await x }` [12:02:27.0000] bradleymeck: control flow non-local to the do block is contentious [12:02:54.0000] But not for `yield`, because we still don't have arrow generators [12:04:51.0000] shu: did you mean to ping me on that? [12:05:05.0000] bradleymeck: nope, sorry :) [12:05:07.0000] brad4d: ^ [12:05:35.0000] shu ack [12:07:34.0000] i think control flow has utility in various positions that are annoying to deal with otherwise but not fatal to be missing [12:10:04.0000] there are some really odd things you can do though, like `do {continue}` on a destructuring default assignment to skip a loop [12:12:05.0000] does return/break/continue inside eval already work in an expression position? [12:12:14.0000] no [12:12:19.0000] you mean `let {x = do {continue}} = obj;` would continue a loop if `obj` doesn't have an `x`? [12:12:43.0000] I think that is harmful to readability. [12:13:03.0000] to me that's a linting concern [12:13:20.0000] there are places (outside of destructuring declarations) where continue can be useful [12:14:14.0000] that's how zkat initially wrote those proposals iirc—pattern matching + do expressions intended to move through committee side-by-side [12:14:21.0000] devsnek could you point me at a use-case where flow-control inside a `do{}` would be beneficial? I can't seem to come up with one on my own? [12:14:47.0000] ljharb: the coupling with pattern matching would be a nice thing to discuss in incubator(ish?) calls [12:15:03.0000] idk Mark's irc handler if any [12:15:10.0000] leobalter: agreed; we're still pretty far from being ready for that tho (mpcsh) [12:15:11.0000] it's been discussed in the pattern matching calls [12:15:28.0000] brad4d: there was one in the slides [12:15:37.0000] Lol [12:16:04.0000] /me sees myself to TDZ [12:16:13.0000] ljharb leobalter Bakkot: should we try to get both of these proposals on an incubator call? [12:16:23.0000] leobalter: happy to invite you to the next pattern matching call if you're interested [12:16:39.0000] yes, please [12:16:54.0000] mpcsh: yes, but i think after i've got the PR ready to update the proposal :-) [12:17:24.0000] 👍 [12:18:22.0000] I've seen a fair amount of Kotlin code that does continue/break/return in expression positions: [12:18:22.0000] ```kotlin [12:18:22.0000] for (x in list) { [12:18:22.0000] val y = x?.y ?: continue; [12:18:22.0000] ... [12:18:23.0000] } [12:18:23.0000] ``` [12:19:08.0000] There's a goog internal server language that has `or exit` all over the place. [12:19:08.0000] I share Bakkot 's intuition about blocking return, continue and break from expressions breaking some kind of invariant that we have [12:19:14.0000] rbuckton: I don't think it'd be contentious without the visible boundary of `do {}` [12:19:28.0000] so, I guess this is what exceptions are for? [12:19:53.0000] same; flow control doesn't belong in expression position [12:20:21.0000] rkirsling: which wouldn't be contentious? `x?.y ?? continue` or `x?.y ?? do { continue; }`? [12:20:27.0000] there is no such invariant in how we have specified the language [12:20:37.0000] in fact completion values help allow it [12:20:42.0000] devsnek: sure, i didn't say they can't be. i said they shouldn't be. [12:21:01.0000] dan said there was an invariant [12:21:04.0000] which i strongly disagree on [12:21:07.0000] oh [12:21:18.0000] well, the invariant is that you currently can't do any non-throw flow control in expression position [12:21:23.0000] rbuckton: the former wouldn't be, is my argument. "everything is an expression" doesn't induce confusion where "crossing the border between worlds" does [12:21:26.0000] it may or may not be intentional, but it remains an invariant [12:21:30.0000] I'm totally +1 to do expressions. Although, a spec draft would make it easier for an overview [12:22:07.0000] hmm, I'm not sure why you'd have to care so much about the microtask ticks... I'd hope not many developers have to think in those terms [12:22:18.0000] people often think about overhead [12:22:30.0000] devsnek: Well, it's currently an invariant; we can disagree about the priority of preserving it [12:22:41.0000] like, it's currently a fact about JS that that doesn't happen [12:23:04.0000] that's not an invariant its just a hole [12:23:05.0000] rkirsling: I have an issue on the do-expressions repo that suggests dropping `do {}` and updating ParenthesizedExpression to allow most statements. Then you would have `x ?? (continue)`. The parens are necessary to preserve precedence of `,`, which was one of Bakkot's concerns about throw expressions. [12:23:16.0000] the JS spec notation allows all kinds of stuff that we have decided we won't do [12:23:17.0000] that's like saying %Iterator%.prototype.map not existing is an invariant of the language [12:23:39.0000] and indeed, it is right now [12:23:46.0000] so, in general, I think that assertions of things being "invariants" are value judgements, and I'm comfortable calling my claim a value judgement [12:23:50.0000] devsnek: but i think there's a categorical difference there that you surely are aware of [12:23:55.0000] it's a statement about what we want in the future [12:24:22.0000] drousso: what about the dev tools/repl? [12:24:29.0000] value judgement seems like a better term [12:24:39.0000] ljharb i don't think those people think of that as "completion" [12:24:44.0000] I'm confused by the non-specific confusion [12:24:44.0000] drousso: and yet that's what it is [12:24:57.0000] drousso: so would it be more palatable if do expressions were explained as "like in the dev tools"? [12:25:09.0000] the goal is to continue preserving "ignorance is bliss" around completion values, was my understanding [12:25:12.0000] drousso: since that's something virtually every dev already understands? [12:25:15.0000] ljharb im not convinced that developers even know what's going on in the console [12:25:27.0000] drousso: they figure it out very quickly. they type `3` and the result is `3` [12:25:44.0000] or `if (true) { 3 }` and the result is `3` [12:25:53.0000] it doesn't work exactly like the devtools tho [12:25:54.0000] i just don't get like [12:26:11.0000] drousso: aside from "devtools exposes internals" and whatnot, how does it differ? [12:26:20.0000] why can't we just say some people don't like control flow there, and leave it to linters [12:26:37.0000] oh wait i was thinking of something different [12:26:44.0000] yes it does work the same as devtools [12:26:56.0000] i don't think that that's a good way of explaining it though [12:27:03.0000] as that doesn't clarify anything about what's happening [12:27:11.0000] it just provides a "if you want to see it in action, use devtools" [12:27:21.0000] it doesn't explain what's actually happening [12:27:26.0000] s/it/devtools [12:27:34.0000] drousso: the explanation isn't needed tho, if everyone already intuits how it's supposed to work [12:27:41.0000] Younies is unavailable for his presentation so Record & Tuple is next. [12:27:41.0000] i disagree with that [12:27:44.0000] vehemently [12:28:24.0000] can you give specific examples of what the people you spoke to thought the basic cases should do instead? [12:28:49.0000]