| 14:16 | <bradleymeck> | i'm going to need an editorial and spec review of https://tc39.es/proposal-upsert/ , added to agenda as requesting stage 3, but unclear a bit on what that means when you need the review. |
| 14:16 | <bradleymeck> | seems like going towards stage 3 made sense, but we cannot advance it this meeting realistically |
| 14:16 | <bradleymeck> | slides also cover the recent changes https://docs.google.com/presentation/d/16PtTpuvkTFycaaqkk5XGZRPLNwzUrzBuN9y7VSrGX9k/edit#slide=id.p |
| 14:23 | <bradleymeck> | devsnek: I made https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers for `import {"" as foo} from "";` gonna do the spec today |
| 14:23 | <bradleymeck> | i remember you were asking about it |
| 14:37 | <devsnek> | bradleymeck: nice |
| 14:38 | <bradleymeck> | the only hard bit is going to be figuring out how to phrase it needs to be representable as valid utf8 |
| 14:40 | <devsnek> | we have infra for valid utf8 thanks to {en,de}codeURI{component} |
| 14:42 | <bradleymeck> | oh thank god |
| 14:43 | <devsnek> | well in a prose-y way anyway |
| 14:43 | <jackworks> | internal slot X + getter x(), or configurable-readonly property x. Which one is better in the API design? |
| 14:44 | <devsnek> | jackworks: check out AggregateError errors property |
| 14:46 | <bradleymeck> | devsnek: nah, under the hood i see [[IsUnpairedSurrogate]] which is all i needed really |
| 14:46 | <bradleymeck> | mathiasbynens: you might know better, is there anything besides surrogates that is a concern when checking if a string in JS is valid utf8? |
| 14:47 | <jackworks> | oh I got the link https://github.com/tc39/proposal-promise-any/issues/38 |
| 14:47 | <jackworks> | thanks I'll read it |
| 14:48 | <mathiasbynens> | bradleymeck: for valid UTF-8, it's just surrogates |
| 14:48 | <bradleymeck> | mathiasbynens: so a static check that all the code points in a string literal are paired would be fine? |
| 14:50 | <mathiasbynens> | bradleymeck: there are cases where you want to check for the larger set of non-characters but that shouldn't be security-sensitive unless you're doing something weird |
| 14:50 | <bradleymeck> | mathiasbynens: this is trying to ensure w/e string is valid utf-8 due to wasm integration https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers#concerns |
| 14:50 | <jackworks> | > Getters are for querying internal state; if there's nothing "internal" about it, a data property seeems more idiomatic to me. |
| 14:50 | <bradleymeck> | non-characters? |
| 14:51 | <jackworks> | this make sense to me, if the data is designed to be immutable, it might be better to use readonly property instead of slot+getter |
| 14:51 | <mathiasbynens> | bradleymeck: U+FDD0 et al http://www.unicode.org/faq/private_use.html#nonchar4 |
| 14:53 | <bradleymeck> | mathiasbynens: interesting, Name in WASM allows for those it looks like https://webassembly.github.io/spec/core/binary/values.html#binary-utf8 |
| 14:53 | <mathiasbynens> | bradleymeck: imho everything should allow those, since they can perfectly be represented in utf8 |
| 14:53 | <devsnek> | name is not the same as exports |
| 14:53 | <mathiasbynens> | bradleymeck: but e.g. Chrome's JSON parser/writer didn't until I recently fixed it |
| 14:53 | <mathiasbynens> | so ymmv |
| 14:54 | <bradleymeck> | mathiasbynens: seems reasonable, this is a spec change just ensuring it is valid utf-8 not that it is sensible |
| 14:54 | <devsnek> | oh i see |
| 14:54 | <devsnek> | bradley you linked to the text format spec in your proposal repo |
| 14:54 | <bradleymeck> | doh |
| 14:54 | <devsnek> | should be binary format |
| 14:55 | <bradleymeck> | done |
| 14:55 | <devsnek> | 👍🏻 |
| 14:55 | <bradleymeck> | mathiasbynens: so only need to iterate and check [[IsUnpairedSurrogate]] it seems, thanks |
| 14:55 | <devsnek> | i still need to fix my utf8 functions in engine262 |
| 14:56 | <devsnek> | i think something is broken in decoding |
| 15:27 | <devsnek> | i figured out why i don't like reading the prose in the spec |
| 15:27 | <devsnek> | its too wide |
| 15:29 | <devsnek> | adding `max-width: 50em` to `p` helps a lot |
| 17:26 | <bradleymeck> | why is `export {package as import}` valid when 100% you can't have a local binding named package? |
| 17:26 | <bradleymeck> | i get that it will blow up later, but it seems like left hand side should be an Identifier not IdentifierName? |
| 17:29 | <bakkot_> | there's an early error for it |
| 17:29 | <bakkot_> | but it is kind of odd that there's an explicit early error rather than just using `Identifier`, not sure what's up with that |
| 17:30 | <devsnek> | from the perspective of a parser that's how you'd parse it |
| 17:30 | <devsnek> | maybe that was the thinking |
| 17:30 | <bakkot_> | is it? I feel like you'd want to parse it using `Identifier`, which is a thing you already know about |
| 17:31 | <devsnek> | oh nvm I'm thinking of import not export |
| 17:31 | <devsnek> | import was probably written first and the export mirrored it |
| 17:31 | <bradleymeck> | yea import goes down to Identifier via BindingIdentifier |
| 17:32 | <bradleymeck> | so they don't match, which is equally odd |
| 17:32 | <bakkot_> | like there's even a note about "The above rule means that each ReferencedBindings of NamedExports is treated as an IdentifierReference." |
| 17:33 | <bakkot_> | I guess IdentifierReference is different from Identifier in that it includes `yield` and `await`? but you can't have a local binding named yield or await in a module anyway |
| 17:34 | <bradleymeck> | when is safari gonna ship #! |
| 17:36 | <bakkot_> | unrelated: igalia published a post about Temporal: https://blogs.igalia.com/compilers/2020/06/23/dates-and-times-in-javascript/ |
| 17:38 | <devsnek> | I'm counting the seconds until I can use temporal |
| 17:39 | <devsnek> | but I'm not sure the seconds are correct because I don't have temporal |
| 17:39 | <bakkot_> | they won't be after temporal either :( |
| 17:39 | <devsnek> | why not |
| 17:40 | <bakkot_> | https://github.com/tc39/proposal-temporal/issues/54#issuecomment-546723710 |
| 17:40 | <devsnek> | 👀 |
| 17:53 | <leobalter> | rkirsling: I'm wondering here, that is the grammar notation for 08.1 in the specs |
| 17:56 | <leobalter> | it sounds like `08.1` is not conforming to the specs |
| 18:01 | <bradleymeck> | mathiasbynens: if you find time, can you glance to check the algo of https://bmeck.github.io/proposal-arbitrary-module-namespace-identifiers/#sec-module-semantics |
| 18:09 | <mathiasbynens> | bradleymeck: looks good |
| 18:10 | <bradleymeck> | nice |
| 18:11 | <leobalter> | it goes well with the specs, my bad. I've just found it |
| 18:31 | <leobalter> | rkirsling: https://github.com/tc39/ecma262/issues/2090 |
| 19:16 | <devsnek> | is "async" not an actual keyword? |
| 19:16 | <devsnek> | like of/as/from/etc |
| 19:17 | <bradleymeck> | devsnek: it is a "contextual keyword" |
| 19:17 | <bradleymeck> | but no not specy |
| 19:17 | <devsnek> | ecmascript has the most evil grammar |
| 19:19 | bradleymeck | stares at bash |
| 19:21 | <jmdyck> | bradleymeck: _C_ defined at step 4.b is unused |
| 19:22 | <devsnek> | ok now i just need to disambiguate `async()` and `async () =>` |
| 19:23 | <bradleymeck> | jmdyck: thanks |
| 19:24 | <rkirsling> | devsnek: I remember having to fix that one in JSC |
| 19:25 | <rkirsling> | it was painful in the sense that I addressed all of the relevant failures but IIRC it still didn't feel globally perfect |
| 19:26 | <rkirsling> | ah no I'm mistaken, it was await as a param name |
| 19:27 | <rkirsling> | https://trac.webkit.org/changeset/249925/webkit |
| 19:28 | <rkirsling> | (also I guess I'm mistaken in that it seems it wasn't so bad in the end; I think it was just difficult to pull apart the intertwining issues at first) |
| 19:38 | <rkirsling> | leobalter: thanks for officially bringing up the discussion |
| 19:38 | <rkirsling> | my feelings are sort of like the eval thing -- either option seems okay as long as we've chosen it consciously |
| 19:39 | <leobalter> | rkirsling: no problem, I believe it deserves at least that visibility, even more if I wanted this to be a follow up to the proposal |
| 19:40 | <leobalter> | I'm slightly on the same page for the eval problem, but I tend to prefer it being indirect |
| 19:40 | <leobalter> | as long TC39 makes an opinion, I'd be fine with any outcome |
| 19:40 | <leobalter> | s/opinion/decision |
| 20:00 | <rkirsling> | (in the eval case in particular, I'm strongly opposed to King Solomon-ing it into an error, but happy to have either spec or impl be made correct) |
| 21:06 | <leobalter> | likewise |
| 23:48 | <shu> | ljharb: if you have a blanket review comment like "reformat" i personally would appreciate not using GH's suggest feature |
| 23:48 | <shu> | it makes the threads extremely long and hard to scroll through |
| 23:48 | <shu> | is there a way to collapse all of them at once |
| 23:54 | <ljharb> | yeah that's fair feedback; i'll delete most of them |
| 23:55 | <devsnek> | shu: do you know how common it is for finalization groups to use unregister tokens |
| 23:55 | <ljharb> | the intention was to try to do the work myself rather than imposing a burden |
| 23:56 | <ljharb> | shu: k, i left two; one as an example and the other that also fixes a typo |
| 23:56 | <shu> | ljharb: yeah, i think suggestions is a well intentioned feature, i just find it so hard to read |
| 23:56 | <ljharb> | understandable |
| 23:56 | <shu> | especially since what people end up using them for are typos and other small fixes |
| 23:57 | <ljharb> | the ability to select multiple lines at once helps a ton |
| 23:57 | <shu> | devsnek: i don't know |
| 23:58 | <devsnek> | i found an interesting optimization for register() in v8 where it doesn't have to do a runtime call if there's no unregister token |
| 23:58 | <devsnek> | not sure how useful it will be though |
| 23:58 | <rkirsling> | is there an example of an overwhelming case? I love suggestions, I just hate the bug where you can't accept them in 262 |
| 23:58 | <rkirsling> | (I don't think I've personally had an overwhelming case though) |
| 23:59 | <shu> | devsnek: right, the runtime calls have to do with the unregister token map. to flip it around, i'd imagine it's at least also common to *not* have unregister tokens |
| 23:59 | <ljharb> | rkirsling: in the weakrefs PR, every prose paragraph was hard-wrapped, so if i'd done them all there'd have been like a hundred or more |
| 23:59 | <ljharb> | rkirsling: i stopped at like 10 |
| 23:59 | <shu> | devsnek: so in that scenario a fast path is probably worth it, but without real world use cases we're always just guessing |