| 00:02 | <jackworks> | ljharb: |
| 00:02 | <jackworks> | I'm interesting join to help pattern matching, how can I help? 🤔 |
| 00:02 | <devsnek> | ljharb: ^ |
| 00:02 | <ljharb> | jackworks: thanks, i'll tag you on the issue i file |
| 00:02 | <ljharb> | devsnek: you too? |
| 00:03 | <devsnek> | i'll happily discuss it |
| 00:03 | <devsnek> | not sure about championing |
| 00:03 | <ljharb> | kk |
| 00:04 | <devsnek> | ljharb: to be clear i really love pattern matching and i want it in the language |
| 00:04 | <ljharb> | noted :-) |
| 00:05 | <jackworks> | +1 love pattern matching and waiting it for years |
| 15:05 | <renatoalencar> | hi |
| 15:05 | <renatoalencar> | anyone here? |
| 15:07 | <jmdyck> | I'm here. |
| 15:09 | <renatoalencar> | I was mapping Sequelize models to object like { attribute: type }, in order to create a serializer or something. So I was doing this: Object.fromEntries(Object.entries(model).map(([key, value]) => [key, value.type])) in order to achieve this. |
| 15:11 | <renatoalencar> | The question is: since I'm already using method chaining to get and map entries from attributes, I guess we could use some synthatic sugar in order to map this to Object.fromEntries intead of having an external function call. Like, we could enjoy the clean view of method chaining. |
| 15:12 | <renatoalencar> | I was thinking about creating proposal to a new Object method: Object.prototype.self. |
| 15:12 | <renatoalencar> | So instead of having something like this |
| 15:13 | <renatoalencar> | Object.fromEntries(Object.entries(model).map(([key, |
| 15:13 | <renatoalencar> | value]) => [key, value.type])) |
| 15:13 | <renatoalencar> | * sorry * |
| 15:13 | <renatoalencar> | I would have something like this |
| 15:13 | <devsnek> | we don't add things to Object.prototype anymore |
| 15:13 | <renatoalencar> | Object.entries(model).map(([key, value]) => [key, value.type]).self(Object.fromEntries) |
| 15:15 | <renatoalencar> | Which is much cleaner |
| 15:15 | <devsnek> | but then you have this `self` property on every single object |
| 15:18 | <renatoalencar> | That's really an issue, I didn't think about it. |
| 15:30 | <bradleymeck> | Seems like pipeline operator could also help |
| 15:33 | <renatoalencar> | bradleymeck: That's great, it solves my problem. |
| 16:01 | <jridgewell> | Wasn’t there an `Object.map` proposal presented recently? |
| 16:09 | <rickbutton> | was it the one that got transformed into "object iteration"? |
| 16:09 | <rickbutton> | https://github.com/tc39/proposal-object-iteration |
| 16:17 | <Bakkot> | with object iteration and a slight extension of the iterator helpers proposal ("collect"), you'd write `Object.iterate(model).map(...).collect(Object.fromEntries)` |
| 16:41 | <renatoalencar> | `collect` is very interesting |
| 16:47 | <renatoalencar> | And `collect` sounds a lot more semantically correct than `self` |
| 17:15 | <Bakkot> | mathiasbynens ping |
| 17:17 | <mathiasbynens> | Bakkot: pong |
| 17:22 | <Bakkot> | mathiasbynens actually I guess I didn't have anything further to say |
| 17:23 | <mathiasbynens> | Bakkot: fair enough |
| 17:23 | <Bakkot> | just was trying to move the discussion here |
| 17:23 | <Bakkot> | but then I didn't have more discussion |
| 17:23 | <mathiasbynens> | there's this thing where if people walk through a doorway they tend to forget what they were doing before |
| 17:23 | <mathiasbynens> | i posit this applies to irc channels as well |
| 17:25 | <Bakkot> | I added a new slides listing possible goals: https://docs.google.com/presentation/d/1COuuP_0fxK_s8-H8AScDMjMzKSEiAlAnOi4snP-OiHY/edit#slide=id.g82bd3e5bae_15_10 |
| 17:26 | <Bakkot> | my intention is to say that I regard the first two goals here as violated only for users who actually try to write unicode escapes for non-BMP characters , who I think are rare enough (and the harm in that case is sufficiently slight) that the other cost to the other goals should outweigh them |
| 17:29 | <mathiasbynens> | "The only reasons to ban these are that it hurts symmetry or exposes users to a concept we want to shield them from. But the number of users affected will be vanishingly small." not the only reasons; this aligns perfectly with ES2015 `u` |
| 17:29 | <Bakkot> | how is that not "hurts symmetry"? |
| 17:30 | <mathiasbynens> | resulting in 0 changes to the mental model |
| 17:30 | <Bakkot> | again, how is that not "hurts symmetry"? |
| 17:30 | <mathiasbynens> | it's completely orthogonal to that |
| 17:30 | <Bakkot> | I guess I don't know what you mean then. |
| 17:31 | <mathiasbynens> | you already know what i mean by symmetry |
| 17:31 | <Bakkot> | I thought what you meant was, you want this thing to be like that other thing, so that the mental model is simpler |
| 17:31 | <Bakkot> | but now I am no longer sure |
| 17:31 | <mathiasbynens> | ok let me try again |
| 17:32 | <mathiasbynens> | sorry i'm not being clear, i swear it all makes sense in my head |
| 17:32 | <mathiasbynens> | by symmetry, I mean the thing where you can copy-paste the sourcetext that makes up any valid group name from within the regexp pattern to `match.groups.<HERE>` without ending up with invalid code |
| 17:33 | <mathiasbynens> | does that make sense? |
| 17:33 | <Bakkot> | Sure, got it |
| 17:33 | <mathiasbynens> | proposal 3 has this property |
| 17:34 | <Bakkot> | agreed |
| 17:34 | <mathiasbynens> | but it gets there by aligning with ES2015 `u`, as in: `u` makes astral symbols work in `u` regexps, and this becomes another example of that |
| 17:35 | <mathiasbynens> | resulting in the simplest possible mental model |
| 17:35 | <Bakkot> | OK |
| 17:35 | <mathiasbynens> | proposal 4 (allowing \u\u even in identifiers) also has the symmetry property, but at the cost of a much more difficult mental model |
| 17:35 | <Bakkot> | when I said "symmetry" in that slide, I meant to refer to both of those things |
| 17:36 | <mathiasbynens> | i understand. i'm trying to explain why i see them as two separate things (and why i listed them separately in my proposal) |
| 17:36 | <Bakkot> | yeah |
| 17:36 | <Bakkot> | there are two different concrete properties, agreed |
| 17:36 | <Bakkot> | but they are both examples of, I want this thing to be like this other thing to simplify how many things the user has to know to know everything |
| 17:37 | <Bakkot> | and my position is, with the allow-all-escapes proposal, users will only be exposed to the asymmetry if they try to write (not just read) unicode escapes for non-astral characters |
| 17:37 | <Bakkot> | sorry, that is, users will only be exposed to _ether of those_ asymmetries |
| 17:45 | <mathiasbynens> | so do you want to add "simpler mental model" to your slide? |
| 17:45 | <mathiasbynens> | or "smaller mental model delta" or w/e |
| 17:46 | <Bakkot> | My intention was that that would be covered by "symmetry" |
| 17:46 | <Bakkot> | since that is why we care about symmetry |
| 17:55 | <mathiasbynens> | heh, i thought we just agreed they were distinct properties |
| 17:55 | <Bakkot> | I agreed that there are two concrete properties which are distinct: having symmetry between the group name in the regex and in the code, and having symmetry with the rest of how u and non-u regexes work |
| 17:55 | <Bakkot> | but these are both symmetry |
| 17:55 | <Bakkot> | and the reason we care about symmetry is, it keeps the mental model simple |
| 17:56 | <mathiasbynens> | not in the case of proposal 4 |
| 17:57 | <mathiasbynens> | "An astral code point can always be represented as \u𝘏𝘌𝘈𝘋\u𝘛𝘈𝘐𝘓, and additionally as the more convenient \u{…} except in old-style non-u regular expressions." is quite a mouthful |
| 17:58 | <Bakkot> | yes, there is yet another kind of symmetry possible, which is symmetry between how the group name works and the rest of the regex works |
| 17:58 | <Bakkot> | (that's the one gibson042 has expressed the most interest in, for example) |
| 17:59 | <gibson042> | allowing \u{ to name capture groups in non-Unicode regexes does not simplify that |
| 17:59 | <Bakkot> | yes |
| 17:59 | <Bakkot> | I agree with that |
| 17:59 | <Bakkot> | I am proposing to make it slightly more complicated - to break that particular symmetry - in service of other goals |
| 18:00 | <gibson042> | understood |
| 18:04 | <mathiasbynens> | Bakkot: yes, proposal 3 gets at that kind of symmetry as well: either astral symbols are supported (`u`), or they aren't (non-`u`) |
| 18:04 | <Bakkot> | yup, I agree that proposal 3 has the most symmetry |
| 18:04 | <Bakkot> | I am proposing to break that symmetry in service of other goals |
| 18:08 | <Bakkot> | mathiasbynens gibson042: concretely, if you were given a choice ONLY between making /(?<\u{1d49c}>.)/ legal or illegal, with all of /(?<\ud835\udc9c.)/ /(?<\ud835\udc9c.)/u /(?<\u{1d49c}>.)/u being definitely legal, which is your preference? |
| 18:09 | <mathiasbynens> | Bakkot: illegal. astral support requires `u` flag. matches implementations too |
| 18:09 | <Bakkot> | mathiasbynens in this hypothetical, /(?<\ud835\udc9c.)/ is legal. |
| 18:10 | <Bakkot> | sorry, /(?<\ud835\udc9c>.)/, rather |
| 18:10 | <Bakkot> | so in this hypothetical, "astral support requires `u` flag." is false |
| 18:10 | <Bakkot> | given that, is that still your preference? |
| 18:10 | <mathiasbynens> | hmmm, not sure. where does the hypothetical come from? |
| 18:11 | <Bakkot> | OK also I guess I should extend my hypothetical to say that /(?<𝒜>.)/ is also definitely legal |
| 18:11 | <mathiasbynens> | oh no |
| 18:11 | <Bakkot> | this hypothetical comes from, I am going to propose exactly one of these two things |
| 18:12 | <Bakkot> | of these six regexes, five of them I am definitely going to propose should be legal. the sixth, /(?<\u{1d49c}>.)/, I think we could go either way. |
| 18:12 | <mathiasbynens> | i think you should present all the options that were discussed, and then pick your favorite, not provide the committee with just 2 options pretending there's no other way |
| 18:12 | <Bakkot> | I'm not going to present to the commitee just these two options |
| 18:12 | <Bakkot> | I am going to present exactly one of these options as the thing I am going for, and discuss many other options |
| 18:12 | <Bakkot> | but I am trying to decide which of two options I present as my favorite |
| 18:13 | <Bakkot> | based on which I think is most likely to get consensus |
| 18:13 | <Bakkot> | which I am hoping to base on which, of those two, you and gibson042 prefer |
| 18:13 | <mathiasbynens> | Bakkot: i prefer keeping `\u{...}` non-special in non-`u` regexps |
| 18:13 | <mathiasbynens> | like, that's one of the reasons we added the `u` flag |
| 18:14 | <mathiasbynens> | i get that we _could_ special-case this one thing if we really wanted to, but imho we shouldn't |
| 18:14 | <Bakkot> | even if \u\u and 𝒜 work? |
| 18:15 | <mathiasbynens> | yes |
| 18:15 | <Bakkot> | ok cool |
| 18:15 | <mathiasbynens> | (although i do think this proposal doesn't make sense) |
| 18:15 | <mathiasbynens> | not too long ago you said "I'm happy either way" https://github.com/tc39/ecma262/pull/1869#issuecomment-583982299 :') |
| 18:16 | <Bakkot> | yeah, that was before waldemar pointed out the tooling concern, which had not occurred to me but which I regard as having nontrivial weight |
| 18:17 | <Bakkot> | I was previously unconcerned because I regarded this as only affecting users who tried to write unicode escapes in group names, which I expect to be a tiny population and so the decision was unimportant |
| 18:17 | <Bakkot> | but waldemar correctly points out that it also affects tooling, which has significantly larger impact, so now I think it does matter |
| 18:19 | <mathiasbynens> | fair |
| 18:19 | <mathiasbynens> | prop 3 addressed all that |
| 18:19 | <mathiasbynens> | but yeah, the requirements keep coming |
| 18:19 | <mathiasbynens> | maybe we shouldn't block es2020 on this |
| 18:19 | <mathiasbynens> | there's really no rush |
| 18:20 | <Bakkot> | I would love to not block es2020 on this |
| 18:20 | <mathiasbynens> | let's do it |
| 18:20 | <Bakkot> | but, unfortunately, making that decision requires convincing waldemar that we should |
| 18:20 | <Bakkot> | which several people tried to do for like an hour after the meeting last night, to no avail |
| 18:20 | <Bakkot> | so I am hoping to route around forcing that issue |
| 18:20 | <mathiasbynens> | if it makes people feel better, include a note in the spec saying that there is an inconsistency that is being addressed with a link to the github issue or something |
| 18:20 | <mathiasbynens> | oh ok :/ |
| 18:21 | <mathiasbynens> | maybe it helps to not point these things out in future editor updates |
| 18:21 | <Bakkot> | yeah I guess |
| 18:21 | <Bakkot> | well |
| 18:21 | <mathiasbynens> | "last known bug in the spec" |
| 18:21 | <mathiasbynens> | it really doesn't matter |
| 18:21 | <Bakkot> | it wasn't really an editor update thing |
| 18:21 | <gibson042> | Bakkot: my preference would be to disallow `/(?<\u{1d49c}>.)/`, but I won't block consensus if there's broad support for it |
| 18:29 | <bradleymeck> | shu: https://github.com/hax/proposal-function-this/issues/2 |
| 18:30 | <mathiasbynens> | Bakkot: it's also worth noting that a smaller change doesn't preclude us from making bigger changes later. otoh if we make the big change first, we likely won't be able to go back |
| 18:31 | <Bakkot> | no one will ever want to revisit this |
| 18:31 | <Bakkot> | I am not going to present something which says we might come back to it |
| 18:31 | <mathiasbynens> | Bakkot: you're asking for a pretty big change, and there is pressure with the whole ES2020 thing |
| 18:32 | <Bakkot> | I do not regard this as a big change. |
| 18:33 | <Bakkot> | I regard the details of which escape sequences are allowed as being a very small detail which will affect only tooling authors and perhaps a dozen humans writing code. (which non-escape characters are allowed affects far more people, of course.) |
| 18:35 | <Bakkot> | (sorry, specifically, which escape sequences are allowed _in named capture group names_. which are allowed in identifiers would be a larger change but I am not asking for a change there.) |
| 18:43 | <mathiasbynens> | I'm talking about supporting astral symbols in non-`u` RegExps in this case (in escaped form or not) |
| 18:44 | <Bakkot> | The spec explicitly permits non-escaped astral symbols in non-u regexes in capture group names; there is no possible ambiguity there. |
| 18:44 | <Bakkot> | We have consensus on that decision. |
| 18:51 | <mathiasbynens> | ack |
| 19:17 | jackworks | sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/yvvzqpdTpoHfygyQXbrYRQHB > |
| 19:23 | <bradleymeck> | jackworks: not to my knowledge |
| 19:23 | <Bakkot> | it came up on es-discuss some time back, I think |
| 20:46 | <TabAtkins> | Yeah, there's been discussion for it. |
| 20:46 | <TabAtkins> | (It's a great idea imo, tho I'd like a slightly different syntax.) |
| 20:46 | <TabAtkins> | (Line/indent-based syntax is a no-go for JS.) |
| 20:48 | <TabAtkins> | repurpose `with()` block imo |
| 20:49 | <rkirsling> | fwiw it doesn't require newlines in Dart |
| 20:49 | <devsnek> | it was blocked by nothing in the jsstdlib being usable with it |
| 20:49 | <devsnek> | well not "blocked" |
| 20:49 | <devsnek> | but demotivated |
| 20:52 | <jackworks> | imo we just need to change another symbol for it (`..` maybe not good with JS). and the dart style doesn't seems to related with indent. |
| 20:54 | <ljharb> | i'm a bit confused how it works |
| 20:55 | <ljharb> | is it a chain of expressions? |
| 20:55 | <ljharb> | how do asi/semis fit in |
| 20:55 | <devsnek> | it's a chain of member expressions |
| 20:55 | <devsnek> | same rules as one dot instead of two |
| 20:56 | <devsnek> | except the base of each one becomes the first item |
| 20:56 | <ljharb> | the assignment isn't that |
| 20:56 | <devsnek> | hm i didn't know you could do assignment in that |
| 20:56 | <ljharb> | also `..classes.add(…)` isn't a member expression |
| 20:56 | <ljharb> | it |
| 20:56 | <ljharb> | * it's a full expression |
| 20:57 | <devsnek> | that's a member expression |
| 20:57 | <rkirsling> | well it's an access and call chain |
| 20:57 | <rkirsling> | you can't use operators there, say |
| 20:57 | <ljharb> | devsnek: ok so the `..` chain is a chain of member expressions? |
| 20:57 | <devsnek> | that's what i expected anyway |
| 20:57 | <devsnek> | the assignment is weird |
| 20:57 | <ljharb> | how would optional chains fit in |
| 20:57 | <rkirsling> | it's called a "cascade" btw, just for helpful verbiage's sake |
| 20:57 | <devsnek> | but seems reasonable i guess??? |
| 20:58 | <ljharb> | like how is this better than just a list of statements, repeating the object |
| 20:58 | <rkirsling> | Dart has `?.` too so you can see |
| 20:59 | <devsnek> | someone quick go implement cascade in engine262 |
| 20:59 | <rkirsling> | err wait |
| 20:59 | <rkirsling> | that assignment _is_ weird |
| 20:59 | <rkirsling> | I didn't realize Dart even allowed that |
| 20:59 | <rkirsling> | we wouldn't have to |
| 20:59 | <devsnek> | yeah but modulo that |
| 20:59 | <rkirsling> | I don't think I support that part of it |
| 21:00 | <rkirsling> | but otherwise, "calling a bunch of things in succession on a single receiver object" is nice |
| 21:00 | jackworks | sent a long message: < https://matrix.org/_matrix/media/r0/download/matrix.org/qKaRPpWHbkFwQcUApJzlYFBe > |
| 21:00 | <ljharb> | jackworks: heads up that matrix turns your long messages into a link i have to click instead of showing text inline |
| 21:00 | <rkirsling> | ^ |
| 21:00 | <devsnek> | jackworks: btw your messages are appearing as "jackworks sent a long message <url>" |
| 21:00 | <devsnek> | and we have to click out to matrix.org to read your messages |
| 21:00 | <ljharb> | jackworks: yeah i do think that it's an asi problem |
| 21:00 | <Bakkot> | ljharb wait what's the ASI problem |
| 21:00 | <ryzokuken> | matrix yay :P |
| 21:01 | <devsnek> | i don't see an asi problem |
| 21:01 | <ljharb> | Bakkot: well i mean, conceptually, i'm sure the grammar can work |
| 21:01 | <Bakkot> | what's the conceptual problem |
| 21:01 | <ljharb> | because it looks like a bunch of statements, where `..` is the value of the last statement before all the double dot statements |
| 21:01 | <ljharb> | or a bunch of expressions |
| 21:01 | <Bakkot> | you can do `.method()` on a new line; being able to do `..method()` on a new line is... pretty much exactly the same thing, no? |
| 21:01 | <ljharb> | but with a multiline chain item, i think it'll be very confusing |
| 21:01 | <ljharb> | oh sure |
| 21:02 | <rkirsling> | yes |
| 21:02 | <devsnek> | ljharb: can you give an example |
| 21:02 | <ljharb> | but `.method` is "get method off of the thing it's dotted onto" |
| 21:02 | <devsnek> | i don't get what the confusion is |
| 21:02 | <ljharb> | let's ignore that confusion for now, i'll make an example if this idea gets more written out :-) |
| 21:02 | <jackworks> | oh I'm sorry, it only 296 words why matrix think it's long (maybe cause there are 2 code blocks in the msg) |
| 21:03 | <devsnek> | jackworks: i'm guessing its the newlines |
| 21:04 | <rkirsling> | again for the record, I think it's a great idea for access and call chains; the `=` part makes me frown |
| 21:04 | <Bakkot> | fwiw I don't think this feature is worth it |
| 21:05 | <Bakkot> | syntax which is aimed at not having to declare and refer to variables almost never seem worth it to me |
| 21:05 | <devsnek> | it's neat |
| 21:05 | <Bakkot> | agreed |
| 21:06 | <devsnek> | that's about all i can say about it |
| 21:06 | <rkirsling> | it is very useful for certain patterns that aren't necessarily common in JS, like StringBuilder |
| 21:06 | <devsnek> | i'm not sure its a good pattern for builders |
| 21:06 | <devsnek> | taking into account stuff like luxon |
| 21:06 | <devsnek> | where each method returns a new instance |
| 21:06 | <Bakkot> | rkirsling builders usually just return the instance from each method and it's not a problem |
| 21:07 | <rkirsling> | er yeah that's fair |
| 21:07 | <rkirsling> | but the DOM element example that jackworks gave is quite relevant |
| 21:08 | <rkirsling> | I was just giving the one example I could demonstrate with the Dart code that I've personally written 😓 |
| 21:08 | <Bakkot> | the dom example requires appendTo existing, which it doesn't :P |
| 21:08 | <jackworks> | `console.log(date.withCalendar("japanese").era); // "reiwa"` shouldn't it return "令和" instead of "reiwa"? |
| 21:08 | <rkirsling> | here's a thing that generates AST node classes from a YAML file: https://github.com/rkirsling/dlox/blob/master/tool/generate_ast.dart |
| 21:08 | <Bakkot> | in actual fact you'd still have to put it in a variable and then do parent.append(variable) |
| 21:09 | <rkirsling> | jackworks: yeah that's what michaelficarra asked too |
| 21:09 | <rkirsling> | probably the two-in-one character though |
| 21:09 | <rkirsling> | ㋿ |
| 21:10 | <michaelficarra> | yeah it specifically should be the square era name |
| 21:12 | <jackworks> | lol |
| 21:29 | <mpcsh> | can we add "reify" to https://github.com/tc39/how-we-work/blob/master/terminology.md ? |
| 21:32 | <jridgewell> | Are you looking for a definition? |
| 21:32 | <jridgewell> | Yes, we should add it. |
| 21:32 | <ljharb> | mpcsh: be the change you want to see in the world |
| 21:33 | <mpcsh> | (I don't know what the term means, which is why I was asking here) |
| 21:33 | <jridgewell> | Currently `this.#foo` exists only as syntax |
| 21:33 | <Bakkot> | we should indeed add it. the meaning is, to give a language-level value to, which could be inspected and passed around as any other value could |
| 21:33 | <jridgewell> | `#foo` isn’t actually a property key |
| 21:33 | <ljharb> | mpcsh: ah ok fair |
| 21:34 | <jridgewell> | And doesn’t have a ECMAScript value |
| 21:34 | <jridgewell> | So you can’t type `console.log(#foo)` |
| 21:34 | <jridgewell> | Because it’s not a value |
| 21:34 | <jridgewell> | Reify means creating a value for it |
| 21:34 | <rkirsling> | it means "make concrete" |
| 21:35 | <rkirsling> | it's a really opaque term though if you're not used to it |
| 21:36 | <rkirsling> | "first-class representation" was a nice synonym just now |
| 21:37 | <rkirsling> | I've used "instantiable" instead of "reified" before but that doesn't apply in all occasions |
| 21:37 | <devsnek> | if we don't reify these as first class values i'm gonna cry |
| 21:37 | <bradleymeck> | are we talking about lexical referencing or straight 1st class reification as a value? i'm confused as i'd be wary of passing around the value |
| 21:37 | <devsnek> | i would kill to be able to pass around the value |
| 21:38 | <devsnek> | we could stop using non-enumerable symbols in node core |
| 21:39 | <devsnek> | really we just need private symbols |
| 21:40 | <jridgewell> | Can’t Node use V8 internals? |
| 21:40 | <jridgewell> | Meaning, can’t you just use V8’s internal Private Symbols? |
| 21:40 | <devsnek> | someone was against that |
| 21:40 | <devsnek> | but regardless |
| 21:40 | <devsnek> | it would be a shame to keep that fun to v8 |
| 21:41 | <devsnek> | its such a useful feature |
| 21:41 | <jridgewell> | I really like Private Symbols... |
| 21:41 | <devsnek> | it fulfills all the use cases in such a natural way :( |
| 21:42 | <devsnek> | jridgewell: btw in node you can use https://npmjs.org/@snek/private |
| 21:42 | <jridgewell> | Link to source code? |
| 21:43 | <devsnek> | oh apparently i forgot to push lol |
| 21:43 | <devsnek> | https://github.com/devsnek/private |
| 21:43 | <jridgewell> | 404 |
| 21:44 | <devsnek> | jridgewell: https://github.com/devsnek/private-symbol/blob/master/private.cc |
| 21:47 | <jridgewell> | THanks |
| 21:48 | <jridgewell> | I was curious how you did it. Makes sense that it’s a native module |
| 21:48 | <devsnek> | yes :( |
| 21:48 | <devsnek> | i want to give this amazing api to all of js |
| 21:49 | <jridgewell> | If you run first, you could patch the `Object.keys` (and friends) to ignore regular regular symbols |
| 21:49 | <mpcsh> | jridgewell Bakkot ljharb rkirsling: https://github.com/tc39/how-we-work/issues/80 |
| 21:49 | <devsnek> | jridgewell: can't patch for-in |
| 21:49 | <jridgewell> | for-in can’t return a Symbol |
| 21:50 | <devsnek> | oh neat |
| 21:50 | <jridgewell> | The only way to expose a Symbol is through the methods |
| 21:50 | <devsnek> | neat idea |
| 21:50 | <devsnek> | oh wait proxies |
| 21:50 | <ljharb> | Object.assign, object spread, Object.getOwnPropertySymbols, Reflect.ownKeys, proxies |
| 21:50 | <devsnek> | jridgewell: need the modifications for proxies |
| 21:51 | <jridgewell> | Yah, Proxy invariants will be super wonky |
| 21:51 | <ljharb> | those all interact with sym,bols |
| 21:51 | <Bakkot> | proxies were a mistake |
| 21:51 | <Bakkot> | the original sin of ES6 |
| 21:51 | <jridgewell> | ljharb: That’s why I said “(and friends)" |
| 21:51 | <jridgewell> | There are quite a few methods that need to be patched |
| 21:51 | <ljharb> | yeah |
| 21:51 | <jridgewell> | But it _could_ be done |
| 21:52 | <jridgewell> | I think Proxies are the only really hard part |
| 21:52 | <jridgewell> | Because of their internal invariant checks |
| 21:52 | <devsnek> | https://github.com/tc39/ecma262/compare/master...devsnek:feature/private-symbols?expand=1 |
| 21:52 | <devsnek> | fairly small change in the spec at least |
| 21:52 | <devsnek> | the entire diff is +60-12 |
| 21:53 | <jridgewell> | It’s much large, unfortunately |
| 21:53 | <Bakkot> | jridgewell this would also require discipline in never using a property a user-controlled object, because it might be a proxy with a `get` trap |
| 21:54 | <devsnek> | in my diff you have to tell the proxy which private symbols it can trap |
| 21:54 | <jridgewell> | https://docs.google.com/presentation/d/1HWM_pREmpz7QN9VrNeFt5T-x6CfKBL06pXhiQcxgfgU/edit |
| 21:54 | <devsnek> | so you're able to trap ones you can reach |
| 21:54 | <devsnek> | but the other ones can't be |
| 21:54 | <jridgewell> | That was my design as well! |
| 21:54 | <ljharb> | +1 to that |
| 21:54 | <ljharb> | you can only trap the ones you've proven you can already access |
| 21:54 | <jridgewell> | Bakkot: You have to wrap Proxy, too |
| 21:55 | <devsnek> | the entire proxy global |
| 21:55 | <jridgewell> | You have to ensure the handlers don’t receive a private symbol |
| 21:55 | <Bakkot> | ah and then proxy the proxy, fun |
| 21:55 | <Bakkot> | but yeah doable |
| 21:55 | <Bakkot> | s/proxy the proxy/proxy the handler/ |
| 21:55 | <jridgewell> | I actually have an implementation of that. |
| 21:55 | <devsnek> | if we just figure out how private fields map to this |
| 21:56 | <devsnek> | we can propose it and retire |
| 21:56 | <Bakkot> | it was proposed and rejected |
| 21:56 | <jridgewell> | We can reify private fields to symbols, iff we keep the brand semantics |
| 21:56 | <devsnek> | you can say the throwing is part of the # syntax |
| 21:57 | <jridgewell> | My proposal got rejected due to using normal propery lookup semantics |
| 21:57 | <devsnek> | because heaven forbid they're just properties :( |
| 21:57 | <jridgewell> | It must throw, else there’ll be many objections |
| 21:57 | <devsnek> | we have the throwing version |
| 21:57 | <devsnek> | objection handled |
| 21:57 | <Bakkot> | that does not in fact handle the objection |
| 21:58 | <devsnek> | then why is it in the language |
| 21:58 | <devsnek> | well stage 3 |
| 21:58 | <Bakkot> | years and years of consensus-building |
| 21:58 | <Bakkot> | decades, even |
| 21:58 | <jridgewell> | Which part are you talking about? |
| 21:59 | <jridgewell> | Reification is its own discussion, but private symbols with brand semantics would be possible |
| 21:59 | <jridgewell> | My proposal was several changes, and there were objections to basically each |
| 21:59 | <jridgewell> | But that doesn’t change the symbol reification is possible |
| 22:02 | <TabAtkins> | Jumping back for a moment: the point of the cascade operator is that it allows you to do chaining on APIs that *don't* support chaining explicitly. (Such as a *lot* of legacy DOM APIs.) If an API is, say, already using the chained-builder pattern, then it's not necessary, as normal method chaining works there. |
| 22:04 | <jackworks> | property assignment doesn't support chaining. I have to add a `enableSomeFeature()` that return `this` to prevent the awkward break of chaining |
| 22:04 | <rkirsling> | TabAtkins: +1, sorry for the misspeak |
| 22:06 | <TabAtkins> | What confuses me about Dart's syntax is that it appears to bless the receiver of the first cascade operator in an expression, such that all subsequent cascades in the same expression use the same receiver? That feels weird as heck to me. |
| 22:07 | <ljharb> | same |
| 22:08 | <TabAtkins> | That all said, hmmmm, does pipeline+comma give us this ability natively? `document.createElement('div') |> #.className = 'abc', #.onclick = ()=>{}, #.appendTo(document.body), #` |
| 22:08 | <ljharb> | oof |
| 22:09 | <ljharb> | (i don't think it does currently, the position of the placeholder is pretty constrained atm) |
| 22:09 | <TabAtkins> | Okay one sec, lemme make it multiline ^_^ |
| 22:09 | <TabAtkins> | (I'm specifically using the hack-syntax pipelines; all other pipelines syntaxes are dead to me for their inherent weaknesses) |
| 22:10 | <TabAtkins> | ``` |
| 22:10 | <TabAtkins> | document.createElement('div') |> |
| 22:10 | <TabAtkins> | #.className = 'abc', |
| 22:10 | <TabAtkins> | #.onclick = ()=>{}, |
| 22:10 | <TabAtkins> | #.appendTo(document.body), |
| 22:10 | <TabAtkins> | # |
| 22:10 | <TabAtkins> | ``` |
| 22:10 | <devsnek> | uhoh |
| 22:11 | <ljharb> | yeah i got what you meant, but the current proposal grammar doesn't allow that |
| 22:11 | <TabAtkins> | Which "current proposal"? |
| 22:11 | <ljharb> | (afaik) |
| 22:11 | <ljharb> | the current pipeline proposal is down to F# and "smart", iirc, and both of those have semantics largely written down |
| 22:11 | <ljharb> | no idea which one is hack |
| 22:12 | <TabAtkins> | Smart allows this. |
| 22:12 | <ljharb> | k |
| 22:12 | <TabAtkins> | Hack is just "always require the #" |
| 22:12 | <Bakkot> | oh god |
| 22:12 | <TabAtkins> | So smart without the smarts. |
| 22:14 | <ljharb> | that kills point-free style? |
| 22:14 | <TabAtkins> | Note that this allows slightly wider sets of syntaxes than cascade, even: `el.appendTo(newParent)` isn't even valid syntax, but cascade requires it to exist. In DOM it's instead `newParent.appendChild(el)`, which you'd write as `document.body.appendChild(#)` in the above example |
| 22:14 | <jschoi> | The Hack doesn’t allow tacit style, yeah. It doesn’t have a formal proposal. |
| 22:14 | <devsnek> | what if you just wrote what the computer should do in prose |
| 22:14 | <devsnek> | the most smart |
| 22:14 | <jschoi> | The DWIM operator. |
| 22:14 | <TabAtkins> | (I'm not implying that I ignore smart; smart is good and pure; I was just saying that point-free is dead to me.) |
| 22:15 | <jschoi> | What’s this pipeline-comma operator, though? |
| 22:15 | <Bakkot> | it's just pipeline plus the existing horror that is the comma operator, as I understand it |
| 22:15 | <TabAtkins> | yup |
| 22:16 | <TabAtkins> | just ordinary, everyday horrifying comma |
| 22:16 | <devsnek> | can we fit entire programs into pipelines |
| 22:16 | <jschoi> | I…think comma behinds less tightly than the pipe operator, but it’s been a while since I’ve been able to look at my own proposal, haha. |
| 22:18 | <TabAtkins> | i'm pretty sure that assignment is looser than pipe as well, so actually nm |
| 22:18 | <TabAtkins> | you'd need parens |
| 22:18 | <jschoi> | document.createElement('div') |> (#.className = 'abc', #.onclick = () => {}, #.appendTo(document.body)); |
| 22:18 | <TabAtkins> | and at that point you might as well just `(x=>{...})(document.createElement('div'))`, honestly. |
| 22:18 | <rkirsling> | it should be, yeah |
| 22:19 | <rkirsling> | ternary, then assignment, then everything else |
| 22:19 | <jschoi> | Or maybe eventually: |
| 22:19 | <TabAtkins> | wait you can do assignment in a ternary? |
| 22:19 | <jschoi> | document.createElement('div') |> { |
| 22:19 | <jschoi> | #.className = 'abc', |
| 22:19 | <jschoi> | #.onclick = () => {}, |
| 22:19 | <jschoi> | #.appendTo(document.body); |
| 22:19 | <jschoi> | } |
| 22:19 | <jschoi> | Er, those should be semicolons in that block. |
| 22:19 | <TabAtkins> | yes |
| 22:19 | <TabAtkins> | i'm for it |
| 22:19 | <jschoi> | I haven’t kept up; I don’t know how do-expressions have been doing. |
| 22:19 | <TabAtkins> | still bad |
| 22:20 | <rkirsling> | er oops I misspoke again |
| 22:20 | <rkirsling> | 🤦 |
| 22:20 | <jschoi> | Bad = those problems with loop control? |
| 22:20 | <rkirsling> | comma, assignment, ternary, ... |
| 22:20 | <TabAtkins> | wait: `((x=document.createElement('div'))=>{x.classList = 'abc'; ... })()`, there, now it has the starting value up front |
| 22:20 | <TabAtkins> | too many parens, but oh well |
| 22:21 | <Bakkot> | bad = we have not revisted it mostly, I think |
| 22:21 | <TabAtkins> | yeah, nobody's touched it i meant |
| 22:21 | <jschoi> | Gotcha. |
| 22:21 | <ljharb> | so many proposals, current and future, would be obsoleted or made simpler with do expressions :-( |
| 22:21 | <rkirsling> | did Dave disappear now too? 😓 |
| 22:21 | <TabAtkins> | YUP |
| 22:22 | <jschoi> | What has had most of TC39’s attention lately? I need to read the latest minutes… |
| 22:22 | <TabAtkins> | So pipeline + do-expr would give you the arrow-function above, but with a lot less parens to worry about. |
| 22:23 | <TabAtkins> | aka the standard benefit of pipeline, so yay |
| 22:23 | <Bakkot> | jschoi empirically, what has most of our attention is "which kind of unicode escape sequences should be usable in named capture group names for non-BMP unicode characters" |
| 22:24 | <jschoi> | Aw yeah. |
| 22:24 | <devsnek> | do expressions are on my proposal list https://snek.dev/proposal-list |
| 22:24 | <TabAtkins> | I mean the answer is always "whatever topics are interesting to people attending the meetings", and nobody at the meetings is currently interested in moving do-exprs. |
| 22:25 | <TabAtkins> | devsnek: Ooh, and it's the next one up, nice |
| 22:25 | <devsnek> | TabAtkins: not ordered |
| 22:25 | <devsnek> | sorry ❤️ |
| 22:25 | <TabAtkins> | I choose not to believe you! |
| 22:25 | <devsnek> | lol |
| 22:26 | <jackworks> | so is "implicit do expression" making every statement (that can be wrapped in a explicit do expr) a valid expression in JavaScript? |
| 22:26 | <Bakkot> | jackworks where did you see that phrase? |
| 22:26 | <Bakkot> | answer depends on where you saw it |
| 22:26 | <Bakkot> | (but probably yes) |
| 22:27 | <jackworks> | oh i like it |
| 22:28 | <jschoi> | I love it too. It would make one of smart pipe’s subproposals obsolete. |
| 22:28 | <devsnek> | some don't make sense |
| 22:28 | <devsnek> | but others do |
| 22:28 | <devsnek> | if expressions and throw expressions would be nice |
| 22:29 | <Bakkot> | it'd be weird to have both those and do expressions though |
| 22:30 | <devsnek> | it wouldn't |
| 22:30 | <Bakkot> | it wouldn't be weird? |
| 22:30 | <devsnek> | i don't think it would |
| 22:30 | <devsnek> | i use block expressions in rust all the time |
| 22:31 | <Bakkot> | rust is a different language |
| 22:32 | <devsnek> | Bakkot: for the same reasons i would use them in js |
| 22:33 | <Bakkot> | devsnek sure, and do expressions might make sense; the point is that it would be would be weird to have three different ways to write a conditional in expression position |
| 22:33 | <jridgewell> | devsnek: Why `function.sent`? |
| 22:34 | <devsnek> | Bakkot: oh we don't have to have if expressions |
| 22:34 | <devsnek> | jridgewell: why not |
| 22:34 | <jridgewell> | If we could just get do expressions, I think that's an argument for not having if expressions. |
| 22:34 | <devsnek> | its useful |
| 22:34 | <jridgewell> | But it's soo hard to get do expressions, why not if statements now. |
| 22:34 | <Bakkot> | we have if statements :P |
| 22:34 | <devsnek> | is it that hard |
| 22:34 | <jridgewell> | Do you have an example? |
| 22:34 | <devsnek> | is the objection still about implicit return semanticss |
| 22:34 | <jridgewell> | Yah |
| 22:35 | <TabAtkins> | we should remove if statements, to encourage do-exprs. |
| 22:35 | <devsnek> | we have eval |
| 22:35 | <Bakkot> | devsnek yes but we shouldn't, everyone agrees we shouldn't except like mark |
| 22:35 | <Bakkot> | eval is terrible |
| 22:35 | <devsnek> | what was the problem with implicit returns again |
| 22:35 | <jridgewell> | Whatever that OCP (I don't remember the acronym) closure requirements were. |
| 22:35 | <Bakkot> | the big points of contention are 1) whether you can put break / return in expressions and 2) completion values are weird |
| 22:35 | <Bakkot> | TCP |
| 22:35 | <Bakkot> | tenant's correspondence principle |
| 22:35 | <Bakkot> | or something like that |
| 22:36 | <devsnek> | if we don't have break and return there's no reason to have do expressions |
| 22:36 | <michaelficarra> | Tennet |
| 22:36 | <jschoi> | Yeah, that was the big problem. |
| 22:36 | <devsnek> | you can polyfill them with eval without tcp |
| 22:36 | <devsnek> | a big reason i want them is the return |
| 22:36 | <TabAtkins> | "you can polyfill them with eval" is... not a valid argument for "we don't need X" imo ^_^ |
| 22:36 | <Bakkot> | +1 |
| 22:37 | <devsnek> | i would add it to the private field list of sad things |
| 22:37 | <devsnek> | along with records |
| 22:37 | <jridgewell> | I really wish `eval('foo')` didn't hit CSP. |
| 22:37 | <devsnek> | i really wish trusted types didn't exist |
| 22:37 | <jridgewell> | If that were the case, we'd already have do expressions. |
| 22:40 | <TabAtkins> | That all said, I'm def still in the camp that we should just exactly match the eval() return semantics (even if they're nasty in some cases like loops) for simplicity (no more discussions needed!) and also I just plain don't understand what the return/break problems are |
| 22:43 | <Bakkot> | so glad eval hits CSP |
| 22:43 | <Bakkot> | so glad |
| 22:44 | <Bakkot> | devsnek they don't exist yet! |
| 22:44 | <Bakkot> | but they probably will |
| 22:44 | <Bakkot> | I also didn't like them originally, still think they're ugly but will probably make actual users actually safer, so I am willing to accept them |
| 22:44 | <Bakkot> | users of websites, that is |
| 22:44 | <Bakkot> | who are the most numerous and highest (to me) priority group |
| 22:45 | <devsnek> | I'm not convinced but 🤷 |
| 22:45 | <devsnek> | I don't do web spec |
| 22:45 | <jridgewell> | `eval(foo)` should certainly hit CSP |
| 22:45 | <Bakkot> | my day job involves talking to engineers at banks |
| 22:45 | <Bakkot> | which informs my perspective here |
| 22:46 | <jridgewell> | But why should `eval('foo')`? |
| 22:46 | <devsnek> | do they ask for decimals |
| 22:46 | <Bakkot> | jridgewell ahhh |
| 22:46 | <Bakkot> | devsnek not the web devs, who are the ones I talk to |
| 22:46 | <Bakkot> | but they don't ask for anything when I am talking to them |
| 23:14 | <jmdyck> | not Tenant or Tennet, but Tennent. E.g.: https://fanf.livejournal.com/118421.html |
| 23:15 | <ljharb> | tenant vs tenet vs Tennant (doctor who) vs Tennent (TCP) |
| 23:23 | <mpcsh> | Bakkot: with regards to symmetry with Identifier, is there appetite for refactoring Identifier? |
| 23:23 | <Bakkot> | mpcsh there's nonzero appetite but also some strong opposition |
| 23:23 | <gibson042> | in what way? to allow surrogate pairs? |
| 23:23 | <mpcsh> | probably? I was just curious if people had Thoughts on this |
| 23:24 | <rkirsling> | I would assume there would be stronger Unicode-hat opposition to that move |
| 23:25 | <ljharb> | mathiasbynens in particular has expressed a strong preference to avoid exposing surrogate pairs in more places |
| 23:25 | <mpcsh> | very fair. is there appetite for banning surrogate pairs entirely anywhere in the language? |
| 23:26 | <ljharb> | web compat precludes that anywhere |
| 23:26 | <gibson042> | I am personally in favor for the author simplicity of "\u escapes work except for the special case of non-Unicode regular expressions", but there is definitely strong opposition on the committee |
| 23:26 | <gibson042> | "\u escapes of both flavors" |