| 00:19 | <rkirsling> | the most hilarious thing |
| 00:19 | <rkirsling> | is that it is a national holiday in Japan |
| 00:20 | <rkirsling> | I'm not sure how we didn't notice this...lol >_< |
| 00:21 | <leobalter> | I underestimated myself working on a Sunday night, after a weekend full of parenting duties. |
| 00:29 | <rkirsling> | yeah, today is 敬老の日 (Respect for the Aged Day) and tomorrow is 秋分の日 (Autumnal Equinox Day) |
| 00:30 | <rkirsling> | so my Japanese colleagues are all off...oops |
| 00:37 | <ryzokuken> | Guten Morgen, fellow delegates. |
| 00:38 | <ryzokuken> | leobalter: early Monday morning here, and I'd be _so_ much happier if it were Sunday evening lol |
| 00:38 | <ryzokuken> | 5 AM on monday morning is the worst, I wouldn't wish it on my worst enemies :D |
| 00:39 | <leobalter> | the last GA meeting started at 4AM in my time zone :) |
| 00:39 | <leobalter> | it was me held by a cup of coffee |
| 00:39 | <ryzokuken> | leobalter: talking of coffee... :) |
| 00:39 | <rickbutton> | yeah time to make a 8:40PM cup of coffee |
| 00:39 | <ryzokuken> | lol |
| 00:43 | <ryzokuken> | are we using hubs again this time? |
| 00:43 | <ryzokuken> | anyone on it yet? |
| 00:52 | <rkirsling> | tomoki_imai: 👋 |
| 00:53 | <devsnek> | of course my laptop picks this time for the gpu drivers to break |
| 00:53 | <rickbutton> | oh no |
| 00:55 | <littledan> | FWIW from Android, it only let me set my name once, and when I disconnected and reconnected, it remembered my name |
| 00:55 | <littledan> | so that's why I'm set to "Daniel", apologies |
| 00:57 | <devsnek> | am i supposed to do something here https://gc.gy/68354869.png |
| 01:12 | <devsnek> | can someone update the MOTD |
| 01:14 | <devsnek> | lol |
| 01:14 | <ljharb> | jinx |
| 01:14 | <ljharb> | i guess technically you beat me by 2s :-( |
| 01:14 | <devsnek> | oh wait i can set the motd |
| 01:14 | <devsnek> | neat |
| 01:21 | <michaelficarra> | omg nothing works :-( |
| 01:21 | <michaelficarra> | teams is so bad |
| 01:22 | <akirose> | I HAD SO FEW COMPLAINTS ABOUT MICROSOFT COLLABORATION PRODUCTS UNTIL TWO WEEKS AGO AND NOW I ONLY TYPE IN CAPS |
| 01:22 | <rickbutton> | we should just standardize on a single tool for meetings |
| 01:22 | <ryzokuken> | is it just me or do we see Aki's slides? |
| 01:22 | <shu> | what have we used so far? zoom and teams? |
| 01:23 | <ryzokuken> | apparently we could just take control |
| 01:23 | <rkirsling> | yeah. zoom worked well except for the privacy worries :-/ |
| 01:23 | <rickbutton> | google meet? |
| 01:23 | <shu> | i don't think we actually used meet |
| 01:23 | <ryzokuken> | jitsi 🙈 |
| 01:23 | <devsnek> | discord :D |
| 01:23 | <rkirsling> | meet would seem fine; I just never had a huge meeting in it |
| 01:23 | <shu> | don't even know what that is |
| 01:23 | <devsnek> | imagine, all our chat and video in one place |
| 01:24 | <devsnek> | jitsi == oss zoom |
| 01:24 | <rbuckton> | MylesBorins: Its possible to upload a PowerPoint to Teams for a meeting which lets anyone move around within the slides without affecting everyone else, and I think that's what akirose was trying earlier. For some reason it took over sharing from Istvan. |
| 01:25 | <MylesBorins> | super strange |
| 01:25 | <MylesBorins> | ¯\_(ツ)_/¯ |
| 01:25 | <akirose> | yeah it's what i was doing earlier and long long after i had given up and no longer had the sharing view, it apparently came back for everyone but me |
| 01:25 | <rickbutton> | that feature was broken last time we used teams too |
| 01:25 | <ljharb> | rbuckton: unfortunately with that feature, it seems like it's really easy to lose "the presenter advances the slides" sync |
| 01:25 | <ljharb> | rbuckton: iow i've found i have to constantly manually advance a slide and hit "to presenter" to sync it up |
| 01:26 | <shu> | there's a chrome extension internally that lets meeting participants control Slides sharing, and it is always chaos |
| 01:26 | <shu> | a nice idea in theory |
| 01:27 | <Bakkot> | zoom is the only one of these which seems to consistently actually work |
| 01:27 | <Bakkot> | petition to only use zoom in the future |
| 01:28 | <Bakkot> | F5 has an account, we might be able to "host" |
| 01:28 | <michaelficarra> | seconded |
| 01:28 | <rkirsling> | I would support that |
| 01:28 | <devsnek> | petition to try discord once first |
| 01:28 | <akirose> | banned from paypal computers i think |
| 01:28 | <rkirsling> | orz |
| 01:30 | <shu> | Bakkot: googlers are still discouraged from using the Zoom desktop client; requires an exception |
| 01:30 | <shu> | i've never used the web version, does that also work well |
| 01:31 | <devsnek> | i use the web version for things that require it, seems to be functional |
| 01:31 | <Bakkot> | shu is "I need it to participate in the standards body of which I am editor, which uses it because it is the only functional video client" a valid exception |
| 01:32 | <shu> | Bakkot: they would take exception to the second phrase but it's certainly a valid exception |
| 01:32 | <shu> | but i am not the only googler, just saying it's not zero-friction |
| 01:33 | <rickbutton> | Bakkot or ljharb can you give me a slides link for the notes when you have a sec |
| 01:34 | <Bakkot> | yeah, just seems like there's a bunch of friction with every client, except that the end result with Zoomo is that you have a functional meeting |
| 01:34 | <shu> | we could give meet a try, but i |
| 01:34 | <shu> | err |
| 01:34 | <shu> | but i've also never had a meeting of this size on Meet |
| 01:34 | <rickbutton> | I've had meetings with 100+ people in a room and it works |
| 01:35 | <shu> | no no, #2086 is a small PR! |
| 01:36 | <bterlson> | Bakkot: can you say how the meeting is not working? |
| 01:36 | <bterlson> | how can I help |
| 01:37 | <ljharb> | rickbutton: https://j.mp/262editor202009 - i'll add them to the agenda shortly |
| 01:37 | <rickbutton> | thx :) |
| 01:38 | <Bakkot> | bterlson I'm mostly referring to the thing where Aki struggled to present, but I'm also salty about a.) when presenting I can't see anyone's faces and b.) when not presenting I can only see at most 9 people |
| 01:38 | <akirose> | how was i meant to present in presenter view? I HAD NOTES |
| 01:39 | <bterlson> | Bakkot: ok got it |
| 01:46 | <ljharb> | bterlson: hm, i didn't see anything on TCQ |
| 01:46 | <bterlson> | https://tcq.app/meeting/BSXq ? |
| 01:46 | <bterlson> | oh whoops |
| 01:46 | <ljharb> | ahhh the draft schedule has KfmX |
| 01:47 | <devsnek> | yeah that's last month |
| 01:47 | <bterlson> | will tell aki to update |
| 01:47 | <rkirsling> | is it a problem that that just got exposed? |
| 01:47 | <ljharb> | kk ty |
| 01:47 | <bterlson> | not really |
| 01:48 | <devsnek> | some random person could spam us with POO but that is unlikely |
| 01:48 | <bterlson> | if we had sensitive issues on the agenda it would be a concern |
| 01:48 | <rickbutton> | needs a github login so isn't anonymous |
| 01:48 | <littledan> | I'm very happy about this SDO restructuring |
| 01:48 | <littledan> | we're switching from object oriented to pattern matching! |
| 01:49 | <littledan> | it's just so hard to read the current spec layout |
| 01:49 | <rkirsling> | ooh |
| 01:49 | <devsnek> | pattern matching O.o |
| 01:49 | <rkirsling> | I hadn't followed that work |
| 01:49 | <devsnek> | which one is that again |
| 01:50 | <Bakkot> | devsnek https://github.com/tc39/ecma262/issues/1950 |
| 01:50 | <Bakkot> | assuming I understand the question |
| 01:50 | <devsnek> | oh i thought there was a pr |
| 01:50 | <devsnek> | curious what "pattern matching" means in this context |
| 01:50 | <rkirsling> | lol I love devsnek's `yes yes so much yes` |
| 01:51 | <Bakkot> | no, not yet |
| 01:51 | <devsnek> | rkirsling: i have spent too much of my life jumping around the spec looking for early errors |
| 01:51 | <Bakkot> | no point in making the PR until we're ready, since it will merge-conflict with everything |
| 01:52 | <rkirsling> | `this style ... was chosen ... on the basis that it was written in Word and Ecma liked Word` |
| 01:52 | <rkirsling> | oof |
| 01:52 | <Bakkot> | "pattern matching" means that it is defined like `SDO = match (node.type){ Expression => whatever, Statement => whatever}` instead of being defined like `Expression.SDO = whatever [...] Statement.SDO = whatever` |
| 01:52 | <Bakkot> | if that makes sense |
| 01:52 | <littledan> | Was it Ross rkirsling ? |
| 01:52 | <littledan> | who did Intl.Segmenter |
| 01:53 | <rkirsling> | littledan: I reviewed the patch but Yusuke implemented it |
| 01:56 | <michaelficarra> | Yusuke Suzuki is amazing! |
| 01:56 | <Bakkot> | +1 |
| 01:56 | <rkirsling> | he literally is |
| 02:01 | <shu> | that's interesting. if interop is not an aspiration of the standard, what is the value of the standard? similar general shapes? |
| 02:02 | <devsnek> | i had a similar line of questioning the other day on twitter |
| 02:02 | <devsnek> | in that case annex b but same idea |
| 02:03 | <shu> | devsnek: what's the relation to annex b? |
| 02:03 | <devsnek> | people thinking annex b == don't need to impl and then learning some of it is ecosystem reality |
| 02:04 | <rkirsling> | in ambulances?! 😱 |
| 02:04 | <devsnek> | or i guess, people saying it should remain annex b even though it is ecosystem reality |
| 02:04 | <shu> | devsnek: i don't think any implementers of web engines i know actually think that |
| 02:04 | <devsnek> | well people who make not-web-engines tend to dislike annex b |
| 02:04 | <shu> | i suppose XS had to learn the hard way |
| 02:04 | <devsnek> | but they still have to implement substr |
| 02:05 | <wsdferdksl> | Not all |
| 02:05 | <wsdferdksl> | C++ uses ECMAScript regular expressions. Merging in annex b would change how C++ regexps work. |
| 02:05 | <devsnek> | yeah there's definitely stuff that needs a closer look |
| 02:06 | <rkirsling> | holy crap |
| 02:06 | <shu> | devsnek: but annex b is still very much all about interop, the problem with annex b is that the subset of implementations it's intended to apply to doesn't match up with reality |
| 02:06 | <rkirsling> | I didn't know that particular detail |
| 02:07 | <Bakkot> | wsdferdksl do you know offhand if it specifies a particular version? |
| 02:07 | <Bakkot> | I don't have my copy of the C++ standard on hand |
| 02:08 | <Bakkot> | a particular version of ECMA-262, that is |
| 02:08 | <wsdferdksl> | It does. I'm not sure how often they update it. |
| 02:09 | <wsdferdksl> | It's kinda hard to get a hold of the official C++ standard |
| 02:09 | <devsnek> | reading through the latex on the draft repo |
| 02:09 | <devsnek> | it appears to be the third edition |
| 02:09 | <Bakkot> | looks like it's on ES3, yeah: https://github.com/cplusplus/draft/blob/78534e3883c9f296ecec6a26c51e55f6cb1bb395/source/intro.tex#L42 |
| 02:10 | <shu> | oh boy |
| 02:12 | <rkirsling> | wow, I can't imagine dealing with test262 before jsvu / eshost |
| 02:12 | <rkirsling> | I'm glad to have missed that era |
| 02:20 | <rickbutton> | leobalter: plz link slides link when you have a chance |
| 02:20 | <leobalter> | rickbutton: I'm not sure if I want to share the slides. I'll let you know. |
| 02:21 | <rickbutton> | ah yes of course |
| 02:21 | <rickbutton> | if you decide that you want to just drop them in the notes |
| 02:23 | <michaelficarra> | JSC date stuff is suuuuuper broken, take their result with a grain of salt |
| 02:23 | <rkirsling> | 😢 |
| 02:24 | <michaelficarra> | yeah JSC seems to implement everything in dates with signed 32-bit integers |
| 02:24 | <michaelficarra> | and that leaks all over the place |
| 02:38 | <littledan> | +100 on separating "normative optional" from "deprecated and discouraged" |
| 02:39 | <ljharb> | same |
| 02:39 | <littledan> | I would be fine with adding more deprecated things over time, whereas I'm very skeptical of adding more optional things |
| 02:40 | <rkirsling> | yeah I think one way or another we should increase clarity around that delineation |
| 02:43 | <michaelficarra> | when talking about __proto__ can we be clear about when we're talking about the syntax and when we're talking about the Object.prototype accessor |
| 02:43 | <Bakkot> | for clarity, what exactly are we asking for here? making the __proto__ getter/setter in the main spec but marked as normative optional? making __proto__ syntax normative non-optional? |
| 02:43 | <Bakkot> | yeah same question as michaelficarra |
| 02:44 | <bradleymeck> | i believe this doesn't change syntax |
| 02:44 | <ljharb> | accesor |
| 02:44 | <michaelficarra> | when people are making statements, I don't know which they're talking about |
| 02:44 | <michaelficarra> | if not both |
| 02:46 | <Bakkot> | fwiw I want `__proto__` syntax not to be marked as icky |
| 02:46 | <Bakkot> | it's the only way to do the thing it does |
| 02:46 | <michaelficarra> | same, __proto__ syntax is not bad |
| 02:47 | <michaelficarra> | that's not to say it couldn't have been better with its own syntactic form, but it's not bad |
| 02:48 | <shu> | it doesn't seem like to me we have consensus on this current proposal because there seems to be desire to have the discouragement note, which this PR doesn't have, and moreover, we don't have consensus that all things in the PR should be discouraged |
| 02:48 | <Bakkot> | yeah also we have only briefly mentioned exactly which things are included and in exactly which forms |
| 02:48 | <Bakkot> | I want to ask for consensus for the smaller question of, make the `__proto__` syntax required, and not marked as icky |
| 02:49 | <shu> | yes, there needs to be a condensed list of the asks |
| 02:49 | <michaelficarra> | I thought Gus's description was clear FWIW |
| 02:49 | <ljharb> | Bakkot: fwiw i don't personally consider the syntax icky (just aesthetically displeasing, but that's not sufficient imo) |
| 02:50 | <Bakkot> | michaelficarra the problem is that this is framed as moving "__proto__" but it covers a bunch of other stuff |
| 02:50 | <michaelficarra> | move __define{G,S}etter__ out of Annex B and make it mandatory; move __proto__ accessor out of Annex B and make it optional; move __proto__ syntax out of Annex B and make it mandatory |
| 02:50 | <michaelficarra> | am I missing anything? that's all Gus listed |
| 02:51 | <ljharb> | michaelficarra: ftr personally, i'd like the define's marked icky, and perhaps the proto accessor i guess; otherwise no additional asks from me. |
| 02:51 | <Bakkot> | michaelficarra also `__lookupGetter__` |
| 02:52 | <ljharb> | (ah yes ty, i want all the non-proto dunders marked icky) |
| 02:52 | <michaelficarra> | ljharb: okay so you're just asking that they are marked as icky before being put in the main spec |
| 02:52 | <ljharb> | michaelficarra: before/while, yes |
| 02:58 | <littledan> | I do prefer things to be required |
| 02:58 | <littledan> | was having troulbe unmuting |
| 03:00 | <devsnek> | littledan: do you object to it being optional |
| 03:00 | <devsnek> | oh nvm |
| 03:01 | <leobalter> | FWIW I support littledan's comment |
| 03:02 | <ljharb> | it's worth noting that inlining it in this way makes it easier to remove optionality in a future PR |
| 03:02 | <littledan> | I'm definitely happy with devsnek 's work overall. Inline normative optional in the main spec!!! |
| 03:02 | <haxjs> | What "icky" means? |
| 03:02 | <leobalter> | haxjs: discouraged / not recommended, I guess |
| 03:02 | <littledan> | btw bterlson earlier noted possible accessibility issues in the normative optional CSS I wrote |
| 03:03 | <littledan> | I think it'd be good for the editors to talk to a skilled a11y person to figure this out; I don't have the expertise myself :) |
| 03:03 | <Bakkot> | haxjs: it means roughly "discouraged" |
| 03:03 | <littledan> | haxjs: https://www.merriam-webster.com/dictionary/icky |
| 03:03 | <Bakkot> | yeah |
| 03:03 | <akirose> | haxjs: it's a slang word little kids use to describe something they don't like, especially messy things |
| 03:03 | <littledan> | ": offensive to the senses or sensibilities : distasteful " |
| 03:03 | <Bakkot> | littledan we've actually just come across this ourselves! |
| 03:03 | <littledan> | I feel like this definition makes a lot of sense |
| 03:03 | <Bakkot> | was talking to michaelficarra about fixing it |
| 03:03 | <haxjs> | So let's use "discouraged", not "icky" which is a slang. |
| 03:03 | <Bakkot> | (the accessibility thing) |
| 03:03 | <littledan> | haxjs: I believe the term "icky" has been used in this conversation as a placeholder, for something that we would definitely not really use |
| 03:04 | <akirose> | ++ |
| 03:04 | <rkirsling> | ^ |
| 03:04 | <littledan> | since it's "obviously" too informal |
| 03:04 | <haxjs> | I would like to say "icky" is "icky" :-) |
| 03:04 | <rkirsling> | I think it's like 讨厌 |
| 03:06 | <shu> | ljharb: what the current annex b wording is missing the thing i'd like to add: *even if* a thing is deprecated, i want to call out that that doesn't imply discouragement in engines if that engine's goal is interop with the existing ecosystem |
| 03:07 | <shu> | that nuance is something we don't have with the current wording |
| 03:07 | <ljharb> | that's totally fair |
| 03:07 | <shu> | and, engines whose goals are greenfield ecosystems are rare, like moddable |
| 03:07 | <ljharb> | ie separating out "discouraged to implement" vs "discouraged to use" |
| 03:07 | <shu> | not quite, it's discouraged to implement given an engine's goals |
| 03:07 | <ljharb> | gotcha, agreed |
| 03:07 | <shu> | web engines sure as hell won't be discouraged to implement |
| 03:08 | <shu> | and maybe, hermes too, even if it's not web |
| 03:09 | <haxjs> | It's not easy for outside (especially the non-native speakers) to understand the slangs. for example i still remember first time i see "sloppy" about ten years ago, i didn't know what that mean, and it cost me long time to figure out it just means "non-strict" :-) |
| 03:11 | <rkirsling> | sloppy is an interesting one, because when I started with TC39 I always wanted to call it "loose" mode |
| 03:11 | <rkirsling> | but our use of "icky" here was the same idea as our use of "smooth" |
| 03:11 | <rkirsling> | *smoosh |
| 03:11 | <avp> | shu: i'm not sure i understand your point, but as a reference, Hermes deliberately avoids implementing plenty of stuff in Annex B because we don't need web compatibility - we've had to add parts of it due to feature requests, but mostly it's been ok for us |
| 03:12 | <devsnek> | avp: i think our point is the "we've had to add parts of it due to feature requests" part |
| 03:13 | <rkirsling> | i.e. it was intended to be "obviously non-technical" in order to postpone bikeshedding about names/terms. I can see how that obviousness may be assuming a certain level of English intuition 🤔 but I'm also not sure how to fix that... |
| 03:13 | <shu> | avp: ah cool, okay. my point was that the "discouragement" isn't binary for implementers. we do a disservice to implementer readers of the spec if we don't add nuanced notes like "if you're an implementation that cares about maximal interop, you are actually encouraged to implement this optional feature, even if it's discouraged from being used" |
| 03:14 | <shu> | avp: and i'd like the editorial leeway to do that as editor, without seeking consensus for it |
| 03:14 | <devsnek> | does hermes target past es5 now |
| 03:15 | <avp> | devsnek: we're actively working on it - we've got a significant number of newer features implemented, but are still working our way through block scoping (variable resolution requires significant design changes in the compiler) |
| 03:16 | <avp> | but we do support generators, all the JS library functions up to ES2020, as well as some minor features like `?.` and `??` |
| 03:17 | <shu> | avp: oh boy, the amount of work each browser engine had to do to support block scoping... |
| 03:17 | <shu> | especially parameter scopes, though thankfully that got simplified a few years after the fact... |
| 03:18 | <rkirsling> | even now JSC has outstanding work to do to ensure that TDZ checks don't add up to a significant perf hit |
| 03:18 | <avp> | shu: we've had a fun time reasoning about function declaration hoisting in the presence of `let`/`const` as well as `catch` vars |
| 03:18 | <devsnek> | block scope was pretty easy in engine262 :^) |
| 03:20 | <shu> | avp: reasoning to elide TDZ checks? |
| 03:20 | <shu> | or correctness? |
| 03:20 | <Bakkot> | b.3.3, lol |
| 03:21 | <Bakkot> | the worst part |
| 03:21 | <devsnek> | proposal to move that to annex z |
| 03:21 | <Bakkot> | https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go |
| 03:21 | <avp> | yep that's the section |
| 03:22 | <Bakkot> | there's still outstanding issues with it too |
| 03:22 | <Bakkot> | https://github.com/tc39/ecma262/issues/913 |
| 03:22 | <devsnek> | scoping gave me some grief in the parser |
| 03:23 | <devsnek> | i wish all of js was like modules |
| 03:23 | <shu> | oh you're implementing b.3.3? why, if web compat isn't needed? |
| 03:23 | <avp> | comparing with other engines yielded behavior that we just couldn't reconcile with our mental model of the spec for a while - eventually we kind of understood it but we're still working on implementing all the variable resolution stuff in a way that works with our "lazy mode" compilation and our debugger information |
| 03:23 | <shu> | i mean like, out of all things in annex b to not implement, b.3.3 is it |
| 03:23 | <rkirsling> | ^ big true |
| 03:24 | <devsnek> | html comments |
| 03:25 | <rkirsling> | ^ medium true |
| 03:27 | <avp> | that seemed like the sort of section we might really want to implement because lots of people using our code run third party npm modules which we want to try and be compatible with |
| 03:29 | <avp> | plus, we really do want to support as much of the spec as we can without incurring significant size and/or perf costs, it's just that for chunks of Annex B it seems that the tradeoff would be bad (hence no `String.prototype.big`, etc) |
| 03:30 | <shu> | hm, getting mixed signals about the web compat part |
| 03:32 | <avp> | yeah i'll clarify - there's certain feature requests that fall into "compat" which come from Annex B that we were explicitly asked to implement by users - `String.prototype.substr` comes to mind because it was actually used in code running on Hermes. HTML stuff like `String.prototype.big` was not because we're intended to be used in React Native which doesn't use traditional HTML. |
| 03:33 | <devsnek> | substr ❤️ |
| 03:34 | <shu> | avp: ah, okay, and npm usage of things like `String#big` for packages react native codebases pull in is close to nil, i guess? |
| 03:34 | <jridgewell> | I don't understand why `substr` is Annex B. |
| 03:34 | <avp> | shu: correct |
| 03:34 | <jridgewell> | It's genuinely useful. |
| 03:35 | <jridgewell> | Put `substring` in Annex B instead, it's basicall `slice`. |
| 03:35 | <devsnek> | i'm guilty of using substr |
| 03:40 | <ljharb> | jridgewell: how is it useful to you? |
| 03:40 | <ljharb> | (substring is indeed terrible, it sorts its arguments which is bizarre) |
| 03:40 | <Bakkot> | sometimes the thing you have on hand is an start index and a length, not a start index and an end index |
| 03:41 | <devsnek> | we need `trimNull([startIndex])` that reads to the first occurrence of \0 :P |
| 03:48 | <Bakkot> | I don't know that I've ever had to find a null byte in a JS string |
| 03:48 | <Bakkot> | I guess for encoding to bytes sometimes |
| 03:51 | <jridgewell> | Using `length` as the second param is useful |
| 03:51 | <jridgewell> | I don't always know the end index, or want to add the current index to my already known length. |
| 04:14 | <haxjs> | jridgewell `substring` is not `slice`, substring may swap the index if i remember correctly |
| 04:15 | <jridgewell> | Hence the "basically" |
| 04:15 | <jridgewell> | The common features are the same |
| 04:15 | <jridgewell> | But there are edge cases that are different |
| 04:15 | <ljharb> | haxjs: substring sorts its arguments |
| 04:15 | <haxjs> | The problem is `substring` may be also used as freqently as `substr` ... I'm not sure |
| 04:16 | <ljharb> | (so `s.substring(a, b)` is identical to `s.substring(b, a)`) |
| 04:16 | <haxjs> | I really curious why these methods come from. It seems ES1 only have substring? |
| 04:17 | <devsnek> | i still feel like "i'm building a whole new separate ecosystem" is "i don't need 100% compat" not "the spec needs to cater to my case" |
| 04:18 | <Bakkot> | haxjs usually it's that either Netscape or Internet Explorer shipped it without worrying about whether it was in the standard |
| 04:20 | <haxjs> | consider there are some complains about codeunit vs codepoint, it seems "string.p.slice" would also "icky" for those people :-) |
| 04:20 | <Bakkot> | yup it's bad |
| 04:21 | <Bakkot> | shoulda been sliceCodeUnits or something |
| 04:21 | <ljharb> | slice is great. strings defaulting to code units is icky. |
| 04:22 | <haxjs> | do we have chance to introduce any encoding-neutral string ? |
| 04:22 | <devsnek> | i'm regretting being amenable on define/lookup getter/setter being optional now |
| 04:22 | <haxjs> | why regreting that? |
| 04:22 | <devsnek> | haxjs: you can already put whatever bytes you want into js strings |
| 04:23 | <shu> | yay, awesome, thanks rkirsling |
| 04:23 | <rkirsling> | thanks for the backup :D |
| 04:23 | <rkirsling> | (Bakkot too) |
| 04:25 | <haxjs> | devsnek: I mean dev need to remember codeunit/codepoint when they use string api. and when they use it, it also make the engine have to convert a utf8 encoding to utf16 encoding |
| 04:29 | <Bakkot> | engines don't always use utf8 internally |
| 04:29 | <michaelficarra> | I am very happy to see that this proposal restricts the exports to valid Unicode |
| 04:29 | <Bakkot> | v8 uses both |
| 04:29 | <Bakkot> | (IIRC) |
| 04:29 | <devsnek> | v8 has one and two byte representations |
| 04:30 | <devsnek> | they are not called utf8 and utf16 because they don't have to be valid unicode |
| 04:31 | <shu> | i don't think anybody uses utf8 internally |
| 04:31 | <shu> | but everybody does have a 1byte vs 2byte distinction |
| 04:31 | <michaelficarra> | FYI you can uncheck "show comments" in the upper right hamburger menu if you're trying to show off a diff |
| 04:31 | <devsnek> | saves a lot of memory |
| 04:32 | <mmarchini> | Tcq agenda item is still on the previous topic |
| 04:32 | <mmarchini> | (I think) |
| 04:32 | <rickbutton> | ^ cc robpalme |
| 04:34 | <haxjs> | shu: yeah, 1byte vs 2byte, because if u want efficiency for current api, u can only have such presentation. what i ask is whether it's possible to add a encoding-neutal apis so allow engine use real utf8/utf16 which save the encoding/decoding for io. |
| 04:34 | <littledan> | oh I forgot to mention, on the detached arraybuffer semantics PR: if this doesn't already match shipping web reality, can I ask that we have 1-2 implementations to prove it out, and test262 tests, before landing? |
| 04:34 | <robpalme> | thanks rick - fixed |
| 04:34 | <Bakkot> | wait is this actually true? |
| 04:34 | <michaelficarra> | I don't think so |
| 04:35 | <Bakkot> | is BOM not legal at the start of a unicode-16 string? |
| 04:35 | <shu> | littledan: the PR matches SM and V8 behavior |
| 04:35 | <shu> | littledan: JSC disagrees with subparts of the PR |
| 04:35 | <littledan> | Oh, I see, carry on |
| 04:35 | <littledan> | but, test262? |
| 04:35 | <devsnek> | Bakkot: it's only valid in 16 and 32 |
| 04:35 | <shu> | disagrees meaning mismatches, not active disagreement |
| 04:35 | <shu> | test262 i don't actually know, rkirsling? |
| 04:35 | <littledan> | (sorry, it's 6:30 AM here, and I haven't slept tonight yet) |
| 04:36 | <devsnek> | well i guess it's valid in 8, but it isn't used |
| 04:36 | <rkirsling> | rwaldron was suggesting he was going to follow along with the PR and help with the tests |
| 04:36 | <rkirsling> | if that's not the case then I can contribute there |
| 04:36 | <michaelficarra> | lol this isn't true either, ugh |
| 04:37 | <Bakkot> | need mathiasbynens here |
| 04:37 | <michaelficarra> | https://tc39.es/ecma262/#sec-encodeuricomponent-uricomponent |
| 04:38 | <littledan> | the answer is yes; it's been stated several times. I think we can iterate on the wording on the issue |
| 04:38 | <rkirsling> | Bakkot: +1 |
| 04:39 | <rkirsling> | wait but shu there is the `configurable` bit |
| 04:39 | <shu> | Bakkot: why can't we volunteer michaelficarra as the new utf abyss gazer |
| 04:39 | <shu> | littledan: rkirsling: oops, ross's right about the [[Configurable]] change, that's not in anyone's implementation |
| 04:39 | <shu> | littledan: i'll ship that soon and be on the lookout for bugs |
| 04:39 | <rkirsling> | <3 |
| 04:39 | <shu> | i see no way to actually usecounter that |
| 04:39 | <littledan> | OK, let's wait to land this until we get 1-2 shipping implementations |
| 04:40 | <littledan> | any concerns with that? |
| 04:40 | <rkirsling> | fine by me |
| 04:40 | <shu> | sure, that should be fine |
| 04:40 | <shu> | could someone note that on the PR? |
| 04:40 | <shu> | i will probably forget |
| 04:41 | <keith_miller> | Bakkot: Is there any order for prototype methods generally in the spec? Is it the same as the order they are listed? |
| 04:41 | <Bakkot> | keith_miller nope |
| 04:41 | <keith_miller> | hmm, ok |
| 04:41 | <rkirsling> | littledan: would you like to add a comment to that end? |
| 04:41 | <Bakkot> | people have proposed changing that |
| 04:41 | <Bakkot> | "nope" as in "there is no order", to be clear |
| 04:41 | <littledan> | rkirsling: I'll do that |
| 04:41 | <keith_miller> | Bakkot: As long as its whatever the current JSC order is I'm happy :P |
| 04:42 | <Bakkot> | keith_miller to be clear, my length/name PR requires a change from JSC and not from anyone else |
| 04:42 | <Bakkot> | I hope that was clear |
| 04:42 | <keith_miller> | Oh, I know |
| 04:42 | <Bakkot> | ok good good |
| 04:42 | <keith_miller> | I'm doing it now |
| 04:43 | <keith_miller> | Bakkot: I'm just lazy :P |
| 04:46 | <Bakkot> | ain't we all |
| 04:46 | <Bakkot> | I try to phrase these PRs in a way which allows the most people to be lazy, as a rule |
| 04:46 | <Bakkot> | re: "valid unicode", I guess the pedantic thing is "is valid unicode if interpreted as a UTF-16BE string" |
| 04:46 | <michaelficarra> | Bakkot: pretty sure all your PRs from this meeting only require JSC changes |
| 04:46 | <shu> | i'm not so much lazy as anxious |
| 04:47 | <Bakkot> | or, that's true at least wrt the BOM |
| 04:48 | <haxjs> | does that mean we can't have 1cm 1deg , etc? |
| 04:48 | <rkirsling> | michaelficarra: womp womp |
| 04:48 | <keith_miller> | haxjs: Yeah, seems like it. |
| 04:49 | <haxjs> | or is that mean 1cm is allowed but 0x1cm is not? |
| 04:49 | <keith_miller> | Oh maybe you're right |
| 04:49 | <keith_miller> | Worth a questino |
| 04:50 | <haxjs> | push a question in the queue |
| 04:52 | <michaelficarra> | I don't like that an _ would be mandatory whereas people are learning today that you can pretend they aren't there |
| 04:53 | <devsnek> | i think it should be `@` |
| 04:53 | <devsnek> | applies to the decorator idea and discourages people from using asi |
| 04:53 | <ljharb> | i'm pretty confident there's web code that depends on bigint literal keys in object literals |
| 04:54 | <Bakkot> | that is a remarkable claim |
| 04:54 | <ljharb> | you think? |
| 04:54 | <ljharb> | i mean, bigints are new |
| 04:54 | <rkirsling> | michaelficarra: can you expand upon "pretend they aren't there"? |
| 04:54 | <haxjs> | we have bigint landed not very long, so maybe not a big problem? |
| 04:54 | <michaelficarra> | rkirsling: 1_2_3 === 123 |
| 04:54 | <ljharb> | but there was a bunch of discussion about bigint's toString not having the "n" for this exact reason so i'm very skeptical that this was a surprise |
| 04:54 | <rkirsling> | ohhh |
| 04:55 | <gibson042> | `{ 9007199254740993n: "precise" }` |
| 04:55 | <rkirsling> | yeah true, C++ uses ' as a separator so there's no clash with _ for custom literals |
| 04:55 | <Bakkot> | ljharb I just don't expect anyone to have wanted this |
| 04:55 | <Bakkot> | I thought the toString thing was for access, not definition |
| 04:56 | <Bakkot> | as in `x[0n] === x[0]` |
| 04:56 | <Bakkot> | not `{ 0n: 'foo' }`, which is a very strange thing to write |
| 04:56 | <ljharb> | iirc it came up in both contexts. the access reason was surely more pressing tho |
| 04:56 | <ljharb> | certainly not making the claim that people *want* this but i'd be surprised if nobody shipped it by now |
| 04:56 | <michaelficarra> | Bakkot: same |
| 04:56 | <Bakkot> | I would be surprised if people shipped it |
| 04:57 | <michaelficarra> | yeah a lot of people use compilers |
| 04:57 | <Bakkot> | (to a website with nontrivial usage, anyway, where nontrivial is > 10 humans / week) |
| 05:00 | <rkirsling> | michaelficarra: ahh your tagged template point is a good one |
| 05:01 | <michaelficarra> | they were called quasis in the beginning for a reason |
| 05:02 | <michaelficarra> | (quasi as in quasi-literal) |
| 05:04 | <shu> | michaelficarra: is your concern that some suffixes are builtin and thus have a completely different analyzability / performance reasons? |
| 05:04 | <keith_miller> | devsnek: woah!!! with is fast in JSC |
| 05:05 | <keith_miller> | You get all the optimizations |
| 05:05 | <shu> | michaelficarra: err, s/reasons/profile, dunno why i typed out reasons |
| 05:05 | <devsnek> | keith_miller: not a problem for numeric suffixes then :P |
| 05:05 | <rkirsling> | keith_miller: does that mean it's no longer evil |
| 05:05 | <rkirsling> | :p |
| 05:05 | <michaelficarra> | shu: no, my concern has nothing to do with performance and is all about language design and syntax budget |
| 05:06 | <shu> | michaelficarra: well, i threw in analyzability in there |
| 05:06 | <shu> | i'll wait to hear it when we get to it |
| 05:06 | <michaelficarra> | not that either, no |
| 05:06 | <devsnek> | but i do think separate namespace is an actively more confusing/worse dev experience |
| 05:06 | <haxjs> | I think dan's motivation of separate namespace is good. |
| 05:06 | <Bakkot> | we should just use template literals |
| 05:06 | <Bakkot> | tagged templates, that is |
| 05:07 | <Bakkot> | they work fine for this use case |
| 05:07 | <Bakkot> | people are even starting to have their editors lint them |
| 05:07 | <devsnek> | cm`123` |
| 05:07 | <Bakkot> | https://marketplace.visualstudio.com/items?itemName=frigus02.vscode-sql-tagged-template-literals |
| 05:07 | <Bakkot> | devsnek right |
| 05:07 | <Bakkot> | that's perfect |
| 05:07 | <devsnek> | sure why not |
| 05:07 | <devsnek> | you should bring it up |
| 05:07 | <Bakkot> | michaelficarra's already on the queue |
| 05:07 | <Bakkot> | gonna let him say it |
| 05:07 | <keith_miller> | devsnek: I wasn't actually following the context. I just wanted to call that out :P |
| 05:08 | <haxjs> | consider someone write code `var x = 1m;` it's possible someone will add code like `let m = ...` and din't notice the `m` because it's suffix. |
| 05:08 | <devsnek> | keith_miller: wasn't saying they must be slow, more that if they are slow, what's the point in making the `1px` inside them fast |
| 05:08 | <devsnek> | (at the cost of dev exp) |
| 05:08 | <keith_miller> | oh, I mean I hope we aren't making it harder than anything else |
| 05:08 | <keith_miller> | in a with scope |
| 05:08 | <haxjs> | template literals like ``px`1``` ??? |
| 05:09 | <devsnek> | keith_miller: it seems like a function call so |
| 05:09 | <devsnek> | if you can optimize those |
| 05:09 | <Bakkot> | hax yup |
| 05:09 | <haxjs> | I think dan want number from parse time |
| 05:10 | <haxjs> | template string need runtime cost |
| 05:10 | <keith_miller> | Yeah, I don't really care for inside a with scope as long as it's lexically obvious |
| 05:10 | <shu> | this proposal definitely has runtime cost |
| 05:11 | <haxjs> | yeah it have runtime cost, but i think dan don't want the extra cost of `parseInt(s)` |
| 05:11 | <Bakkot> | don't think that cost warrants a new syntactic feature |
| 05:11 | <haxjs> | it not to save such cost , the proposal itself is for dev experience. |
| 05:13 | <shu> | the weak link for me here is the constraint that "decimal ought to be polyfillable" |
| 05:13 | <rickbutton> | anecdotally I just moved an entire codebase off of tagged template literals for GraphQL queries, we found that editor support was less than ideal and was brittle |
| 05:13 | <shu> | not having this doesn't imply decimal can't use a suffix, but that it can't be polyfilled with the same syntax |
| 05:13 | <haxjs> | i understand we may worry about the syntax budget here again, so maybe we could try to find some more general solution. For example old bind op allow u write `1::px()` |
| 05:14 | <devsnek> | haxjs: the `px` function needs the source text of the numeric literal |
| 05:14 | <haxjs> | devsnek: current CSS.px do not need raw literal. |
| 05:14 | <devsnek> | right but other things do |
| 05:14 | <devsnek> | like a decimal type |
| 05:14 | <Bakkot> | we already found a more general solution: it's tagged templates. that's what they're for |
| 05:14 | <haxjs> | even we need it, we could consider add such ability to bind op! |
| 05:15 | <devsnek> | Bakkot: inverted tagged templates though :P |
| 05:15 | <rickbutton> | yeah template literal suffixes |
| 05:15 | <devsnek> | what happens if you prefix and suffix it |
| 05:15 | <haxjs> | tagged template have the bad order (prefix vs suffix) and only have raw string not parsed value. |
| 05:16 | <devsnek> | templates can afford to call parseInt because they can cache it |
| 05:16 | <Bakkot> | parsing small integers is not slow, I don't think that's an actual problem |
| 05:16 | <ljharb> | if the parsed value isn't needed tho, then that seems like it's more efficient for most cases? |
| 05:16 | <rickbutton> | devsnek: pre``string``post => `post(pre("string")` |
| 05:16 | <Bakkot> | I don't hate tagged template suffixes, tbh |
| 05:16 | <devsnek> | i slightly dislike them |
| 05:16 | <rickbutton> | I would love tagged template suffixes |
| 05:16 | <rkirsling> | is suffix viable to add? it is, right? |
| 05:16 | <rickbutton> | y devsnek |
| 05:16 | <rkirsling> | I don't hate that |
| 05:16 | <devsnek> | rkirsling: ASI |
| 05:16 | <ljharb> | ``` `3`px ``` ? |
| 05:16 | <rkirsling> | yeah |
| 05:17 | <devsnek> | rickbutton: no objective reasons |
| 05:17 | <rbuckton> | There was a suggestion on the issue tracker to use `'` as a separator, as in `3'px`: https://github.com/tc39/proposal-extended-numeric-literals/issues/8#issuecomment-361714521 |
| 05:17 | <rkirsling> | devsnek: yeah but like whitespace wouldn't be allowed, right? |
| 05:17 | <rickbutton> | devsnek: I read "slightly" as "strongly" whoops |
| 05:17 | <shu> | the numeric suffixes proposal was an update, not asking for any advancement, right? |
| 05:17 | <devsnek> | yes |
| 05:17 | <rickbutton> | no advancement |
| 05:18 | <shu> | thanks |
| 05:18 | <rickbutton> | rkirsling: String.raw\nfoo is allowed, would be weird if you couldn't do it on the rhs i guess |
| 05:19 | <rkirsling> | oh |
| 05:19 | <devsnek> | :D |
| 05:19 | <Bakkot> | weird but not fatal, I think |
| 05:19 | <rickbutton> | agree |
| 05:19 | <devsnek> | js's motto |
| 05:19 | <rkirsling> | wow that is so strange to me |
| 05:20 | <ljharb> | seems a bit weird to me to write that code on the lhs in the first place |
| 05:20 | <rkirsling> | I did not realize you didn't need the `` |
| 05:20 | <ljharb> | (with the \n) |
| 05:20 | <devsnek> | wait until you learn about all the places you can put subscript operators |
| 05:20 | <Bakkot> | rkirsling oh, you do need that |
| 05:20 | <Bakkot> | the `` is necessary, it just can have a newline before it |
| 05:20 | <Bakkot> | " String.raw\n` foo ` " works |
| 05:20 | <devsnek> | there are people who do `a.\nb.\nc` |
| 05:20 | <rickbutton> | yeah sorry bad escaping, you still need the backticks |
| 05:21 | <rkirsling> | ohh what rickbutton works as-is but it's *because* of ASI, I see |
| 05:21 | <rkirsling> | "works" as in, doesn't thro |
| 05:21 | <rkirsling> | w |
| 05:21 | <devsnek> | unless foo is undefined |
| 05:21 | <rkirsling> | right |
| 05:22 | <ljharb> | devsnek: trailing dot, ick |
| 05:22 | <ljharb> | devsnek: i've seen that pattern in ruby, is it common in other langs? |
| 05:22 | <devsnek> | i've seen it in js |
| 05:22 | <Bakkot> | people write it in JS |
| 05:22 | <devsnek> | dunno about "common" |
| 05:22 | <Bakkot> | sometimes they complain in prettier's tracker / social media |
| 05:22 | <Bakkot> | they get shut down 'cause it's rare enough |
| 05:22 | <rickbutton> | gross |
| 05:22 | <devsnek> | what you really have to worry about is the people who put each lexical token on its own line |
| 05:29 | <rkirsling> | keith_miller: that's good to confirm, I wondered if this was a watchpoint-y sorta thing |
| 05:29 | <keith_miller> | I think it's just a named property |
| 05:29 | <keith_miller> | Sometimes a custom property until you set it |
| 05:30 | <devsnek> | just did a test in v8 |
| 05:30 | <haxjs> | what' function.length be infinity mean? is it affect any other things? |
| 05:30 | <devsnek> | setting length to infinity makes accessing `call` slower |
| 05:30 | <ljharb> | does it? |
| 05:30 | <ljharb> | i'd think it means the same as if you set the function's length to `'foo'` |
| 05:30 | <haxjs> | why it would be slow? |
| 05:31 | <keith_miller> | Yeah, that's surprising |
| 05:31 | <rkirsling> | oh nice, Alexey is like Yusuke #2 |
| 05:31 | <keith_miller> | but I don't V8 so.. lol |
| 05:31 | <rkirsling> | I guess I overlooked that patch |
| 05:32 | <devsnek> | looks like it completely destroys the IC |
| 05:32 | <devsnek> | keith_miller: https://gc.gy/68371336.png |
| 05:34 | <haxjs> | so the conclusion is infinity? |
| 05:34 | <Bakkot> | haxjs yup |
| 05:34 | <haxjs> | interesting :-) |
| 05:34 | <michaelficarra> | devsnek: why f.call() and not f()? |
| 05:34 | <Bakkot> | as to "what does it mean", it doesn't really mean anything, and it doesn't affect anything else to my knowledge |
| 05:35 | <devsnek> | michaelficarra: it affects the property access, not the call |
| 05:35 | <shu> | jridgewell: devsnek: so this change has no new performance implication |
| 05:35 | <devsnek> | i included the call itself because idk the specifics of v8's DCE |
| 05:35 | <jridgewell> | 👍 |
| 05:35 | <shu> | if i'm reading correctly as devsnek noted, setting/defining .length on JSFunctions will transition the map |
| 05:35 | <shu> | but that's true today |
| 05:35 | <jridgewell> | As long as this isn't going to cause some weird cascade to other functions |
| 05:36 | <Bakkot> | this doesn't require the major engines to change |
| 05:36 | <shu> | yeah, it should transition the map of that function, not all functions |
| 05:37 | <devsnek> | you could deopt all functions by changing F.p.length :P |
| 05:37 | <shu> | what happens is that .length is implemented in V8 as a getter/setter pair (even though at the language level it is not), except the setter is a magical engine thing that transitions the .length to a normal data property |
| 05:38 | <jridgewell> | Does anyone see slides? |
| 05:38 | <devsnek> | magic accessors are a theme in implementations |
| 05:38 | <devsnek> | jridgewell: yes |
| 05:38 | <shu> | devsnek: i'm not sure you can |
| 05:39 | <shu> | how does that work? |
| 05:39 | <devsnek> | shu: changing f.p.length? |
| 05:39 | <shu> | yeah, how would that deopt all functions? |
| 05:39 | <devsnek> | hm it might only be anonymous ones |
| 05:39 | <devsnek> | i would have to actually check |
| 05:40 | <shu> | i thought all functions have a their own length property on their maps |
| 05:40 | <ljharb> | they should |
| 05:40 | <devsnek> | yeah but i don't remember what happens when the prototype map changes |
| 05:40 | <devsnek> | in terms of IC |
| 05:40 | <devsnek> | not 100% sure if it actually deopts all functions, was going for a joke more than anything else |
| 05:43 | <devsnek> | wow it deoptimized property access off a named function |
| 05:45 | <ljharb> | sffc: quickjs |
| 05:46 | <littledan> | I'm pretty sure people do use QuickJS for stuff actually |
| 05:47 | <devsnek> | it gets use in wasm |
| 05:48 | <sffc> | 👍 |
| 05:48 | <haxjs> | I know some people use quickjs heavily |
| 05:52 | <ljharb> | littledan: there is no such clause. you certainly can (and have) withhold consensus, but there's no deadline for anything but proposals. normative changes aren't all proposals. |
| 05:52 | <ljharb> | needing more time to review something is ofc a legit reason not to provide consensus |
| 05:53 | <littledan> | OK, so that's what I'm saying |
| 05:53 | <ljharb> | alrighty. you could say that even if it'd been on the agenda for 2 months, ftr. |
| 05:53 | <akirose> | ryzokuken: if you're talking we can't hear you |
| 05:53 | <littledan> | I like to review everything ahead of the meetings in written format |
| 05:54 | <littledan> | even if not all TC39 delegates do these reviews, I like to do so |
| 05:54 | <littledan> | I'm very happy that Bakkot is doing these changes to clarify these edge cases |
| 05:54 | <littledan> | and bring interoperability |
| 05:54 | <shu> | littledan: i'm somewhat surprised by this. i thought the change small enough to review on the fly during his presentation |
| 05:55 | <rkirsling> | I too thought it was quite trivial, if this is a per-case decision to make |
| 05:56 | <ljharb> | robpalme: update the queue topic? |
| 05:56 | <devsnek> | i feel like all my items get changed during the presentation |
| 06:02 | <shu> | ljharb: that is a problem with people |
| 06:02 | <ljharb> | that is true |
| 06:02 | <shu> | one way to combat this could be legalistic disclaimers, but we know how EULA works out even in a legal system *with* teeth |
| 06:03 | <devsnek> | idk if some random person does this we can just tell them off |
| 06:04 | <devsnek> | maybe we can start with "standard"js |
| 06:04 | <shu> | but i think the actual way to combat this is to make TC39 plenary less of a "room where it all happens", because it's not actually true anyway |
| 06:07 | <leobalter> | littledan: the goal is to facilitate this to make it work. I know there are a lot to discuss |
| 06:09 | <littledan> | about the earlier topic from Kevin: I'm legitimately extremely tired. It's 8 AM and I didn't get to sleep all last night. This is a topic I'm interested in, and I've been trying to follow the work around it. |
| 06:10 | <littledan> | I just am unable to take a nap before the meeting. I tried to sleep in late before, this but it wasn't enough. |
| 06:10 | <rkirsling> | right :( that really takes a lot of stamina |
| 06:28 | <Bakkot> | time zones are rough |
| 06:28 | <Bakkot> | I expect next meeting to get a little silly |
| 12:13 | <littledan> | hey, is there an IRC command that I can copy-paste to send a message to the chairs? |
| 12:13 | <littledan> | I'd rather not bother one person individually, but last meeting, I had some kind of typo in the command I tried to use, and the message was silently lost |
| 12:14 | <littledan> | ah sorry I see this in the topic :) |
| 12:14 | <littledan> | `/notice #tc39-chairs your message here` |
| 16:59 | <keith_miller> | Bakkot: Are there tests for the length change? I want to make sure I found all the places... |
| 17:00 | <Bakkot> | keith_miller not as yet. I'll try to come up with some to add to test262 before merging the PR |
| 17:01 | <keith_miller> | Bakkot: Ok, well, I'm going to land the change now then and double back once there are tests. If you remember, can you ping me when they land? |
| 17:01 | <Bakkot> | will do |
| 17:01 | <keith_miller> | thanks! |
| 17:02 | <Bakkot> | there's basically three categories: intrinsics like Function, weird intrinsics like %ThrowTypeError%, and synthesized on-the-fly functions like you get from `new Promise((f1, f2) => ...)` or `await { then: f => ... }` etc |
| 17:03 | <Bakkot> | I am not gonna add comprehensive tests for the first kind because there are so many, but I'll try to be comprehensive about the latter two |
| 17:05 | <keith_miller> | gotcha, I think the first kind is the kind that we got wrong. I changed it so that the base class for the C++ functions takes a length so you have to get the right order. Assuming we want the order to be "length", "name", "prototype" eventually |
| 17:05 | <keith_miller> | I think all our functions that are wrapping "built-in" JS and user JS are correct |
| 17:05 | <keith_miller> | were correct* |
| 17:06 | <keith_miller> | That said, our implementation details don't really map to things in the spec. So I could be missing some cases |
| 17:06 | <keith_miller> | It's more just about whether something is implemented in JS or C++ |
| 17:08 | <devsnek> | Bakkot: test262 has a list of top level intrinsics you can use |
| 17:09 | <devsnek> | we could abstract the logic here for testing the properties https://github.com/tc39/test262/blob/main/test/built-ins/Function/prototype/toString/built-in-function-object.js |
| 17:10 | <Bakkot> | keith_miller: also take a look at `console.log(Object.getOwnPropertyNames(Proxy.revocable({}, {}).revoke))` |
| 17:11 | <Bakkot> | devsnek neat |
| 17:11 | <keith_miller> | >>> Object.getOwnPropertyNames(Proxy.revocable({}, {}).revoke) |
| 17:11 | <keith_miller> | length,name |
| 17:11 | <keith_miller> | Is what I get after my change |
| 17:11 | <Bakkot> | good good |
| 17:12 | <devsnek> | is it legal to install additional properties between those |
| 17:12 | <devsnek> | `length,color,name` |
| 17:13 | <keith_miller> | more likely length, prototype, name |
| 17:13 | <keith_miller> | since prototype is unspecified IIUC |
| 17:13 | <devsnek> | sure i just mean |
| 17:13 | <devsnek> | we should take that into account in the tests |
| 17:13 | <devsnek> | if its allowed |
| 17:13 | <keith_miller> | Yeah, I think the spec doesn't say anything |
| 17:13 | <keith_miller> | What that means is... 🤷♂️ |
| 17:13 | <devsnek> | forbidden extensions: functions must not have colors |
| 17:14 | <keith_miller> | You could put something in the function constructor that says no properties should be added until after length and name |
| 17:14 | <keith_miller> | err function create operation (whatever that's called in the spec) |
| 17:15 | <devsnek> | oh no i have name/length for some things |
| 17:15 | <keith_miller> | what things? |
| 17:15 | <devsnek> | hard to say for sure |
| 17:16 | <Bakkot> | yeah I'm just going to assert on relative order, not the actual list |
| 17:16 | <devsnek> | i have `CreateBuiltinFunction()\nSetFunctionName\nSetFunctionLength()` sprinkled through a lot of the spec |
| 17:16 | <devsnek> | the source* |
| 17:16 | <Bakkot> | find-replace |
| 17:16 | <devsnek> | idk how to find replace that |
| 17:17 | <devsnek> | i'm just grepping for SetFunctionName |
| 17:17 | <keith_miller> | SetFunctionName isn't inside CreateBuiltinFunction()? Seems like that would be the idiomatic way to do it |
| 17:18 | <Bakkot> | the point of this change is to make that change to the spec! |
| 17:18 | <Bakkot> | currently the spec just asserts the existence of these properties; we want to make it install them in CreateBuiltinFunction |
| 17:18 | <keith_miller> | Bakkot: For what it's worth I think you can get add a thing to the spec that says length, name must be the first two properties on all functions |
| 17:18 | <keith_miller> | well that's some poor phrasing lol |
| 17:18 | <keith_miller> | but I think you get the point |
| 17:18 | <devsnek> | oh if it moves them to createbuiltinfunction |
| 17:19 | <devsnek> | that makes this way easier |
| 17:19 | <Bakkot> | that would require V8 and Chakra to change |
| 17:19 | <Bakkot> | but yeah probably |
| 17:19 | <keith_miller> | "that would require V8 and Chakra to change" is that in response to my comment? |
| 17:19 | <Bakkot> | keith_miller yeah |
| 17:19 | <Bakkot> | wait, SM and Chakra |
| 17:19 | <keith_miller> | Where does that occur? |
| 17:19 | <Bakkot> | not V8 |
| 17:19 | <keith_miller> | Is prototype first or something? |
| 17:20 | <Bakkot> | yup |
| 17:20 | <keith_miller> | gotcha |
| 17:20 | <keith_miller> | Seems like prototype should be 3rd because it's only sometimes there |
| 17:20 | <keith_miller> | but that's a nit |
| 17:20 | <keith_miller> | and I don't really care lol |
| 17:20 | <Bakkot> | devsnek https://github.com/tc39/ecma262/pull/2116/files#diff-3540caefa502006d8a33cb1385720803R8889-R8890 |
| 17:21 | <Bakkot> | yeah that's my feeling also |
| 17:21 | <Bakkot> | plus then it's alphabetic! |
| 17:21 | <devsnek> | very exciting |
| 17:21 | <keith_miller> | "alphabetic" until you get to any other functions lol |
| 17:21 | <devsnek> | well the signature of CreateBuiltinFunction is not exciting |
| 17:21 | <devsnek> | but oh well |
| 17:21 | <Bakkot> | yeah... |
| 17:21 | <Bakkot> | hope to get tooling to help with that eventually |
| 17:21 | <Bakkot> | so you can see the signature of an AO if you hover over it, or something |
| 17:22 | <devsnek> | we should integrate objective c's named arguments into the spec |
| 17:22 | <Bakkot> | ehhhhhh |
| 17:22 | <keith_miller> | I lowkey love that about Obj-C |
| 17:22 | <keith_miller> | It makes reading code so easy |
| 17:22 | <devsnek> | yeah but my editor can just |
| 17:22 | <keith_miller> | which is what I'm doing like 90% of the time |
| 17:22 | <devsnek> | insert the names anyway |
| 17:22 | <keith_miller> | what do you mean by that? |
| 17:23 | <devsnek> | like it takes the code `foo(a, b, c)` and renders it as `foo(arg1: a, arg2: b, arg3: c)` |
| 17:23 | <keith_miller> | Oh, I see |
| 17:23 | <devsnek> | i think vscode can do that too |
| 17:24 | <devsnek> | i know that's advertised as a feature of rust-analyzer |
| 17:24 | <keith_miller> | That doesn't work too well for C++ since it's common-ish practice to have the signature not have variable names only types |
| 17:24 | <Bakkot> | no reason the rendered spec couldn't pull that trick (as an opt-in mechanism); main issue would be discoverability probably |
| 17:24 | <keith_miller> | And you'd have to integrate with the compiler |
| 17:24 | <keith_miller> | which can be problematic if you're trying to get something compiling |
| 17:24 | <devsnek> | yeah you have to use language servers |
| 17:24 | <devsnek> | rip battery life |
| 17:24 | <keith_miller> | that said, that's a nice feature |
| 17:25 | <devsnek> | i think this screenshot is from vscode https://user-images.githubusercontent.com/2690773/75099758-74d99400-55d6-11ea-856f-565e130a7e0c.png |
| 17:26 | <Bakkot> | intellij is reasonably good at this for java too |
| 17:27 | <Bakkot> | there is so much room for our tools to get better... |
| 17:27 | <Bakkot> | I think about this a lot more since I started working with a smalltalker, since this is all they can talk abouot |
| 17:27 | <Bakkot> | (that is, a person who worked on/with Smalltalk, the language) |
| 17:29 | <devsnek> | i think you mean smalltalk, the os |
| 19:16 | <dandclark> | bradleymeck: Did you get a chance to review https://tc39.es/proposal-import-assertions/? It's on the schedule for today, and we've heard from the other Stage 3 reviewers; it would be great to confirm whether you've also been able to review. |
| 19:42 | <bradleymeck> | dandclark: i've had reviews in meetings and had a final one on saturday to clear things up |
| 19:43 | <bradleymeck> | shu and ljharb went over concerns about some editorial wording for the host constraint but other than that it looked fine from my end |
| 19:55 | <dandclark> | bradleymeck: Great, thanks! |
