2019-03-01
[15:27:58.0000] <devsnek>
was the main issue with do expressions the completion values of statements

[15:42:20.0000] <TabAtkins>
I think so, yeah.

[15:42:25.0000] <TabAtkins>
Specifically loops and similar stuff.

[15:42:44.0000] <TabAtkins>
And likely wanting to expose the same things as eval() does, which is... often not very useful.


2019-03-03
[12:31:31.0000] <devsnek>
i think there may be a bug in the spec of PropertyDefinitionEvaluation

[12:31:37.0000] <devsnek>
or ClassDefinitionEvaluation

[12:32:26.0000] <devsnek>
can anyone verify that the calls to PropertyDefinitionEvaluation in 22.a.i and 22.b.i aren't covered by any definitions of PropertyDefinitionEvaluation

[12:33:41.0000] <devsnek>
well 22.a.i may be covered but it doesn't seem that 22.b.i is

[12:37:44.0000] <devsnek>
it also seems like testing the toString of a static method isn't tested

[12:38:40.0000] <jmdyck>
You're asking whether PDE is defined for every possible ClassElement m?

[12:38:47.0000] <devsnek>
yes

[12:38:53.0000] <devsnek>
i think it's missing `static MethodDefinition`

[12:39:34.0000] <jmdyck>
that would just chain to MethodDefinition

[12:39:48.0000] <devsnek>
interesting

[12:39:58.0000] <devsnek>
ok so part 2

[12:40:08.0000] <devsnek>
my engine has been including `static` in the toString

[12:40:16.0000] <devsnek>
while also passing test262

[12:40:25.0000] <devsnek>
is this an indication that test262 is missing something

[12:41:32.0000] <jmdyck>
sounds like it, but don't know.


2019-03-06
[15:57:53.0000] <Bakkot>
Domenic / etc: if `import()` could land now by putting it Annex B for the moment, or putting a "this section is normative optional on it or something, would that be something you'd consider acceptable?

[15:58:30.0000] <Bakkot>
I agre this would be super dumb, but it seems like it is better than the current state, which is also super dumb, and erights suggested this would be acceptable to him in https://github.com/tc39/proposal-dynamic-import/issues/26#issuecomment-392280836

[15:59:48.0000] <Domenic>
I don't really care.


2019-03-07
[16:02:28.0000] <Bakkot>
cool, that's what I figured.

[04:59:47.0000] <annevk>
ljharb: https://github.com/web-platform-tests/wpt/pull/15720 might be of interest

[05:48:21.0000] <superamadeus3>
Hello all. Would this be a good place to see if there's any interest in a new language feature? I've already searched ESDiscuss and couldn't find any real discussion on it, though it was touched upon.

[06:24:17.0000] <jmdyck>
superamadeus3: It's an appropriate place. Whether it's a *good* (i.e., useful) place varies over time, I'd say.

[06:29:12.0000] <superamadeus3>
Well, I'll take my chances! The proposal is for a "try expression" which allows for imperative error handling patterns similar to how it's typically done in Go. While I came up with the semantics organically, it resembles a discussion I found on ESDiscuss from 3 years ago (specifically this post: https://esdiscuss.org/topic/just-try#content-4).

[06:30:03.0000] <superamadeus3>
Here's a github gist with my attempt at an overview of it's behavior: https://gist.github.com/superamadeus/e81c0524d6991c6977cb4ab34b82321a . I apologize ahead of time if this has been proposed before, as it seems like it shouldn't be that novel of an idea.

[09:05:41.0000] <ljharb>
annevk: thanks

[09:06:35.0000] <ljharb>
superamadeus3: can you add some examples that don’t use await?

[09:06:59.0000] <devsnek>
i don't understand this example

[09:07:07.0000] <devsnek>
or what this is doing in general

[09:07:24.0000] <devsnek>
oh wait i see now

[09:07:30.0000] <devsnek>
it's an approximation of how go returns errors

[10:19:20.0000] <superamadeus3>
Hey,

[10:19:28.0000] <superamadeus3>
I updated the gist to show examples without await.

[10:21:38.0000] <superamadeus3>
Here's the link again for convenience https://gist.github.com/superamadeus/e81c0524d6991c6977cb4ab34b82321a

[10:27:35.0000] <superamadeus3>
Yes, the goal of the proposal is to resemble this error handling pattern. It essentially wraps any expression into a result type `Result<TValue, TError> = [TValue, undefined] | [undefined, TError]`.

[10:28:19.0000] <superamadeus3>
Also, sorry if this is spammy. I'm not totally used to IRC. If there's a better place for this discussion I would be happy to move it/set it up!

[10:29:47.0000] <ljharb>
superamadeus3: i think we’d first need a Result before we’d want to add syntax to produce it

[10:34:15.0000] <devsnek>
^

[10:34:56.0000] <superamadeus3>
ljharb: For sure. Would that have to be a separate proposal, or could it be part of the same one?

[10:35:06.0000] <ljharb>
I’d think separate

[10:35:15.0000] <ljharb>
syntax is expensive, and a hard hill to walk up

[10:42:13.0000] <superamadeus3>
Cool, thanks.

[10:45:19.0000] <superamadeus3>
What might the next steps be if I want to work on this? Make a repo for the proposals and work on documentation and a spec for it and hope the community takes interest?

[10:46:41.0000] <superamadeus3>
(Not to simplify the work that must go into it)

[10:53:07.0000] <Bakkot>
you might consider checking with the Promise.allSettled champions if they'd consider using a more general result type

[10:54:01.0000] <Bakkot>
the thing they're currently returning refers to promises in particular, but if there were a pattern for Result in JS, they could use that instead.

[10:54:18.0000] <Bakkot>
("checking with" = opening an issue on https://github.com/tc39/proposal-promise-allSettled )

[10:57:55.0000] <Bakkot>
but more generally, I don't know that this would be worth it, especially if we end up with syntax for statements in expression position more generally - you could just write `let [user, err] = do { try { [foo()] } catch (e) { [void 0, e] } }` instead of `let [user, err] = try foo()`

[11:18:28.0000] <superamadeus3>
Bakkot: thanks for the lead! I'll check out that proposal. And hm, that's valid! I think it's worth exploring at least academically, or even if it just ends up being a babel plugin that I use myself :)


2019-03-08
[10:24:57.0000] <TabAtkins>
`var √ = Math.sqrt;` being a syntax error makes JS literally unusable.

[10:28:41.0000] <devsnek>
at-mathias time to extend the identifier syntax

[10:32:54.0000] <ljharb>
TabAtkins: we

[10:33:09.0000] <ljharb>
TabAtkins: we've already tried to make Math.TAU a thing too :-/

[10:34:23.0000] <devsnek>
what can i do to make Math.TAU a reality

[10:35:24.0000] <ljharb>
it seemed like some delegates were too afraid of being first-movers on "actually making math awesome"

[10:35:40.0000] <ljharb>
so getting it shipped as a constant in other languages would help :-p

[10:37:02.0000] <devsnek>
lol

[10:37:22.0000] <ljharb>
srsly tho, https://tauday.com/tau-manifesto

[10:39:16.0000] <michaelboegner>
greetings TC39 members :) I have a proposal that I am looking to get shepherded in. I am fairly new to the process but have read through the proposal documentation. You can find my suggestion here: https://www.npmjs.com/package/dry-forloop

[10:39:54.0000] <michaelboegner>
Thank you to anyone who can assist me with the process. This is super exciting!

[10:41:31.0000] <devsnek>
michaelboegner: can you provide some more information on what this is trying to solve, etc

[10:44:07.0000] <michaelboegner>
sure, so I see a couple use cases: 1. It provides a simple, easy to understand reduction of the traditional forLoop without anything other than what you would expect to find in said loop, i.e. no extra bells and whistles, it's still a forLoop, just as dry as possible

[10:44:58.0000] <devsnek>
well the existing forEach is "just a for loop"

[10:45:10.0000] <devsnek>
i'm confused about what adding all this extra stuff is doing

[10:45:28.0000] <michaelboegner>
2. You could argue at this point, hey, but I've got forEach. That basically does the same thing, right? I would say, no, in that you cannot manipulate the start, operator, length and iterator traditionally found in a forLoop using a forEach. This means that you can do things like nesting and manipulation of iteration that forEach doesn't provide, I don't believe at least.

[10:45:59.0000] <michaelboegner>
```array.forDry((e) => {     array.forDry((f) => {         solution.push(e + f)     }, 1) });  console.log(solution);  Expected return:  [ 3, 4, 5, 6, 4, 5, 6, 7, 5, 6, 7, 8, 6, 7, 8, 9, 7, 8, 9, 10 ]```

[10:46:19.0000] <devsnek>
right but what's the use case for manipulating all those things

[10:47:06.0000] <michaelboegner>
The alternative is nesting two forLoops, which means writing a much wetter code

[10:47:30.0000] <michaelboegner>
alternatively

[10:47:38.0000] <devsnek>
i'm not sure what that code does

[10:48:00.0000] <devsnek>
does it skip the first element?

[10:48:36.0000] <michaelboegner>
it's equivalent to a nested forLoop with the iterating variable starting at 1

[10:48:56.0000] <devsnek>
like `array.forEach((e) => array.slice(1).forEach((f) => { solutions.push(e + f); }))`

[10:49:05.0000] <michaelboegner>
sorry, i thought i indluced the array

[10:49:21.0000] <devsnek>
so those are equiv

[10:49:28.0000] <devsnek>
but the one i posted seems much clearer

[10:49:42.0000] <jmdyck>
michaelboegner: your proposal should maybe show a couple examples of what the equivalent code would be with current JS

[10:49:57.0000] <devsnek>
well you should write up a proposal

[10:50:10.0000] <michaelboegner>
so yeah, so the instructions just say to come here and talk to you

[10:50:16.0000] <michaelboegner>
so that's what i'm doing

[10:50:24.0000] <michaelboegner>
What should a proposal look like?

[10:51:08.0000] <michaelboegner>
nevermind, i found one in github

[10:51:10.0000] <devsnek>
at a minimum: what is the problem, why does the problem matter, some possible solutions to the problem

[10:51:19.0000] <michaelboegner>
I appreciate everyone's time

[10:51:31.0000] <devsnek>
yeah we're also working on making it easier for new people to get involved

[10:52:47.0000] <michaelboegner>
cool, thanks again for taking a second to talk it out with me

[10:53:30.0000] <ljharb>
michaelboegner: it'd help to document prior art - showing where this pattern is so common in JS or other languages that it warrants being in the language instead of in userland

[10:54:09.0000] <ljharb>
michaelboegner: also to make a case for why this is cleaner than, say, using forEach and checking the index, or using flatMap and returning `[]`

[10:54:44.0000] <michaelboegner>
awesome. Will do for sure

[10:56:30.0000] <ljharb>
(also i hope your npm package doesn’t actually modify Array.prototype; that can be very dangerous and has interfered with other proposals in the past)

[12:32:40.0000] <TabAtkins>
Personally, these modifications to start/end belong in functions that return modified arrays themselves (or rather, iterators over the array). Traditional for-loops are terrible UX-wise in the first place, but they're so ubiquitous people learn how they work anyway; scattering the same functionality over a handful of arguments makes the readability much worse.

[12:33:21.0000] <TabAtkins>
So like `array.forEach(e=>drop(1, array).forEach(f=>solution.push(e+f)))`

[13:13:10.0000] <devsnek>
TabAtkins: +1


2019-03-09
[21:32:59.0000] <rkirsling>
is the order taken as meaningful in text like this?

[21:33:00.0000] <rkirsling>
https://tc39.github.io/ecma262/#sec-primary-expression-regular-expression-literals-static-semantics-early-errors

[21:33:00.0000] <rkirsling>
(i.e. do we consider *which* early error gets prioritized in `/+/gg` to be specified?)

[21:35:47.0000] <rkirsling>
I'm assuming not, because V8 and SM both complain about the flags first, and the reason I'm even asking is because I'm playing the video game called "JSC early error whac-a-mole"

[21:36:29.0000] <rkirsling>
(it's easily as fun as a Zachtronics title 😂)

[21:59:27.0000] <Bakkot>
rkirsling, I would say no, since it does not define semantics differentiating between those two early errors

[22:00:22.0000] <rkirsling>
Bakkot: hmm. I'd ask for a counterexample but then I kind of doubt one exists?

[22:01:04.0000] <rkirsling>
since I suppose one might view it as needlessly specific

[22:01:49.0000] <Bakkot>
there is a bit of an edge case related to this:  `0++` is, for some reason, an early Reference Error rather than a Syntax Error, so I am not sure what `try { eval('0++; /r/gg;'); } catch (e) { console.log(e.name); }` should print

[22:02:26.0000] <rkirsling>
interesting

[22:02:48.0000] <rkirsling>
it's like a static race condition lol

[22:05:20.0000] <Bakkot>
in trying to determine if this is specified I have not yet been able to find an answer, but I did learn that `eval` acts as identity for anything which is not of Type string

[22:05:34.0000] <Bakkot>
i.e. `x = {}; eval(x) === x` is true

[22:07:40.0000] <rkirsling>
huh. fair enough.

[22:58:56.0000] <ljharb>
anyone have any suggestions for how to most cleanly handle this? https://github.com/tc39/ecma262/pull/702#discussion_r263966562

[04:25:49.0000] <jmdyck>
rkirsling: ParseScript() and ParseModule() both say: "If more than one parsing error or early error is present, the number and ordering of error objects in the list is implementation-dependent, but at least one must be present."

[04:31:44.0000] <jmdyck>
Which I think answers your question

[07:52:48.0000] <devsnek>
i don't think any implementations report more than one error

[07:53:55.0000] <devsnek>
this is interesting though https://gc.gy/19851876.png

[09:26:41.0000] <Bakkot>
jmdyck: I wonder if the semantics for PerformEval and/or CreateDynamicFunction should be updated with similar wording - currently they just say "if any early errors are detected, throw a SyntaxError or a ReferenceError exception, depending on the type of the exception", which is a little ambiguous because it refers to "the" exception but there can be more than one.

[10:20:02.0000] <jmdyck>
Bakkot: yup. And it might be nice to factor out the commonalities, but I think that might be tough.

[11:46:57.0000] <rkirsling>
jmdyck: cool, thanks!

[11:47:19.0000] <rkirsling>
devsnek: also note that the JSC/Ch ReferenceErrors are late ones

[12:53:03.0000] <devsnek>
rkirsling: as in they don't throw on invalid regex?

[12:54:59.0000] <rkirsling>
devsnek: the right type of error is thrown for `0++` and for `/r/gg` but they're thrown at runtime

[12:55:02.0000] <rkirsling>
I just put up a fix for early invalid flags: https://bugs.webkit.org/show_bug.cgi?id=195514

[12:55:32.0000] <rkirsling>
introducing the notion of early ReferenceError at all is still a todo item

[12:55:58.0000] <devsnek>
that's weird

[12:57:44.0000] <rkirsling>
yeah the "late SyntaxError" there is surprising

[12:58:16.0000] <rkirsling>
but my understanding is that "early ReferenceError" is a comparatively new concept

[12:58:44.0000] <rkirsling>
'twill be fun to address, I expect

[13:02:54.0000] <rkirsling>
oh whoa but SM's SyntaxError there is actually for `0++`

[13:03:14.0000] <rkirsling>
so that too is a bug

[14:45:02.0000] <devsnek>
rkirsling: looks like chakra is an early ReferenceError

[14:46:46.0000] <rkirsling>
devsnek: hmm...so it is. I thought they didn't have that notion either though 🤔 guess either I was mistaken or it changed recently

[14:47:15.0000] <devsnek>
0++ is all over the place though https://gc.gy/19876609.png

[14:47:32.0000] <devsnek>
engine262 uses acorn which considers all early errors syntax errors :(


2019-03-10
[18:05:21.0000] <rkirsling>
Bakkot: hah, I hadn't noticed that you're literally in the midst of refactoring that text (https://github.com/tc39/ecma262/pull/1464)

[19:21:51.0000] <Bakkot>
tbh I don't think "early ReferenceError" ought to be a concept in the spec

[19:22:17.0000] <Bakkot>
just throw a SyntaxError

[19:26:22.0000] <rkirsling>
interesting

[19:26:41.0000] <rkirsling>
Bakkot: is that a reversible decision?

[19:28:30.0000] <Bakkot>
rkirsling: depends on whether anyone is depending on it. But we have generally said (and found) that _removing_ an error which is only observable to correct programs via `eval` (or equivalents) is not problematic, since that happens whenever we add new syntax, so I would guess that changing the type of such an error would likewise be acceptable.

[19:30:13.0000] <rkirsling>
Bakkot: Yeah, I feel like moving from one sort of error to another would be okay, aside from any concern about popular frameworks/libraries checking which kind it is

[19:31:36.0000] <rkirsling>
I guess my immediate thought was that someone would object on account of the original reason for introducing the concept (whatever that may be), but maybe I'm wrong?

[20:05:44.0000] <jmdyck>
early Reference Error was introduced in ES6, so discussion might be findable

[20:09:28.0000] <jmdyck>
draft 10 was the first that had it, 2012-09-27.

[20:10:22.0000] <jmdyck>
release notes don't mention it.

[20:22:47.0000] <jmdyck>
There's some history in https://github.com/tc39/ecma262/issues/691

[20:57:20.0000] <rkirsling>
jmdyck: that is certainly an interesting thread

[21:06:05.0000] <rkirsling>
from the spec text perspective, they're also rarer than I was thinking

[21:11:02.0000] <rkirsling>
of the 40 `Static Semantics: Early Errors` sections, there are only four ReferenceError cases (demonstrated by `0++;`, `++0;`, `0 = 0;`, and `0 += 0;`) and they all boil down to "AssignmentTargetType is ~invalid~"

[21:11:58.0000] <rkirsling>
perhaps that does raise a question of whether it's truly worthwhile

[07:41:30.0000] <devsnek>
rkirsling: honestly I'd expect those to all be syntax errors, like on a design level

[11:42:09.0000] <rkirsling>
devsnek: yeah I added my vote for that to the thread jmdyck linked -- apparently Allen had already said the same, which I totally wasn't expecting


2019-03-13
[10:46:46.0000] <rkirsling>
aw man, V8/SM/XS have full ES2019 support now but JSC still needs to implement the F.p.toString revision

[10:47:21.0000] <rkirsling>
and by "aw man" I guess I mean "hey maybe I should do that"


2019-03-14
[10:55:55.0000] <rkirsling>
lol

[10:55:55.0000] <rkirsling>
```

[10:55:55.0000] <rkirsling>
λ eshost -sx "print(new Date('08.10.2023'))"

[10:55:55.0000] <rkirsling>
#### ch, jsc, sm, xs

[10:55:55.0000] <rkirsling>
Invalid Date

[10:55:55.0000] <rkirsling>
#### v8

[10:55:55.0000] <rkirsling>
Thu Aug 10 2023 00:00:00 GMT-0700 (Pacific Daylight Time)

[10:55:56.0000] <rkirsling>
```

[11:02:13.0000] <Domenic>
One day, someone will spec a date parser

[11:03:12.0000] <cloudshu>
is that star trek time

[11:03:39.0000] <cloudshu>
what is that called with the decimals, stardate

[11:06:30.0000] <rkirsling>
cloudshu: yeah, but it looks like it's always one decimal point: https://en.wikipedia.org/wiki/Stardate

[11:06:59.0000] <cloudshu>
ah

[11:15:40.0000] <annevk>
Someone from Mozilla was nearly there with a Date parser spec

[11:16:22.0000] <annevk>
/me remains hopeful

[11:19:44.0000] <efaust>
annevk: yeah, it's a crying shame that morgan's work was lost there. She had spent a LOT of effort outlining the intersection behavior.

[11:20:18.0000] <efaust>
frankly, that's partially my fault. By the time we went looking for it, she had left the company and it had sorta disappeared.

[11:21:05.0000] <annevk>
I did not realize we lost it, ouch

[11:25:35.0000] <efaust>
/me certainly doesn't know where it is, and I don't know if any of the SM people from then that are still around do, either

[11:44:03.0000] <rkirsling>
efaust: 😢

[12:12:17.0000] <devsnek>
`new CivilDateTime(2023, 08, 10)` :)

[12:13:11.0000] <devsnek>
hmm temporal also has fromString

[12:14:30.0000] <ljharb>
efaust: it’s not lost; i found a fork of it. It’s on the proposals repo.

[12:41:19.0000] <Domenic>
Doesn't that 08 actually mean 10

[13:05:43.0000] <efaust>
ljharb: wait, really?! \o/

[13:15:39.0000] <littledan>
I don't think that repo included most of the supporting materials

[13:17:10.0000] <ljharb>
fair, i'm not sure morgan's repo ever did tho

[13:17:23.0000] <ljharb>
like i'm not sure the supporting materials ever got posted anywhere accessible - but if they did, what was the url?

[13:24:42.0000] <annevk>
ljharb: http://mrrrgn.com/date/ per https://bugzilla.mozilla.org/show_bug.cgi?id=1274354#c1

[13:25:10.0000] <annevk>
https://github.com/tc39/proposal-date-time-string-format links that too

[13:26:45.0000] <annevk>
https://github.com/tc39/proposal-uniform-interchange-date-parsing is also interesting; why did all of these get stalled?

[13:27:38.0000] <annevk>
mathiasbynens: Date.parse > <script srcset> 😛

[13:38:05.0000] <ljharb>
annevk: aha, thanks

[13:40:37.0000] <annevk>
ljharb: efaust: there might not have been too much on that site though: https://web.archive.org/web/20161109002227/http://mrrrgn.com/date/

[14:27:13.0000] <efaust>
yeah, that was a rehost of whatever she had left laying around, IIRC

[14:27:25.0000] <efaust>
at some point, there was a beautiful chunk of markdown

[14:27:56.0000] <efaust>
much of the pain is that someone has to go back, even armed with her analysis and confirm that they're still the actual on-web semantics from various browsers

[15:44:09.0000] <littledan>
annevk: Richard Gibson is currently taking up this mantle

[15:44:33.0000] <littledan>
But he's starting with a less ambitious approach than what Morgan was doing

[15:59:01.0000] <littledan>
hey, I know some people here had concerns with top-level await. I'm wondering, what if you had to use an `import await` statement when importing a module that contained a top-level `await`? I'm thinking, this might add a little more explicit-ness and make it clear that asynchronous stuff is going on. So the whole feature becomes an opt-in--no change in the semantics or synchronous-ness of your module unless you use `await` or

[15:59:01.0000] <littledan>
`import await`.

[15:59:16.0000] <littledan>
(this idea came from Tobias Koppers)

[15:59:57.0000] <ljharb>
i like the idea, but since using `import await` still makes that module async, it's still got the same virality issues as TLA


2019-03-15
[18:39:35.0000] <Domenic>
littledan: I would be against that; it ruins the ability to transparently refactor your work to take on async startup costs

[18:40:00.0000] <Domenic>
If you're willing to rewrite the calling module graph anyway then you can just refactor to put everything inside dynamic imports

[18:44:17.0000] <gibson042>
annevk: https://github.com/tc39/proposal-uniform-interchange-date-parsing is still active, I've just been short on time lately

[19:58:38.0000] <ljharb>
that transparent ability is the

[19:58:50.0000] <ljharb>
“Spooky action at a distance” that i have major concerns with :-/

[20:01:53.0000] <devsnek>
littledan: along the same vein as domenic, you'd have to know if what you're importing is async or not, which is an annoying experience

[20:44:27.0000] <ljharb>
devsnek: you’d get an early error about that tho

[20:44:38.0000] <ljharb>
it’d even be an autofixable lint rule

[20:45:28.0000] <devsnek>
🤷

[02:29:21.0000] <littledan>
ljharb: I thought `import await` would fix those exact spooky action a distance issues. Ultimately, the vitality is analogous to the virality of async/await itself

[02:31:53.0000] <littledan>
Domenic, devsnek: I can see this point abstractly, but isn't this just like async functions, which also require the caller to be adjusted to use a Promise rather than another value? We found it worth it to add async functions even though you could just use generators and Promises.

[02:32:41.0000] <littledan>
What I am missing is usage scenarios where you want to change a deep dependency like that. The current TLA explainer doesn't really have one concretely, making it hard to think about

[02:33:43.0000] <littledan>
I don't see what dynamic imports have to do with any of this, though; why would refactoring to those solve this problem?

[04:31:02.0000] <littledan>
s/vitality/virality/

[05:01:14.0000] <Domenic>
littledan: consider a web component whose template you want to move to another file

[05:01:43.0000] <Domenic>
If you are going to change all call sites anyway you can use the import() + export default async antipattern the readme calls out.

[05:03:57.0000] <Domenic>
The whole point of top-level await is to avoid making changes to the caller. I would be opposed to the proposal if it required caller changes.

[09:33:23.0000] <littledan>
Domenic, I think it's still more ergonomic than nothing. I don't quite understand that other case--why would you export the element rather than defining it (in the background than blocking module loading)?

[09:33:47.0000] <Domenic>
littledan: consider the example at https://github.com/tc39/proposal-top-level-await/issues/58#issuecomment-468749512

[09:34:03.0000] <Domenic>
Consider a "before" version which had `const template = .... long string here ...`

[09:34:22.0000] <Domenic>
You're saying I cannot switch to the version in the comment which loads the template from ./template-1.html without changing all my callers

[09:34:32.0000] <Domenic>
I don't think top-level await is worth moving forward as an ergonomics feature

[09:34:38.0000] <Domenic>
It is fundamentally an abstraction boundary feature

[09:34:43.0000] <Domenic>
wycats made this point in previous meetings

[09:39:53.0000] <littledan>
To be clear, I still think it makes sense to have both imports run in parallel

[09:41:36.0000] <devsnek>
`await import` does also imply some ordering

[09:41:59.0000] <Domenic>
+1 devsnek

[09:42:03.0000] <Domenic>
littledan: I was just using that code sample

[09:42:07.0000] <Domenic>
Let me create a separate one to be clearer

[09:46:36.0000] <devsnek>
heh the current proposal looks a lot like my implementation of top level await in engine262

[09:52:18.0000] <Domenic>
https://github.com/tc39/proposal-top-level-await/pull/60#issuecomment-473362344

[09:55:19.0000] <littledan>
devsnek: Maybe, but I don't think anyone is proposing that

[09:55:32.0000] <devsnek>
i just mean from a design standpoint

[09:55:42.0000] <devsnek>
i didn't assume you were proposing such a thing

[09:57:33.0000] <littledan>
Right, well, I was hoping that `import await` would make it feel like the whole awaiting action is hoisted to the top and done in parallel, just like the fetch for the `import`.

[09:57:47.0000] <littledan>
devsnek: Do you think it achieves that?

[09:58:10.0000] <devsnek>
i am unsure

[09:58:54.0000] <devsnek>
domenic gave me an idea though

[09:59:09.0000] <devsnek>
if all import statements are import await statements

[10:00:46.0000] <littledan>
well, that's basically what you get from #49 or E57

[10:00:51.0000] <littledan>
#57

[10:01:04.0000] <littledan>
the idea of this PR is that import statements stay import statements

[10:16:14.0000] <ljharb>
littledan: `import await` fixes it for the modules that add TLA; but it just moves it to the one that adds `import await`

[10:19:10.0000] <ljharb>
to be specific, i don’t think adding TLA *should* be transparent. Maybe it should be viral, maybe not, but making a sync thing async is always a breaking change so far.

[10:43:30.0000] <littledan>
ljharb: I don't understand what you mean by moving it. In particular, if you import a module that contains an import await, it's an error (at linking time)

[10:43:42.0000] <littledan>
so, it remains a breaking change

[10:44:05.0000] <littledan>
it's just like async functions: you need an await all the way up the callstack, if you want to get the value

[10:44:15.0000] <ljharb>
right. But if i import a module that suddenly adds import await, that’s a breaking change too

[10:44:33.0000] <ljharb>
and in the case of promises, you don’t - you could mutate a binding when the promise resolves without having to export a promise

[10:44:40.0000] <ljharb>
or you could dispatch to different behavior, etc

[10:44:47.0000] <ljharb>
the actual interface doesn’t have to change

[10:45:11.0000] <ljharb>
atm there’s no way to consume a module using TLA that encapsulates that decision from *your* users.

[10:45:22.0000] <devsnek>
i've kinda imagined that TLA is more useful at the entry rather than dependencies

[10:45:23.0000] <ljharb>
hm, i guess dynamic import

[10:45:33.0000] <Domenic>
At the moment consuming a module that uses TLA is ENTIRELY encapsulated from your users

[10:45:42.0000] <Domenic>
The change to use `await import` would break that, which is why I'm objecting ot it

[10:45:42.0000] <ljharb>
yes, my preference would be to only ever allow it in entry points, but there’s no way to spec that

[10:45:55.0000] <ljharb>
Domenic: using TLA changes ordering and timing semantics tho

[10:45:58.0000] <ljharb>
doesn’t it?

[10:46:03.0000] <Domenic>
Yes, OK, "ENTIRELY" was over-strong

[10:46:04.0000] <devsnek>
"it is an early error if module includes top level await and export"

[10:46:12.0000] <Domenic>
If you don't use tick-counting trickery then it's unobservable

[10:46:14.0000] <ljharb>
thus it’s still a breaking change, just a silent one

[10:46:20.0000] <ljharb>
if it is ever observable then it’s observable imo

[10:46:28.0000] <Domenic>
Sure. It's an observable change

[10:46:31.0000] <Domenic>
Just one that's highly encapsulated

[10:46:45.0000] <ljharb>
so i either want it to be entirely unobservable, trickery or not, or, i want it to be explicitly and loudly a breaking change

[10:46:53.0000] <ljharb>
the middle is where confusion happens

[10:46:53.0000] <Domenic>
OK. Then I don't think this feature will move forward.

[10:47:15.0000] <ljharb>
what would the downstream consequences of that be?

[10:47:32.0000] <ljharb>
in html, node, wasm, etc

[10:47:36.0000] <devsnek>
i wouldn't agree that the number of ticks something takes is grounds to call it breaking

[10:48:03.0000] <ljharb>
devsnek: when it goes from 1 to > 1, no, but when it goes from effectively 0 to > 0, yes

[10:48:16.0000] <devsnek>
and i don't think anything except js itself wants async during evaluation phase

[10:48:32.0000] <devsnek>
actually scratch that i know nothing about html imports

[10:48:59.0000] <ljharb>
so that’s my question. Before declaring a feature deadlocked, I’d like to understand what bad things could happen without it

[10:49:26.0000] <ljharb>
like E.g. if weakrefs died, wasm would ship them anyways, and then js would be forced to use wasm’s version

[10:49:40.0000] <ljharb>
what happens downstream without TLA, looking far forward?

[10:49:50.0000] <devsnek>
IIFEs continue to exist

[10:51:27.0000] <devsnek>
it looks like importing an html returns that html as an element

[10:53:18.0000] <Domenic>
We're still working moving the web from 0 ticks to >0 ticks

[10:54:19.0000] <devsnek>
looks like importing html isn't hurt by the lack of async either

[10:55:18.0000] <Domenic>
I mean, importing HTML will definitely be async

[10:55:34.0000] <Domenic>
So I guess people could get around lack of top-level await by wrapping their .mjs files in .html files

[10:57:04.0000] <devsnek>
i mean there's nothing imperative about html modules that require fancy async during the evaluation phase

[10:57:17.0000] <devsnek>
not that they should be loaded synchronously :P

[10:58:08.0000] <annevk>
/me whispers .mhtml*

[10:58:12.0000] <Domenic>
Well they can include <script type="module">

[10:58:16.0000] <Domenic>
Which is loaded async

[10:58:32.0000] <devsnek>
i'd assume that's like having an import()

[10:58:34.0000] <devsnek>
new entry point

[10:58:44.0000] <Domenic>
Nah that's not the current proposal

[10:58:48.0000] <Domenic>
They re-export any <script>s

[10:58:59.0000] <Domenic>
Or maybe just the first one

[10:59:11.0000] <devsnek>
interesting

[10:59:30.0000] <devsnek>
that still fits within the current evaluation rules though right?

[10:59:32.0000] <Domenic>
All of them, it looks like

[10:59:33.0000] <Domenic>
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/html-module-spec-changes.md

[11:00:14.0000] <Domenic>
I mean HTML just evaluates modules on its own

[11:00:20.0000] <devsnek>
yeah

[11:00:30.0000] <Domenic>
It currently follows ES's everything-is-sync all-one-graph evaluation but that's changing

[15:07:09.0000] <littledan>
ljharb, WebAssembly modules also need to be async, as mentioned in the TLA explainer

[15:07:22.0000] <littledan>
Domenic: Where can I find discussion about why HTML modules are async? I missed that.

[15:08:34.0000] <littledan>
ljharb: I still don't understand why `import await` wouldn't meet your goals. I think it's "explicitly and loudly a breaking change", as you put it.

[15:08:34.0000] <devsnek>
littledan: why does wasm need async?

[15:08:56.0000] <devsnek>
it doesn't even *do* anything unless you have a start point

[15:08:56.0000] <littledan>
https://github.com/tc39/proposal-top-level-await#webassembly-modules

[15:09:15.0000] <devsnek>
and if you have a start point

[15:09:17.0000] <littledan>
it might have to do compilation during the Evaluate phase, due to what the imports are

[15:09:26.0000] <devsnek>
its not like you can await inside wasm

[15:09:32.0000] <littledan>
these things are hard to reason about from first principles but come from real implementations

[15:10:32.0000] <devsnek>
how is instantiation not part of the linking phase

[15:11:32.0000] <littledan>
See a detailed explanation in https://github.com/WebAssembly/esm-integration/tree/master/proposals/esm-integration

[15:11:32.0000] <devsnek>
is this because of "From HTML, it’s not observable when parse a WebAssembly module begins, so any work perfomed in compilation may be performed off-thread."?

[15:12:11.0000] <devsnek>
reading a file is async too, but we can still export things from source text

[15:12:15.0000] <littledan>
Some compilation work might happen when parsing a WebAssembly module (nothing happens in the linking phase), but some other work might be needed once the imports are known

[15:12:32.0000] <devsnek>
this causes me immense confusion

[15:12:34.0000] <littledan>
in particular, some implementations have multiple types of underlying memory, and need to recompile due to that

[15:12:44.0000] <littledan>
if you import a memory

[15:13:07.0000] <devsnek>
that sounds like it would break the js api

[15:13:19.0000] <littledan>
well, it doesn't, it's just that the JS API isn't very useful...

[15:13:25.0000] <littledan>
you should only use instantiateStreaming for this reason

[15:13:40.0000] <littledan>
probably the Wasm JS API should've been designed very differently, but it's a little too late

[15:14:15.0000] <littledan>
the API just forces compilation work to happen on the main thread when you hold it wrong. Wasm modules will not compile on the main thread.

[15:14:34.0000] <littledan>
the whole point of Wasm/ESM integration is to make the right way easy

[15:14:36.0000] <devsnek>
you can use instantiateStreaming in a module loader today right now

[15:14:41.0000] <littledan>
ype

[15:14:43.0000] <littledan>
yep

[15:15:23.0000] <devsnek>
not that its possible to easily test with cuz node refuses to merge any instantiateStreaming apis

[15:15:35.0000] <devsnek>
but locally i've built all this already which is why i'm confused

[15:16:27.0000] <littledan>
I mean, if you're testing it, the JS API "just works". It just might do compilation on the main thread. And these effects are engine-specific--JSC is the one which motivated this current issue.

[15:17:11.0000] <devsnek>
are you saying that instantiation shouldn't happen during linking?

[15:18:19.0000] <littledan>
Anyway, between HTML and WebAssembly, I think we really need modules to be able to be asynchronous. I wouldn't like to see more HTML willful violations governing things here, the way they do with the job/microtask queue; I'd like to find some sort of clean layering. But if the WebAssembly "do it anyway" case is motivating for you, that's sort of the risk here.

[15:20:04.0000] <devsnek>
can you give me an example of a wasm module that demonstrates the need for async

[15:33:47.0000] <littledan>
devsnek: No, because any of them may need to do compilation during instantiation. Please read the documents I linked which explain this in detail

[15:35:56.0000] <devsnek>
i am seemingly missing the why from these documents

[15:41:23.0000] <devsnek>
littledan: is this just that you want to allow recompilation to happen off thread?

[15:41:32.0000] <littledan>
yes

[15:41:53.0000] <littledan>
Seems like you understand; I'm wondering if you have ideas for how the documents could be more clear

[15:43:19.0000] <devsnek>
what's the difference between my code needing to wait for something because it blocks vs needing to wait for something because its async

[15:44:37.0000] <devsnek>
like within js code it makes sense to move things to the loop so you can keep going with other things, but your module graph has to wait either way

[16:01:12.0000] <devsnek>
littledan: sorry to answer your question, i'd say the word "depend" is the wrong word, i was trying to figure out why it wouldn't be possible to add wasm modules without async when the actual situation was that it was just a bonus for performance

[16:01:48.0000] <littledan>
exactly, but this performance bonus is an architectural thing. If we make them sync now, it will be hard to move compilation into the background in the future.

[16:04:17.0000] <devsnek>
littledan: is the overhead of wasm optimization greater than the overhead of js optimization

[16:04:25.0000] <devsnek>
just as a curiosity

[16:05:56.0000] <littledan>
devsnek: Well, JS parsing and bytecode generation can be done during ParseModule, which can be done in the background, since modules are defer or async

[16:06:31.0000] <devsnek>
an engine may need to readjust the bytecode depending on the values of imports

[16:06:42.0000] <littledan>
Often, Wasm modules are extremely large, making them take a while to load up. That's why engines have been investing in baseline compilers.

[16:06:55.0000] <littledan>
I don't think this comes up in JS the same as it does in Wasm

[16:07:18.0000] <devsnek>
alright


2019-03-16
[17:37:22.0000] <ljharb>
littledan: import await addresses one of my big concerns; but it’s vitality is one that remains.

[17:47:14.0000] <littledan>
ljharb: Is there any version of top-level await you could imagine that would address the virality concern (regardless of other issues people have raised)?

[17:50:23.0000] <ljharb>
yep! Maybe sugar for an AAIFE with import or import await? That makes adding TLA or import await not a breaking change (transparent) but using import await ensures all the bindings are available (desired behavior). Both sync and async static import would work with any module. (just came up with this now so i haven’t thought it through more than this comment)

[00:46:47.0000] <littledan>
ljharb: Do you mean, dependent modules would not be blocked?

[00:53:05.0000] <littledan>
If so, I don't think this would meet the WebAssembly goals well, as those should wait for the module to be ready before exposing the exports

[00:53:29.0000] <littledan>
it seems like a weird hazard that, if you leave off the `await`, you expose yourself to the race condition that the explainer walks through the techniques for avoiding.

[00:53:45.0000] <littledan>
this really would be a problem when refactoring!

[09:05:01.0000] <ljharb>
littledan: yes, i dislike that dependent modules are blocked without them opting into it

[09:05:21.0000] <littledan>
ljharb: They are opting into it by doing `import await`, right?

[09:05:36.0000] <littledan>
I mean, they have the choice of not using the module at all, but it's not silently foisted on them

[09:05:41.0000] <ljharb>
yes, but modules importing *them* are not

[09:05:59.0000] <littledan>
OK, I think that's where we have some confusion. I'd say, if you import a module using import await, you also have to use import await

[09:06:05.0000] <littledan>
(otherwise there's no point to any of it)

[09:06:16.0000] <ljharb>
right, that’s the current proposal for import await iirc

[09:06:31.0000] <littledan>
right, so what is it that you're against with that?

[09:06:36.0000] <littledan>
or, what are you in favor of?

[09:06:42.0000] <ljharb>
so that addresses my concern of silent optin - but it preserves the concern about vitality

[09:06:45.0000] <ljharb>
*virality

[09:06:54.0000] <littledan>
heh I keep making the same mistake

[09:07:00.0000] <ljharb>
DYAC :-p

[09:07:39.0000] <littledan>
so, do you have any ideas of what would meet your requirements, while also not encouraging races?

[09:21:05.0000] <ljharb>
perhaps the same idea i said earlier, but the bindings start out as promises instead of undefined or in tdz?

[09:22:21.0000] <ljharb>
it seems important that i can import a module that’s not using TLA, but that starts using import await, and that it doesn’t necessarily impact me

[12:19:58.0000] <MylesBorins>
ljharb littledan it seems to me that if the "import await" is not viral there isn't much point to it. if just the consumer needs to know if would be dead simple for package authors to introduce a single level of indirection and never have to let consumers worry about it... in which case there really isn't any value in it

[12:25:48.0000] <littledan>
Yeah, I am similarly confused. Also, it's really hard for me to imagine how you'd use a module  when you don't know whether its bindings are Promises or not. Is everyone supposed to defensively await everything?

[12:26:41.0000] <littledan>
ljharb: Happy to keep bouncing ideas back and forth, but I think making all the exports into Promises wouldn't really work out

[13:15:27.0000] <ljharb>
MylesBorins: if it is viral, then everyone will have to use it basically everywhere (unless, i suppose, if it errored on a sync module) but at that point either a graph leaf will never use TLA, limiting its usefulness, or it will, forcing the entire chain above it to use import await as well.

[13:16:07.0000] <ljharb>
i suppose another alternative is that TLA modules can only be dynamically imported

[13:16:48.0000] <ljharb>
and then `await import()` at the top level is how you’d consume that in a blocking fashion, and that would be your own TLA


2019-03-17
[15:29:20.0000] <devsnek>
mfw seeing the new decorators proposal 😥


2019-03-18
[08:46:50.0000] <mathiasbynens>
devsnek: what, you like slow startup times?

[09:21:53.0000] <devsnek>
mathiasbynens: no... just from a design standpoint, it's not the simplest or prettiest api

[09:22:47.0000] <ljharb>
mathiasbynens: come on tho, how "slow" are we talking here, for an arbitrary module with an arbitrary decorated class


2019-03-19
[08:49:33.0000] <mathiasbynens>
ljharb: https://docs.google.com/document/d/101VnCaQaheEwSXQ_-eSAKpkutnAbDjS9T5TS2gF5zLQ/edit

[08:52:10.0000] <annevk>
mathiasbynens: guess you shared that with wycats already?

[08:53:12.0000] <mathiasbynens>
annevk: i believe gsathya did, yeah

[08:57:55.0000] <ljharb>
mathiasbynens: that just talks about conceptually; is it quantified anywhere?

[08:58:59.0000] <ljharb>
like let’s say my many-10Ks class-based react component codebase has a decorator on every one. How much startup cost increase are we talking? 1ms, 1s, 1m?

[09:00:16.0000] <devsnek>
mathiasbynens: my question is, at the cost of adding all that weird syntax/behaviour in the new proposal, is the entire feature worth it

[09:00:31.0000] <devsnek>
its basically adding a new DSL to the language

[09:43:03.0000] <mathiasbynens>
ljharb: the whole point of the doc is that you can't answer this question, even when given code which you can statically analyze

[09:43:46.0000] <mathiasbynens>
devsnek: that's a good question, and one we should be asking ourselves more often

[09:44:20.0000] <devsnek>
any solution that has to work with function hoisting is probably going to be meh

[09:44:33.0000] <devsnek>
i'd assume "make decorated functions unhoisted" has been proposed at some point

[09:48:17.0000] <ljharb>
mathiasbynens: ok so it could be negligible and this could all be fud?

[09:48:50.0000] <ljharb>
while it could also be the worst case, but nobody knows how bad that might be

[09:50:13.0000] <ljharb>
if the only way to answer it is an implementation, isn't that the purpose of stage 3?

[09:52:01.0000] <mathiasbynens>
ljharb: i'm saying it depends on what the decorator does exactly, which you cannot statically figure oout

[09:53:58.0000] <mathiasbynens>
imho it's not our job as implementers to do busywork for TC39. multiple implementers voiced concerns re: start-up performance AND implementation complexity, so the suggestion to "try and implement it to see how bad it really is" feels a little detached from reality

[09:55:34.0000] <ljharb>
that's fair.

[09:56:02.0000] <ljharb>
altho the complexity grows directly out of all the use cases, so i'm not sure that's avoidable, altho the performance part may be.

[10:00:01.0000] <mathiasbynens>
yep, it's a trade-off for sure

[10:21:44.0000] <Bakkot>
we are not required to support all use cases; as such it's totally avoidable by saying "that use case requires too much implementation complexity and we aren't going to support it"

[10:23:47.0000] <devsnek>
+1 Bakkot

[10:38:08.0000] <ljharb>
Bakkot: that is true; i should have said, not sure that's avoidable without cutting off a bunch of use cases

[10:38:27.0000] <ljharb>
but also, many of the use cases not being met may cause objections to advancement.

[11:29:25.0000] <littledan>
What if top-level await were synchronous if an entire module subgraph is deterministically synchronous (does not contain any syntactic top-level await)? https://github.com/tc39/proposal-top-level-await/pull/61

[11:30:04.0000] <littledan>
so it's not "Zalgo" (like #49) but it's also not creating lots of trivial Promises and depending on queue flushes to work through them in time (like #51)

[11:32:30.0000] <Domenic>
littledan: as you know I think we'll want to do queue flushes on the web anyway, so as long as that's preserved I guess whatever is fine for the top-level await spec.

[12:05:33.0000] <annevk>
Domenic: is that a cross-browser pos? It makes sense to me btw, but wonder how many folks considered the tradeoffs

[12:30:48.0000] <littledan>
Domenic: Yeah, this would be fine in conjunction with that

[12:31:17.0000] <littledan>
Domenic: I don't think the difference between #61 and #51 would be observable in this case

[12:41:48.0000] <littledan>
I think it'd be pretty weird to have the Promises set up in one layer (JS), and synchronization guarantees made in another layer (HTML for its microtask checkpoint), unless we have a very explicit contract that it's going to do exactly that. In this case, such a construction feels like overkill. What we want is for synchronous subgraphs to run in order--microtask checkpoints are one way of doing that, and just not adding in all

[12:41:49.0000] <littledan>
these promises on synchronous subgraphs is another way (and perfectly compatible with adding other, independently motivated microtask checkpoints)

[12:42:17.0000] <littledan>
anyway, you could think of it as an editorial change, if the web will end up doing these microtask checkpoints.

[12:48:00.0000] <annevk>
littledan: so an argument for interleaving tasks as well is that module loading should still give opportunities for hitting 60fps

[12:48:38.0000] <littledan>
annevk: Unfortunately, we heard from nyaxt on html#4400 that it'd be hard to yield to the event loop after each module load

[12:48:54.0000] <annevk>
This does seem like it’d benefit from involving more people

[12:49:42.0000] <littledan>
I think yielding optionally, driven by the UA, seems like a good proposal. However, it wouldn't address the specific synchronization need we have here. I think it'd be best to decouple these

[12:50:06.0000] <littledan>
annevk: Is there someone from Mozilla who works on event loop kind of things who we could bring in?

[12:51:13.0000] <annevk>
littledan: smaug and dbaron I suppose

[12:51:46.0000] <annevk>
littledan: rniwa from Apple too?

[12:54:52.0000] <littledan>
cc'd on html#4400

[12:55:26.0000] <littledan>
I've been wondering about something crazier as far as being incremental: Should we let code start executing when the module graph is not all fetched and parsed?

[12:56:45.0000] <littledan>
It would complicate things, but it could improve parallelism. On the other hand, you could accomplish the same though manual code splitting instead and give stronger priority hints to the browser that way

[13:06:10.0000] <Bakkot>
grammar question: is `({ ...{a} } = {})` legal?

[13:06:17.0000] <Bakkot>
note that this is assignment, not declaration

[13:06:36.0000] <Bakkot>
oh wait no

[13:06:47.0000] <Bakkot>
there's an early error for it, ok

[13:06:51.0000] <ljharb>
Bakkot: i wouldn't expect spread without an identifier to be legal there

[13:06:58.0000] <ljharb>
or rest, rather

[13:07:35.0000] <Bakkot>
Yeah, it has to be an identifier, not an object or array. Did not know that.

[13:09:22.0000] <Bakkot>
lol, but `({ ...(a) } = {})` is legal; that's fun

[13:09:56.0000] <ljharb>
that must bind to `a`?

[13:10:12.0000] <ljharb>
interesting, seems like a weird omission to allow parens there

[13:10:20.0000] <ljharb>
since `var (a) = 3` doesn't work

[13:10:34.0000] <Bakkot>
`(a) = 3` does

[13:10:39.0000] <ljharb>
oh right

[13:10:46.0000] <ljharb>
ok well then it's horrifically consistent

[13:10:51.0000] <ljharb>
yay

[13:13:34.0000] <annevk>
littledan: that sounds like defer or async

[13:15:03.0000] <littledan>
annevk: Modules are always defer or async, but as a group. All of them are fetched and parsed before any of them run, and that fetching and parsing happens as defer or async

[13:15:34.0000] <littledan>
As we think about HTML or CSS modules, I guess these problems become more acute. Suddenly more and more stuff is all at once

[13:15:58.0000] <littledan>
Or, maybe it's not. Maybe those do their loading in the Evaluate phase, unlike JS. I'm not sure

[13:46:55.0000] <annevk>
littledan: you mean that they would export a promise? I don’t think that’s how folks are thinking about them

[14:16:37.0000] <littledan>
No, I mean they might run via top-level await basically

[14:17:13.0000] <littledan>
But if they pull in their dependencies this way, it would differ from JS. So I am wondering if JS should actually do this too

[14:48:51.0000] <littledan>
annevk: What I'd heard is that HTML modules might be asynchronous (as if they used top-level await), which could make sense as the HTML processing module is async. So would it make sense to extend that further, if JavaScript is what's making startup slow on lots of pages?

[14:52:46.0000] <ljharb>
JS often needs to block startup tho, to set up the environment or the DOM or whatnot


2019-03-20
[21:20:26.0000] <annevk>
littledan: interesting, I’m not so sure that makes sense as a default, guess I need to investigate

[22:11:52.0000] <littledan>
Ljharb, In HTML, modules don't have the power to do this, so that sounds like another, separate feature request

[22:13:46.0000] <ljharb>
in JS modules they do, tho, absent TLA, no?

[15:21:59.0000] <Bakkot>
@mathiasbynens: do your various "unicode-match-property-value-ecmascript" etc packages distinguish between those properties which are legal in `\P` and those which are not?

[15:24:49.0000] <Bakkot>
(i.e. binary vs non-binary properties, I guess)


2019-03-21
[00:37:59.0000] <mathiasbynens>
Bakkot: currently all of them are legal in both `\p` and `\P`, so we don't have that problem

[01:11:10.0000] <mathiasbynens>
Bakkot: aah, I see the PR now for context. here's how regexpu-core does it: https://github.com/mathiasbynens/regexpu-core/blob/a20f9142d87013822441f417bd8c5b14999f2353/rewrite-pattern.js#L50-L62

[01:12:16.0000] <mathiasbynens>
(https://github.com/shapesecurity/shift-regexp-acceptor-js/pull/17/files)

[09:14:13.0000] <Bakkot>
mathiasbynens: thanks! I think try-catching a dynamic `require` is a little too ugly for me; we'll go with the hardcoded list I guess.

[09:58:35.0000] <mathiasbynens>
Bakkot: oh yeah, I agree. I wouldn't have gone with that approach for a validator either

[09:59:00.0000] <mathiasbynens>
for regexpu-core it's nice as it means we can just update a dependency to make new properties/values magically work

[10:15:54.0000] <Bakkot>
mathiasbynens: also, unrelated: it'd be good to get https://github.com/tc39/proposal-promise-any/pull/15 merged before the meeting I think

[10:16:07.0000] <Bakkot>
doesn't much matter since it's only going for stage 1


2019-03-26
[07:06:37.0000] <cmorningstar>
msg chanserv invite #tc39-delegates

[07:06:55.0000] <ljharb>
cmorningstar: /

[07:07:07.0000] <bterlson>
loool

[07:51:50.0000] <bnb>
Can the new website be shared publicly?

[07:52:09.0000] <bterlson>
tc39.github.io? definitely! I think there was a Moz blog you could retweet

[07:52:13.0000] <bnb>
\o/

[07:53:15.0000] <cloudshu>
https://twitter.com/mozhacks/status/1107660133281206272

[07:58:08.0000] <bnb>
Thank you cloudshu!

[13:22:27.0000] <TabAtkins>
Yo, I'm adding some trig/pow functions to CSS, and intend to match JS semantics exactly wrt pos/neg zero, infinities, etc. Does test262 have some decent suites that I can adapt into CSS tests?

[13:42:09.0000] <michaelficarra>
TabAtkins: 546 tests: https://test262.report/browse/built-ins/Math

[13:58:25.0000] <TabAtkins>
nice

[13:59:52.0000] <TabAtkins>
Also: has JS gotten any significant requests for a root function, beyond the built-in sqrt() and cbrt()?  You can't take higher roots of negative numbers with pow().

[14:00:34.0000] <michaelficarra>
I'm not aware of any such request

[14:00:48.0000] <michaelficarra>
but I also don't follow es-discuss the last 4 or so eyars

[14:00:53.0000] <michaelficarra>
*years


2019-03-27
[10:32:02.0000] <ljharb>
`document.createElement('applet')` triggers a java update popup in IE 11 (and presumably other browsers). anyone know if there's a way to prevent that?

[10:33:28.0000] <ljharb>
michaelficarra: you know about weird browser stuff, any idea? ^

[10:42:03.0000] <Domenic>
that's amazing

[10:42:25.0000] <ljharb>
lol, it's something

[10:49:37.0000] <devsnek>
lmao

[10:50:27.0000] <annevk>
ljharb: applet got removed from most if not all new browsers

[10:50:53.0000] <annevk>
ljharb: also somewhat doubt that particular behavior was cross-browser

[10:52:11.0000] <ljharb>
annevk: yeah i'm just hoping there's a way to bypass the dialog :-)

[10:56:50.0000] <michaelficarra>
haha I'm not sure about that one ljharb


2019-03-28
[07:44:29.0000] <keith_miller>
littledan: Nvm, we still differentiate between memories in the baseline compiler for wasm.

[07:53:20.0000] <littledan>
keith_miller: So, you think you really want it to be async long-term?

[07:53:38.0000] <littledan>
and it makes sense to queue a task?

[07:53:53.0000] <keith_miller>
I wasn't saying long term just that it would be a non-trivial amount of work

[07:54:21.0000] <littledan>
oh, yeah, I get that, but I guess we were talking about other things like ES Modules being a bunch of work anyway

[07:54:35.0000] <littledan>
Has rniwa been included in this discussion, about whether we want an event loop turn?

[07:54:40.0000] <littledan>
for each Wasm module

[07:54:49.0000] <littledan>
which is the implication if this is async

[07:54:50.0000] <keith_miller>
No

[09:00:52.0000] <TabAtkins>
Re: my earlier root request, it was pointed out that you can take higher roots of negative numbers via `Math.pow(Math.abs(x), 1/5)*Math.sign(x)`, so I don't care about the issue any longer. ^_^

[09:01:33.0000] <TabAtkins>
(If your root isn't an odd integer you'll get nonsense results, but caveat emptor, it'd just return NaN if there was a dedicated function.)


2019-03-29
[07:43:45.0000] <annevk>
littledan: so overloading of Number and BigInt is gonna be a thing after all?

[07:44:11.0000] <littledan>
annevk: That was the conclusion for Intl.NumberFormat.prototype.format, yes

[07:44:26.0000] <annevk>
littledan: was there a more general conclusion too?

[07:44:27.0000] <littledan>
annevk: The committee declined to recommend anything for WebIDL, but I'd like us to eventually be able to migrate Intl to WebIDL

[07:44:40.0000] <littledan>
however, I am also fine with prohibiting the overloading in WebIDL for now

[07:44:56.0000] <littledan>
I explained to the committee that I'd like to bring alignment on these decisions

[07:44:57.0000] <annevk>
littledan: if we're going to allow it folks are gonna overload

[07:45:04.0000] <littledan>
:(

[07:45:06.0000] <annevk>
littledan: e.g., in that Wasm decision

[07:45:13.0000] <annevk>
s/decision/issue/

[07:45:13.0000] <littledan>
wait that one is different

[07:45:25.0000] <annevk>
Is it?

[07:45:45.0000] <annevk>
https://github.com/WebAssembly/JS-BigInt-integration/issues/12

[07:46:18.0000] <littledan>
that one clearly should not allow an overload; this is just like writing into a Uint64Array, which the committee decided should not be permitted. It's about Number values "being in range" so it's OK

[07:46:41.0000] <littledan>
the distinction is a little subtle, I understand

[07:46:52.0000] <annevk>
littledan: once it's in IDL that distinction will be lost

[07:46:56.0000] <littledan>
but, that proposal is purely about "eh, both should work here" whereas the NumberFormat issue is a genuine overload

[07:47:18.0000] <littledan>
well, how about we think about the NumberFormat.format thing as using an "any"-based overload, and don't let people do it in WebIDL?

[07:47:26.0000] <annevk>
littledan: unless browsers have linting on it and informed reviewers

[07:47:42.0000] <annevk>
littledan: I guess

[07:47:53.0000] <littledan>
well, I can write more about this in the W3C TAG spec guidelines

[07:47:59.0000] <littledan>
I'm not sure if people read that...

[07:48:09.0000] <annevk>
Might still get copy-and-paste, but maybe

[07:48:16.0000] <littledan>
it seems like it's typically down to you, Domenic , bz and a couple others to actually enforce conventions

[07:48:20.0000] <annevk>
They should, but I also haven't read it recently to be fair

[07:48:26.0000] <annevk>
uhuh

[07:48:36.0000] <annevk>
That's why I'm skeptical 😃

[07:48:42.0000] <littledan>
:(

[07:48:45.0000] <littledan>
OK, I'll think about this more

[07:49:22.0000] <littledan>
I don't think overloading Intl methods will keep working in the future. Domenic pointed out that, if Temporal is in a module, then it couldn't be purely lazy-loaded if we let it overload Intl.DateTimeFormat methods

[07:49:47.0000] <littledan>
also, overloading on different platform objects gets kinda wonky if we move to same-realm brand checking

[07:50:14.0000] <littledan>
one nice benefit of same-realm brand checking that Domenic pointed out is, current realm = relevant realm! We don't have to have that argument then.

[07:52:24.0000] <annevk>
Interesting

[07:53:00.0000] <annevk>
I'm a lil scared for same-realm brands, but I suppose it's not too different from what JavaScript has thus far, except for Array

[08:14:30.0000] <Domenic>
w3ctag design guidelines are sometimes-read, and somewhat-often cited by people

[08:14:54.0000] <Domenic>
Although I guess the recent instance I am thinking about is bz citing them, so that's not so helpful. I guess it saves bz a bit of time.

[08:15:23.0000] <Domenic>
annevk: JS has cross-realm brand checks

[08:16:18.0000] <annevk>
Domenic: hmm yeah, I guess it does mostly, so maybe I'm more concerned

[08:16:37.0000] <Domenic>
It's just more restrictive, and aligned with what JS developers are able to create in their own files

[08:17:03.0000] <Domenic>
Maybe I'm biased but I think the complexity of allowing cross-realm access at all is just a mistake of the web platform; everything should have been postMessage().

[08:17:45.0000] <Domenic>
So little steps we can take to make the platform simpler seem nice, like same-realm brand checks and that proposal from dtapuska to allow sites to isolate themselves from cross-realm access even if same-origin. (I think that's what the proposal was.)

[08:18:15.0000] <annevk>
I think a proposal that gives you an agent cluster per document has legs

[08:18:30.0000] <annevk>
What dtapuska and mikewest proposed were not quite there

[08:24:33.0000] <Domenic>
I guess I'm just focused on the simplification and not on the security boundary. Although probably we should couple them, so as not to have two things.

[08:27:00.0000] <annevk>
It's also a potential parallelization boundary and without an agent cluster it might be much harder to parallelize due to shared memory


2019-03-30
[21:38:22.0000] <devsnek>
rwaldron: has somehow enabling the host specific hooks ever come up for eshost