2021-12-07 [12:18:31.0727] Finally realized that setting the room's visibility to "Anyone" won't reveal past messages, so it's safe to do so. 2021-12-08 [00:32:34.0135] Usually past messages under different rules are not (at least should not be) revealed as a default. The people that were talking before the changes relied at the rules at that point and everyone can't be reached for permission. [00:33:01.0932] * Usually past messages under different rules are not (at least should not be) revealed as a default. The people that were talking before the changes relied at the rules at that point and everyone can't be reached for permission. [14:05:51.0490] Yes, they're not, that was my point. (I *thought* they would be, because I didn't read the dialog very carefully and the options are structured in a slightly misleading way.) 2021-12-10 [20:53:15.0735] https://github.com/tc39/proposal-pipeline-operator/issues/232#issuecomment-990615800 [20:53:22.0567] https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-990614661 [07:51:47.0221] https://github.com/tc39/proposal-pipeline-operator/issues/91#issuecomment-991010158 raised the point that the only thing keeping `#` from being the topic token is record/tuple literals being `#{}` and `#[]` and not `{||}` and `[||]`. And this question still doesn’t seem to be settled, since tc39/proposal-record-tuple#10 hasn’t seen recent activity and the most recent record/tuple update from October did not mention the spelling issue. [07:51:48.0236] nicolo-ribaudo: Has there been recent talk over whether the record/tuple champions are committed to `#{}` and `#[]` and not `{||}` and `[||]`? Is there still any chance of the latter syntax being what you choose? [07:52:12.0927] * nicolo-ribaudo: Has there been recent talk over whether the record/tuple champions are committed to `#{}` and `#[]` and not `{||}` and `[||]`? [07:58:59.0969] * nicolo-ribaudo: Has there been recent talk over whether the record/tuple champions are committed to `#{}` and `#[]` and not `{||}` and `[||]`? Is there still any chance of the latter syntax being what you choose? [12:02:03.0175] Honestly, I rather like `{| |}`. I think Flow uses that syntax as well. [12:06:26.0986] That could be a reason they can't or won't adopt it however. [12:09:06.0016] Whether or not Flow or other JS dialects impose hard constraints on record/tuple literals’ spelling, we probably should wait on committing to wholly rejecting `#` as a topic token until the record/tuple champions commit to `#{}` and `#[]` (or `{||}` and `[||]`). [12:38:39.0049] I'm fine with holding onto `#` as an explicit stretch goal [12:39:06.0329] > <@rbuckton:matrix.org> That could be a reason they can't or won't adopt it however. I believe Flow only uses it for exact object types & not values. [12:39:54.0808] Which actually could be conflicting, now that I think about it, cuz it's not about immutability but extra properties. [12:42:06.0649] > <@jamesdigioia:matrix.org> Which actually could be conflicting, now that I think about it, cuz it's not about immutability but extra properties. Something like `const foo: {| a: 2 |} = { a: 2 }` then? [12:44:28.0047] The flow conflict would be that the type would look like a record literal but be an object type. So could be confusing. But wouldn’t be a technical clash [12:44:55.0137] computers would understand the difference [12:45:06.0726] The only point that it conflicts is that with `const foo: {| a: 2 |} = { a: 2 };` flow will not be able to declare a tuple type as easily. [12:46:41.0840] > <@aclaymore:matrix.org> The flow conflict would be that the type would look like a record literal but be an object type. So could be confusing. But wouldn’t be a technical clash Unless the explicit intention is for the type to be a Record. [12:47:04.0420] Heh, I meant a record. [12:47:13.0186] Oh right yeah [12:47:15.0150] * Oh right yeah [12:47:36.0968] Well, computer _wouldn't_ know the difference between "Exact Object Type" & "Record Type" [12:48:01.0591] Unless Flow came up with a distinct syntax for Record Types [12:52:11.0100] Actually, Tuple typing at all in JS IS interesting. For typing the only real issue I think is when something returns a tuple/record. Further, typescript has already a more intricate support for everything except an ergonomic syntax for it. I think there's even DeepReadonlyObject generic (though not included in standard TypeScript typing definitions) [12:52:21.0080] As far as I know, TC39 has never considered TypeScript, Flow, etc. to be hard blockers on potential new future ES syntax, and TypeScript has done backwards-compatibility changes to accommodate new ES syntaxes. [12:52:27.0973] * As far as I know, TC39 has never considered TypeScript, Flow, etc. to be hard blockers on potential new future syntax, and TypeScript has done backwards-compatibility changes to accommodate new ES syntaxes. [12:52:30.0497] * As far as I know, TC39 has never considered TypeScript, Flow, etc. to be hard blockers on potential new future ES syntax, and TypeScript has done backwards-compatibility changes to accommodate new ES syntaxes. [12:52:45.0282] yeah, we do *soft* avoidance of clashes, for politeness' sake, but that's it [12:53:09.0662] TypeScript and Flow have the luxury of language versioning, haw. [12:53:18.0992] * TypeScript and Flow have the luxury of language versioning, haw. [12:54:08.0318] TypeScript can break stuff between minor versions (since the versioning is 2.9 -> 3.0). [12:54:19.0100] And a new TS version is released every 2 months IIRC. [12:56:37.0781] I believe that Flow and TS would really really want an ergonomic type to define tuples and records. Preferably the same syntax as in JS. [12:56:57.0944] Flow is also moving for types to be closed by default [12:57:12.0902] so the `{| |}` flow type syntax is actually semi deprecated [12:57:40.0366] For Flow, it seems like it would be a breaking change to change `{| |}` behaviour, but it should be pretty easy to fix through something like codefix. [12:57:43.0032] That said I don't think the reason R&T was not using that syntax was because of the clash with Flow. [12:58:55.0003] `{| |}` has the disadvantage that it's not as ergonomic to change objects -> records and vice-versa since you have two places to edit. [13:01:42.0561] > <@aclaymore:matrix.org> That said I don't think the reason R&T was not using that syntax was because of the clash with Flow. See also https://github.com/tc39/proposal-record-tuple/issues/10. [13:02:12.0623] > <@jschoi:matrix.org> See also https://github.com/tc39/proposal-record-tuple/issues/10. dw I've read almost every comment of every issue in the RT repo ;) [13:02:39.0498] my colleagues are the champions, so I take an active interest :) [13:06:01.0215] Though, it feels like flow's `{| a: string |}` is for a use case that feels extremely rare: for `const foo: {| a: string |} = { a: 'a', b: 1 }; // Error`. Maybe someone could scour existing flow projects for them. [13:07:07.0757] Wasn't Flow mainly used at Facebook? maybe we can ask for someone who has access to their repo. [13:11:21.0743] As I said earlier, flow is moving towards 'exact types by default' https://medium.com/flow-type/on-the-roadmap-exact-objects-by-default-16b72933c5cf [13:11:58.0740] so `{| a: string |}` in Flow can be replaced with `{ a: string }` and you opt-out of it with `{ a: string, ... }` [13:22:13.0210] why does it matter if flow conflicts? flow isn't js. [13:22:59.0394] that's just the risk things take when they extend JS syntax in any but the one way reserved for that purpose (the `:` type annotation stuff) altho in this case it's flow's type syntax, so JS having that syntax in a value context wouldn't even conflict in a technical sense, just a conceptual one. [13:23:00.0535] * so `{| a: string |}` in Flow can be replaced with `{ a: string }` and you opt-out of it with `{ a: string, ... }` [13:23:30.0273] * that's just the risk things take when they extend JS syntax in any but the one way reserved for that purpose (the `:` type annotation stuff) altho in this case it's flow's type syntax, so JS having that syntax in a value context wouldn't even conflict in a technical sense. [13:23:36.0215] * that's just the risk things take when they extend JS syntax in any but the one way reserved for that purpose (the `:` type annotation stuff) altho in this case it's flow's type syntax, so JS having that syntax in a value context wouldn't even conflict in a technical sense, just a conceptual one. [13:23:38.0997] > <@aclaymore:matrix.org> As I said earlier, flow is moving towards 'exact types by default' > https://medium.com/flow-type/on-the-roadmap-exact-objects-by-default-16b72933c5cf Exact types is pretty weird for me, although I've done something similar in TypeScript. I've been thinking of typing in JS and TS as "if it has the required properties, then it fulfills the type". There is a risk of polluting naive code with extra properties, but the type system is not the shield against it. [13:24:18.0940] ¯\\\_(ツ)_/¯ in react propTypes, using exact types has caught innumerable bugs, including typos on optional prop names, so i think there's tons of value in that being the default in a type system. [13:25:23.0511] * ¯\\\_(ツ)_/¯ in react propTypes, using exact types has caught innumerable bugs, including typos on optional prop names, so i think there's tons of value in that being the default in a type system. [13:26:23.0545] > <@ljharb:matrix.org> that's just the risk things take when they extend JS syntax in any but the one way reserved for that purpose (the `:` type annotation stuff) > > altho in this case it's flow's type syntax, so JS having that syntax in a value context wouldn't even conflict in a technical sense, just a conceptual one. yep it is only a conceptual clash for people reading it, and isn't the syntax Flow is sticking with going forwards. So Flow isn't the issue here. [13:33:14.0702] > <@tabatkins:matrix.org> I'm fine with holding onto `#` as an explicit stretch goal FYI, I added `#` back to the table of candidates in https://github.com/tc39/proposal-pipeline-operator/wiki/Bikeshedding-the-Hack-topic-token/. [13:38:19.0094] After having followed many different ECMAScript proposals, is there a FAQ counterargument against the "syntax soup" -argument that is pretty common? Basically explaining that we don't even need ECMAScript 3 to tailor unreadable code. [13:39:27.0038] Argument soup? You mean ASCII soup? [13:40:12.0421] * After having followed many different ECMAScript proposals, is there a FAQ counterargument against the "syntax soup" -argument that is pretty common? Basically explaining that we don't even need ECMAScript 3 to tailor unreadable code. [13:46:33.0776] As in I don't think people should care about readability of code that hasn't had any readability in mind when it was written. [13:47:01.0596] There isn't a counter-argument; it's a valid argument. [13:47:45.0121] Perl is an existence proof of what JS should not become in regular usage. How quickly we get there is individually arguable, but we all agree it's a bad endpoint, and every new syntax addition pushes us there. [13:48:29.0311] Yes. Any new proposal has to be compelling enough to override the fact that any new feature adds more weight to the language. See https://erights.medium.com/the-tragedy-of-the-common-lisp-why-large-languages-explode-4e83096239b9 [13:49:03.0427] Many of us happen to believe that the benefits of the pipe operator outweighs its cost, but there is no denying that there is at least some cost. [13:49:12.0463] Same goes for any proposal. [13:51:18.0869] My point was mostly the most recent `^^^` -example. When people don't bother adding a space, they haven't written the code with an intention of having it simple to read. [13:51:35.0387] I’ve seen a counterargument from Rob Palmer though against “you can sometimes create unreadable code with this”. His counterargument is that any reasonably powerful language feature can create difficult-to-read code. Like `[[[], [[], [], [[]], []], [[]]]`. [13:52:38.0628] * I’ve seen a counterargument from Rob Palmer though against “you can sometimes create unreadable code with this”. His counterargument is that any reasonably powerful language feature can create difficult-to-read code. Like `[[[], [[], [], [[]], []], [[]]]`. [13:53:06.0163] So I would rather focus on cases where making a easily readable version is cumbersome to write. [13:58:31.0623] So in my opinion, less weight should be put on "most complex syntax soup I could write", some weight for "I naturally wrote this code and after I wrote it, I realized that it needed clarification" and most for "Writing this often occurring operation is pain to write clearly." [13:58:54.0935] * So in my opinion, less weight should be put on "most complex syntax soup I could write", some weight for "I naturally wrote this code and after I wrote it, I realized that it needed clarification" and most for "Writing this often occurring operation is pain to write clearly." [14:05:04.0934] In comparison, balancing a dozen parenthesis for multiple nested function calls (which is not a rare to end up with) in my mind is vastly more difficult than almost any realistic usage of any suggested topic placeholder topic. [14:13:09.0195] Yes, that's more or less how we respond to such an argument. 2021-12-14 [07:30:56.0149] https://github.com/tc39/proposal-record-tuple/issues/10#issuecomment-993130019 [07:30:57.0877] Looks like a record/tuple champion is still willing to consider `@[ … ]`, `[| … |]`, and `[| … ]` as alternatives to `#[ … ]`. So `#` as the topic reference is still in the running. [07:31:33.0879] * Looks like a record/tuple champion is still willing to consider `@[ … ]`, `[| … |]`, and `[| … ]` as alternatives to `#[ … ]`. So `#` as the topic reference is still in the running. [08:38:39.0875] I prefer `#[` over `[|`, but I also prefer `|> #`over the two-tokens alternatives 😂 We could also just live with the conflict.`|> #[0]`will be a syntax error because the topic token is not used, and you will have to write`|> (#)[0]`. The only silent bug is when you want to use `#`twice and only once it's in a computed property access (for example,`|> #[#.length - 1]`, but it doesn't feel common: this is the only realistic example I could come up with, but we now have `#.at(-1)`. [08:38:51.0321] * I prefer `#[` over `[|`, but I also prefer `|> #`over the two-tokens alternatives 😂 We could also just live with the conflict.`|> #[0]`will be a syntax error because the topic token is not used, and you will have to write`|> (#)[0]`. The only silent bug is when you want to use `#`twice and only once it's in a computed property access (for example,`|> #[#.length - 1]`, but it doesn't feel common: this is the only realistic example I could come up with, but we now have `#.at(-1)`. [08:39:03.0471] What about `@[`? [08:39:51.0167] (I will also say that I expect `#[0]` to actually be fairly common. At least for me. I would do it often.) [08:39:53.0662] It's slightly worse than `#[` because `@(`,`@[` and `@{` look related but `@(` is a completely different thing [08:40:12.0424] Yes but you would get a syntax error and not a runtime bug [08:40:23.0806] > <@jschoi:matrix.org> (I will also say that I expect `#[0]` to actually be fairly common. At least for me. I would do it often.) * Yes but you would get a syntax error and not a runtime bug [08:41:37.0792] Btw, would `@` work for pipes too? (searching in the long issue about topic bikeshedding doesn't help because it finds all the usernames) [08:41:43.0671] > <@nribaudo:igalia.com> It's slightly worse than `#[` because `@(`,`@[` and `@{` look related but `@(` is a completely different thing Well, is `@(` really that big of a deal? Since `@(` won’t be very common… [08:41:45.0663] * Btw, would `@` work for pipes too? (searching in the long issue about topic bikeshedding doesn't help because it finds all the usernames) [08:41:56.0263] …and decorators and records/tuples will not be closely mixed often. [08:42:02.0502] > <@jschoi:matrix.org> Well, is `@(` really that big of a deal? Since `@(` won’t be very common… No, that's why I said _slightly_ 😛 [08:42:09.0322] In contrast, private fields and records/tuples may well be mixed often. I give an example in that comment I link above. [08:42:11.0265] Yeah, haha. [08:42:19.0161] All of these slight trade offs… [08:42:22.0611] `@[` is definitely better than `[|`, at least for me (single char rather than two to move from arrays to tuples) [08:42:39.0388] `@` does not work for pipes because of `@()`’s ambiguity with decorators. [08:42:44.0383] * `@[` is definitely better than `[|`, at least for me (single char rather than two to move from arrays to tuples) [08:43:04.0654] Although, yes, we could do the same thing as you suggest with `#` and force parentheses for the function call `(@)()`. I do not much like this sort of solution though. [08:43:16.0230] Because of ASI? [08:43:22.0431] > <@jschoi:matrix.org> `@` does not work for pipes because of `@()`’s ambiguity with decorators. * Because of ASI? [08:43:38.0548] I believe so, although I need to double check. [08:44:03.0044] Uh ok ```js x |> @(1) class A {} [08:44:15.0764] Yes. [08:44:27.0601] It's the same kind of ambiguity as ``` 1 [x] ``` [08:44:34.0160] Where you are forced to put a semicolon [08:45:01.0886] Yep. (Also there’s Getify’s suggestion of `[| … ]`, so yeah. But I do like `@[ … ]`.) [08:45:32.0406] I prefer `@[` because `[|...]` seems visually unbalanced [08:45:45.0306] Yes, it does look visually unbalanced. [08:47:43.0757] By the way, Nicolò, did you want me to rebase that Babel pull request for `^^` and `@@`? [08:47:51.0912] Since you were waiting on that decorators call. [08:48:08.0104] > <@jschoi:matrix.org> Since you were waiting on that decorators call. Whops sorry [08:48:19.0785] I want to wait to see what the committee says about `@init:` [08:48:27.0325] Ah, the plenary today, okay. [08:48:33.0495] Sounds good. [08:48:38.0126] Tomorrow I think [08:48:51.0601] We will see. The schedule is packed indeed… [08:49:00.0426] I’ll also start work on support for Babel records-and-tuples support for `@[ … ]` sometime. [10:31:34.0956] > <@jschoi:matrix.org> (I will also say that I expect `#[0]` to actually be fairly common. At least for me. I would do it often.) Yes, I think `#[...]` will be too common of an expression for us to allow it to be a syntax error. [10:32:11.0251] Wait, is tuples seriously considering `[|...]` as an option, rather than `[|...|]`??? [10:32:21.0988] That seems untenable personally [10:32:56.0438] Nope, it is just one of the options mentioned in the R&T syntax thread (not by a champion) [10:33:02.0615] * Nope, it is just one of the options mentioned in the R&T syntax thread (not by a champion) [10:34:26.0617] okay, phew [10:35:42.0141] `@tuple [ … ]` >:) [10:42:13.0928] Actually, no, even better: `[ … |]`. [10:42:42.0482] Extend all the things via keywords. `@tuple [...]` for tuples, `@topic` for pipeline, there are no downsides. [10:43:02.0063] > <@jschoi:matrix.org> Actually, no, even better: `[ … |]`. luv2see unbounded lookahead [11:29:49.0633] Nice, Tab. 2021-12-15 [14:30:41.0492] We could do Records and Tuples better by not introducing any new characters at all: `{ ... ]` for records and `[ ... }` for tuples. If you disagree with this, we'll go with swapped syntax instead. [14:42:48.0458] how would that be better [14:43:05.0307] that'd make likely mismatching bugs suddenly become valid syntax with wildly different semantics [14:47:47.0628] Reminds me of the [a, b) and (a, b] notations for intervals. https://en.wikipedia.org/wiki/Interval_(mathematics)#Notations_for_intervals [14:47:50.0607] Incidentally, those are two of my least favorite math syntaxes, haha. [14:48:04.0471] Sorry, Pokute, I don’t think it’s a good idea, but it was worth a shot. : ) [14:50:07.0762] ljharb: you, uh, might be missing the tongue that's in the cheek there [14:51:25.0854] Well, I was a bit late coming up with it. [14:54:02.0615] lol i clearly did miss it 2021-12-23 [19:44:43.0922] I’ve made a diagram that tries to map the problem space of the five “dataflow” TC39 proposals and their overlaps in functionality. Hopefully this would be the start of a productive discussion about how to holistically consider these features. Pinging Richard Gibson and yulia | back Jan. 3 since this was an explicit concern from them in prior plenary meetings. [19:44:49.0467] * I’ve made a diagram that tries to map the problem space of the five “dataflow” TC39 proposals and their overlaps in functionality. Hopefully this would be the start of a productive discussion about how to holistically consider these features. Pinging Richard Gibson and yulia | back Jan. 3 since this was an explicit concern from them in prior plenary meetings. [19:45:16.0714] Also pinging HE Shi-Jun and rbuckton since it also involves two of their proposals too. [21:26:07.0559] * I’ve made a diagram that tries to map the problem space of the five “dataflow” TC39 proposals and their overlaps in functionality. (It’s a work in progress; it’s not yet done.) Hopefully this would be the start of a productive discussion about how to holistically consider these features. Pinging Richard Gibson and yulia | back Jan. 3 since this was an explicit concern from them in prior plenary meetings. 2021-12-24 [22:15:06.0647] https://jschoi.org/21/es-dataflow/ [22:16:20.0633] https://jschoi.org/21/es-dataflow/ [22:17:33.0258] …I’m not sure why the title is showing up in Matrix, but I wrote a text comparison and updated the diagram. [22:17:37.0525] Updated image: https://jschoi.org/21/es-dataflow/map/ [22:20:08.0841] * …I’m not sure why the title is showing up incorrectly in Matrix, but I wrote a text comparison between the five proposals and updated the diagram. [22:20:13.0345] * Updated diagram: https://jschoi.org/21/es-dataflow/map/ [10:39:25.0187] thank you jschoi ! I really appreciate the effort put into that broad analysis [11:41:30.0710] The diagram doesn’t load for me; it says there’s an ssl error [11:43:33.0050] I’ll look into that later, but here’s the image as a file: [11:48:01.0085] http://cdn.glitch.me/fce49fe7-f83b-4170-90d5-ab11ebc3ff25/21--es-dataflow--map.png worked tho, once i clicked through a scary browser warning