| 02:36 | <shu> | jmdyck: Bakkot: copypasta, let me change now |
| 02:37 | <shu> | hm, there is some precedent for this, like `thisStringValue` having `<dfn id="sec-thisstringvalue">` |
| 02:38 | <shu> | that's kinda unfortunate |
| 02:38 | <shu> | Bakkot: do `<dfn>`s take oldids=? |
| 02:38 | <Bakkot> | not sure, let me check |
| 02:39 | <Bakkot> | shu: should, based on impl |
| 02:39 | <shu> | i'm not adding oldids to the ones i just introduced but for the older ones, we should keep the oldids |
| 02:39 | <shu> | okay great |
| 02:41 | <Bakkot> | yeah, tested experimentally |
| 02:41 | <Bakkot> | it's kind of funny actually; the oldids will link directly to the definition, rather than (as is normal for dnfs) the containing section |
| 02:44 | <shu> | https://github.com/tc39/ecma262/pull/2103 |
| 02:45 | shu | off |
| 11:32 | <ystartsev> | everybody ready for today? |
| 11:32 | <ystartsev> | https://youtu.be/jxi0ETwDvws?t=116 |
| 13:10 | <devsnek> | i suppose i did know this already, but i'm very surprised that optional chains aren't valid assignment targets |
| 14:56 | <jorendorff> | ljharb: hi - looking at https://github.com/tc39/ecma262/pull/2045, it seems very likely to land. Is that right? |
| 15:18 | <bradleymeck> | devsnek: i think there was some back and forth and it was dropped in ancient times due to back and forth |
| 15:18 | <devsnek> | ya |
| 15:19 | <rickbutton> | ystartsev: that channel has a lot of programming related music videos |
| 15:19 | <bradleymeck> | i asked people at godaddy about if they wanted it and the overwelming majority wanted if (z) x.y = z rather than that |
| 15:19 | <devsnek> | i am knowledgeable of that, but in the moment of writing code i just naturally did `a?.b = c` and then was sad when it failed |
| 15:19 | <devsnek> | isn't that `??=` |
| 15:19 | <devsnek> | or just `||=` |
| 15:19 | <jackworks> | jorendorff: there're still some work not done, including old ids and some review ExEBoss rises I'll handle them tomorrow |
| 15:19 | <devsnek> | oh no i guess that's the inverse |
| 15:20 | <jorendorff> | jackworks: yep -- it all looks good |
| 15:20 | <jorendorff> | i just wanted to make sure i'm not missing anything |
| 16:21 | <ljharb> | jorendorff: afaik all the editors are on board with the concept; it may need some more tweaks, and it’ll need review (but that will likely be after plenary) |
| 16:21 | <jorendorff> | ljharb: ok, thanks. that makes sense. |
| 16:22 | <Bakkot> | yeah I haven't gotten a chance to review the PR itself and so can't say if the current form works, but I still agree with the plan we talked about during last meeting |
| 16:22 | <ljharb> | jorendorff: the hope is to find some balance between “converting none of the existing iterator-producers” and “converting all of them” that both convinces us it’s viable and also doesn’t make jackworks do too much work :-) |
| 16:24 | <jorendorff> | ljharb: Ah, I see. Thanks for the extra context. Does this imply trying to change the prototype chains of the existing iterator-producers? |
| 16:26 | <Bakkot> | I don't think so; I am pretty sure when we discussed this at the last meeting we said that the point of this effort was strictly editorial improvement for specifying iterators |
| 16:27 | <Bakkot> | and I am in general not in favor of making normative decisions for editorial reasons |
| 16:57 | <ljharb> | jorendorff: no, it very much implies not doing that, since that'd be observable :-) |
| 16:57 | <jorendorff> | OK, good |
| 17:10 | <leobalter> | bterlson: I love your social isolation hair style |
| 17:14 | <bterlson> | leobalter: lol thanks |
| 18:57 | <bradleymeck> | how would people people want to spec export/import wildcards regarding arbitrary binding name strings, currently we use a special string: "*default*" , but that would be valid in https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers , so need to alter on a type somehow so it isn't a string |
| 18:58 | <bradleymeck> | same for "*" |
| 18:59 | <bradleymeck> | we could spec it using symbols as special well known values? |
| 18:59 | <jmdyck> | or use tilde-values? |
| 19:02 | <bradleymeck> | jmdyck: i guess we could, seems a bit odd to mix string and tilde values in a list |
| 19:02 | <devsnek> | can we refactor this https://gc.gy/62976763.png |
| 19:02 | <michaelficarra> | bradleymeck: sounds like a question for #tc39-editor-group |
| 19:03 | <michaelficarra> | I think we could use a spec enum value for it |
| 19:03 | <jmdyck> | devsnek: refactor how? |
| 19:03 | <bradleymeck> | can move it there |
| 19:03 | <devsnek> | don't need nested if statements i don't think |
| 19:04 | <devsnek> | jmdyck: might push this up in a minute https://gc.gy/62976833.png |
| 19:04 | <ljharb> | bradleymeck: a spec enum makes sense to me |
| 19:05 | <leobalter> | shu: |
| 19:05 | <leobalter> | I don't have a motivation for disallowing |
| 19:06 | <leobalter> | I'm just addressing a point that came out from the proposal issues, and my preference is to not disallow |
| 19:06 | <leobalter> | it's too specific and disallowing might involve some tricky change in the grammar to also extend DecimalLiteral in Annex B |
| 19:07 | <leobalter> | so if you don't see enough motivation, I'm totally onboard with you |
| 19:07 | <shu> | leobalter: yeah it just seems like more work to me |
| 19:07 | <shu> | leobalter: since as you said exponential parts have been allowed forever, and that's the same kind of weirdness |
| 19:08 | <shu> | so if we can't disallow all weirdness, it seems worse to me to bless some subset of weirdness and say "okay these weird things are allowed, but new weird things aren't allowed", if we don't expect people to use the feature anyhow |
| 19:08 | <shu> | all other things being equal, that is, like implementation and spec burden |
| 19:08 | <shu> | in this case it seems like they are? |
| 19:09 | <shu> | the flip side is maybe if we allow it it's likely to be implemented wrong? |
| 19:10 | <shu> | like, in the parser when you start parsing a legacy nonoctal you'll pass some flag that says "separators not allowed" which might get accidentally propagated to the part after `.` or `e`, but that's a pretty weak argument |
| 19:10 | <shu> | but given that it's all implemented already... |
| 19:11 | <devsnek> | we also have "*namespace*" |
| 19:12 | <jmdyck> | devsnek: I checked the history: that elseless-if-within-if goes back to a late draft of ES6. It seems like there's never been a reason for it. |
| 19:12 | <leobalter> | shu I created a new slide I'll show during the continuation: https://docs.google.com/presentation/d/1J-oYbstZX2W0LCIVtKG4XbTxWe3cH8JoWNGnoL2F-94/edit#slide=id.g8c6affb1a1_0_50 |
| 19:12 | <devsnek> | ljharb: https://travis-ci.org/github/tc39/ecma262/jobs/710124061 |
| 19:12 | <leobalter> | it's weird that I'm presenting a proposal that my goal is to reject it :) |
| 19:12 | <devsnek> | jmdyck: thx, made pr https://github.com/tc39/ecma262/pull/2105 |
| 19:13 | <rkirsling> | leobalter: :highfive: more or less |
| 19:13 | <rkirsling> | lol |
| 19:14 | <ljharb> | devsnek: that happens when the PR has too many commits, but i deployed a service fix for it an hour ago. rerunning. |
| 19:14 | <devsnek> | i mean its only got 1 commit |
| 19:14 | <rkirsling> | (once I can come up with a rationale for how things are then I feel less strongly about changing them, I suppose) |
| 19:16 | <jmdyck> | devsnek: I made a suggestion on 2105, and gh gives me an option to "Commit suggestion", which I don't think I've seen before. |
| 19:16 | <ljharb> | devsnek: hm, if it fails again i'll reach out to my contact at Begin |
| 19:16 | <devsnek> | jmdyck: if it works go for it |
| 19:16 | <ljharb> | jmdyck: it's supposed to always be there |
| 19:16 | <devsnek> | https://gc.gy/62977581.png |
| 19:16 | <devsnek> | when i try to use it |
| 19:16 | <ljharb> | there's a bug on github; if the suggestion is from someone with write access, you can't accept it |
| 19:17 | <devsnek> | incredible |
| 19:17 | <jmdyck> | Oh, I see it when people make suggs on *my* PRs, but this is my sugg on someone else's PR. |
| 19:17 | <devsnek> | what happens if you click it |
| 19:17 | <jmdyck> | let's see.... |
| 19:17 | <devsnek> | and try to commit it |
| 19:17 | <rkirsling> | that bug has been plaguing us forever 😭 |
| 19:18 | <ljharb> | jmdyck: iirc you have write access on 262, so you *should* have write access on all PR branches too |
| 19:18 | <devsnek> | do i have write access to 262? |
| 19:19 | <jmdyck> | Got the same old "This diff has recently been updated. Refresh and try again." |
| 19:19 | <ljharb> | devsnek: afaik no |
| 19:53 | <ljharb> | devsnek: build issue is fixed, job passed on rerun |
| 19:53 | <devsnek> | 👍🏻 |
| 20:22 | <leobalter> | rkirsling: we've had consensus for this one, right? https://github.com/tc39/test262/issues/2653 |
| 20:23 | <rkirsling> | leobalter: yep! :D |
| 22:55 | <devsnek> | if we have do expressions do we need static constructors |
| 22:58 | <ljharb> | devsnek: yes, for anything in the block that's not setting up a field |
| 22:58 | <ljharb> | like if it wants to put a data property on the prototype, or to defineProperty something |
| 22:59 | <devsnek> | ljharb: why can't you do that in a do expression |
| 23:01 | <ljharb> | because the do expression would still have to be assigned to a class field, and you may not want one? |
| 23:01 | <devsnek> | huh |
| 23:01 | <ljharb> | where else would you put a do expression except in the RHS of a class field |
| 23:02 | <devsnek> | ljharb: const X = do { create class here } |
| 23:02 | <devsnek> | or let X I guess |
| 23:02 | <devsnek> | why are class declarations mutable anyway |
| 23:59 | <ljharb> | devsnek: that wouldn't provide access to private fields outside the class body. |
| 23:59 | <Bakkot> | though private declarations would! |
| 23:59 | <Bakkot> | which we should do anyway |
