TC39 Delegates on 2022-03-31

13:45	<pzuraq>	Yes, would like to do that if possible
13:45	<pzuraq>	Sorry for all of the last minute additions 😅
13:54	<Ashley Claymore>	Always been curious - Is there a formal difference between the incubator calls and other (non-plenary) calls where proposals may be discussed?
13:55	<Michael Ficarra>	Ashley Claymore: incubator calls are usually just one-offs instead of recurring like most of the others
13:57	<Rob Palmer>	* Plenary begins in 3 mins! *
14:28	<yulia>	bakkot: thanks for the answer
14:29	<shu>	not familiar with that meaning of "borrowability"
14:34	<bakkot>	shu: "borrowing" a method and calling it on another instance
14:45	<Michael Ficarra>	Richard Gibson: please mute
14:48	<Justin Ridgewell>	Did we discuss whether arguments can branch on whether it has the internal slot?
14:49	<Justin Ridgewell>	Eg, https://tc39.es/ecma262/multipage/indexed-collections.html#sec-%typedarray%.prototype.set
14:49	<Michael Ficarra>	Justin Ridgewell: briefly during the presentation
14:49	<bakkot>	haven't presented that explicitly, but yes, it's a possibility
14:49	<Justin Ridgewell>	This branches on whether the argument is a true TypedArray or an iterable
14:49	<bakkot>	Michael Ficarra: we didn't talk about it for arguments specifically
14:49	<ljharb>	(fresh handler lookup was definitely a mistake tho, even if it's not why Proxy is slow)
14:49	<Justin Ridgewell>	We could have both a fast path and a customizable slow path
14:50	<ljharb>	i like the idea of detecting argument slots, and only calling the method observably if it lacks the slot
14:50	<Michael Ficarra>	V8 has said they don't want more than 2 paths because it becomes impossible to reason about
14:50	<ljharb>	but without something like constructor hooks, that still breaks expected subclass invariants
14:50	<bakkot>	and Justin Ridgewell's suggestion would satisfy markm, as I understand it
14:51	<Justin Ridgewell>	Ah, slide 10 discusses hybrid appraoch
14:51	<Justin Ridgewell>	Sorry, I need to pay more attention
14:57	<jschoi>	pzuraq: Were you still planning to request extra time for decorators? It’s not in the TCQ agenda yet.
14:58	<pzuraq>	yes, will do
14:59	<bakkot>	ljharb: thinking more, I don't understand why hooks would satisfy your use case
14:59	<bakkot>	like, the reason you do `Set.p.add.call` is presumably because you want to not use the user hooks
14:59	<bakkot>	and if the hooks are built in, now you can't avoid it
14:59	<bakkot>	so... seems bad?
15:00	<bakkot>	like if you want to give the user the option to hook, you would just call `arg.add()`
15:00	<ljharb>	no, it's because i don't want to depend on the `add` method being present
15:00	<ljharb>	certainly if someone provides a hook that throws, then i'll just throw, and that's fine
15:01	<ljharb>	but what it means is that at the time their instance is created - when i can just trust everything works - the proper behavior is set in stone, and i can invoke it later safely.
15:01	<bakkot>	couldn't you just cache the methods off the instance?
15:03	<ljharb>	my fn might be called with instances from N different subclasses, how would i cache them all
15:03	<ljharb>	iow i can rely on the instance being correct when it was created - but "when it's passed to me" is potentially much later than that
15:05	<bakkot>	so, wait, why do you not want to call the method when it's passed to you
15:05	<bakkot>	why can you trust it any more when the instance is crated than when it's passed to you
15:07	<ljharb>	if it's a subclass i probably can, tbh. but if it's not a subclass, i can't trust it because any random person could `delete Set.prototype.add`
15:07	<ljharb>	i agree this stuff is murky, and the Set constructor's calling of "add" makes this specific example probably a bad one
15:08	<bakkot>	i feel like, if someone passes you a set, and someone else has deleted `Set.prototype.add`, and you still want to work, it is not obvious to me that there's any benefit to anyone to still work
15:10	<Michael Ficarra>	like a [[SetData]] -> set-like -> iterable fallback?
15:11	<Michael Ficarra>	I guess that wouldn't hurt
15:11	<ljharb>	bakkot: for me, deleting builtins shouldn't cause any part of the app not to work, ideally.
15:13	<shu>	really? how can that be true?
15:18	<ljharb>	as long as you delete them after the app is initialized, it should keep working just fine
15:18	<shu>	wait but like, if my app uses `Math.sin` and you delete `Math.sin` how is my app supposed to work
15:19	<bakkot>	i appreciate that desire but do not think it is reasonable when you are interoperating with other people's code, since their code almost certainly does not have this property. like if they made themselves a Set, and then someone else deleted Set.prototype.add, their code is gonna break
15:21	<Michael Ficarra>	HE Shi-Jun: I would agree with that, but if we're discouraging subclassing built-ins, we shouldn't need it
15:22	<Michael Ficarra>	and it sounds like we're mostly leaning toward discouraging subclassing
15:25	<Michael Ficarra>	(also the constructor calls `add` lol)
15:25	<ljharb>	because my app at least would cache `Math.sin` on module evaluation, it wouldn't dynamically look it up at runtime on Math
15:26	<ljharb>	i appreciate that desire but do not think it is reasonable when you are interoperating with other people's code, since their code almost certainly does not have this property. like if they made themselves a Set, and then someone else deleted Set.prototype.add, their code is gonna break sure. but that doesn't mean i want my code to be the reason it breaks. i'm fine with their app breaking - i just don't want my code to be in the stack trace :-)
15:26	<shu>	oh i see, yeah i think that style is vanishingly rare
15:26	<ljharb>	it very much is
15:26	<shu>	you literally never lookup on the prototype?
15:26	<shu>	you cache every single thing?
15:26	<ljharb>	yep, only at module level
15:26	<ljharb>	in libraries, that is. in apps ofc i can have guarantees
15:26	<Michael Ficarra>	keith_miller: in Java, all method calls are virtual, so subclasses "replace M" all the time
15:26	<bakkot>	yeah I... do not want to optimize for this case
15:27	<ljharb>	i understand that lack of desire :-) i'm not asking to optimize for this case exactly. it's just that constructor hooks happens to solve it, while also checking a lot of other boxes.
15:27	<ljharb>	like your frozen set example
15:28	<Michael Ficarra>	shu: I don't even think there's a single algebraic understanding of a Set, as we discussed when considering swapping out the "comparison operation" that doesn't actually exist in practice
15:28	<shu>	i agree there isn't a single algebraic understanding
15:28	<shu>	but it doesn't actively resist an algebraic understanding like RegExp.exec?
15:28	<Michael Ficarra>	sure, but that's still limiting
15:29	<shu>	all i'm saying is if we have a minimal core for Set, it's reasonable to expect us being able to come up with and communicate an algebra
15:30	<shu>	and i think it is most def not reasonable what Kevin has categorized as "low-level" on that slide
15:30	<shu>	and that's the division in my mind
15:30	<Michael Ficarra>	shu: are you willing to maintain two radically different Set implementations though?
15:30	<shu>	i don't follow
15:31	<Michael Ficarra>	shu: like if we had constructor hooks, would you also want to provide a Set implementation with a linear time `add` that repeatedly applies the provided comparison?
15:31	<ptomato>	you mean, a fast path for builtin and a slow path for overridden?
15:31	<shu>	Michael Ficarra: i mean depends on the algebra right?
15:32	<shu>	actually i'm not sure what we're discussing anymore
15:32	<Michael Ficarra>	shu: sure, but I imagine the algebra will often not align with that of your current, fast implementation
15:32	<bakkot>	shu: a motivating question: is `clear` part of the minimal core
15:32	<bakkot>	it is clearly possible in terms of iteration/`delete`
15:32	<shu>	what does that do, in-place emptying?
15:32	<Michael Ficarra>	yes
15:32	<shu>	okay
15:33	<shu>	good question, i'd say yes
15:33	<shu>	don't write per-item finalizing logic
15:33	<shu>	bad idea
15:33	<ptomato>	fwiw I find Temporal.TimeZone a reasonable case for a minimal core of methods
15:33	<ptomato>	if you have implemented `getPossibleInstantsFor()` then you don't need to implement `getInstantFor()` as well
15:34	<ptomato>	(which just calls `getPossibleInstantsFor()` and picks one of the values in the returned array based on the other parameter you give it)
15:35	<ptomato>	I think TimeZone is definitely a "higher-level" built in, in the terminology used in the slides
15:48	<Michael Ficarra>	ptomato: are there internal slots on a `Temporal.TimeZone`?
15:48	<ptomato>	only one: the string identifier, e.g. `UTC` or `Europe/Berlin`
15:49	<ptomato>	the default implementations of the methods aren't internal slots
15:49	<ptomato>	I think we could write it that way & the difference wouldn't be observable, but I'm not 100% sure off the top of my head
15:55	<Rob Palmer>	As a heads up, we have Decorators coming back (again) for 20min in the afternoon slot today.
15:57	<jschoi>	FYI: The next discussion topic, holistic dataflow, doesn’t have slides—instead, it has a diagram and an article that you can read at https://jschoi.org/22/es-dataflow/.
15:58	<Justin Ridgewell>	More decorators?
15:59	<Michael Ficarra>	Justin Ridgewell: more decorators
16:00	<bakkot>	MORE DECORATORS
16:10	<Ashley Claymore>	I was tying to imagine writing a decorator for enforcing that a field was initialised by the end of the constructor. Am I right in thinking ~~this won't work super well~~ the only way to add logic at the end is to add a subclass?
16:13	<ljharb>	by replacing the class in a class constructor, maybe?
16:15	<bakkot>	yeah "at the end of the constructor" is not one of the positions into which decorator allow you to inject code, except by replacing the class entirely
16:15	<bakkot>	but you can indeed replace the class with a subclass which does that check
16:16	<Ashley Claymore>	cool thanks, so it would be paired up with a class level decorator with a way to communicate to it
16:17	<bakkot>	yup
16:17	<bakkot>	(I should say, this is just from my understanding of decorators, which I might easily be forgetting something)
16:17	<Ashley Claymore>	I was just thinking about the `!` initialisation assertion in TypeScript, and if that had a runtime equivalent
16:22	<ljharb>	how does that look in TS on fields?
16:23	<Ashley Claymore>	`class C { f!: string; // I promise this will be a string once constructed constructor() { this.#init(); } #init() { this.f = 'hey'; } }`
16:25	<Ashley Claymore>	I use it more when adding type-annotations to existing .js code that has that seperate `init` pattern. Rather than in new code.
16:44	<ljharb>	i assume it would depend on constructor params, otherwise you'd just initialize it as a field
16:52	<Ashley Claymore>	yeah, my example was weak. Usually the value being initialised is more complex and based on arguments being passed around
16:54	<Ashley Claymore>	If TypeScript sees a direct assignment to the field in the constructor body (not a closure) then the assertion is not required
17:01	<jschoi>	https://jschoi.org/22/es-dataflow/
17:10	<bakkot>	the module splitting thing is fake
17:11	<bakkot>	we could totally optimize those cases in bundlers
17:11	<bakkot>	we just don't
17:11	<bakkot>	those cases = prototype-based fluent apis
17:12	<shu>	i understand that to mean bundlers don't want to build more sophisticated static analysis, which, yeah, sounds like they can try to?
17:12	<bakkot>	well
17:12	<bakkot>	you really need types for it to work
17:12	<Justin Ridgewell>	We could (Closure can), but it's be incredibly hard (only TS has an equivalent type system and it's not a minifier)
17:12	<bakkot>	and it's true there are many cases where you can't figure it out
17:12	<Justin Ridgewell>	And there are tons of deopts.
17:13	<Justin Ridgewell>	A single cast, and elimination isn't guaranteed anymore.
17:13	<Justin Ridgewell>	I don't think that's an acceptable "we could but don't"
17:14	<shu>	so on paper the functional APIs have the exact same issue except the popular way to do it is simple enough (e.g. import foo and use foo without renaming or fancy namespace objects) to analyze?
17:14	<Justin Ridgewell>	Static analysis is trivial to perform, and it's built into every minifier
17:14	<bakkot>	the functional APIs are always possible to analyze unless you do a `* as x` import
17:15	<bakkot>	so the rules to learn to stay on the happy path are easier
17:15	<Justin Ridgewell>	Virtual dispatch requires types, and only Closure has a type system and minifier combined to do it.
17:15	<shu>	asked another way, functional APIs don't have complex flow like being passed to HOFs?
17:15	<Justin Ridgewell>	Namespace imports are DCEable depending on how it's used.
17:15	<bakkot>	the complex flow isn't the problem
17:15	<Justin Ridgewell>	If you do `ns.foo()`, it's easy to see only `foo` import is used
17:15	<bakkot>	ehhh
17:16	<shu>	what's the problem if not complex flow?
17:16	<bakkot>	namespace objects are exactly as difficult to analyze as OO-based modules
17:16	<Justin Ridgewell>	If you do `Object.values()`, then it becomes dynamic and you can't DCE
17:16	<Justin Ridgewell>	Not at all
17:16	<bakkot>	yes at all; they're the same thing
17:17	<Justin Ridgewell>	There's a huge difference between a static `ns` import and a dynamic variable binding to an object.
17:17	<bakkot>	you can pass `ns` imports around
17:17	<bakkot>	and now they are dynamic variables bound to objects
17:17	<Justin Ridgewell>	You can treat a namespace as an object with key-values, but that's not the norm for imports.
17:18	<Justin Ridgewell>	Again, it depends on how it's used.
17:18	<bakkot>	yeah.
17:18	<shu>	that's what i'm asking, does it come down to norms
17:18	<Justin Ridgewell>	The point is it starts from a staticly analyzable point, so it can remain statically analyzable.
17:19	<bakkot>	shu: anyway, the problem is if you have something like `function pretty(x) { console.log(x.color()) }` and `print(y)` gets called, anywhere in your code, then in order to eliminate a prototype method named `color` on some class you have to prove that no instance of the class is ever passed to `pretty`
17:19	<bakkot>	now, IME that's fairly practical, but no one really implements that optimization
17:19	<shu>	bakkot: that is exactly the "complex flow" problem?
17:19	<bakkot>	and it's true that there are places which become hard
17:19	<shu>	you gotta monomorphize and have some kind of class hierarchy analysis to eliminate
17:19	<bakkot>	ah, sorry, I didn't realize that's what you meant
17:20	<shu>	sorry yeah it's an unclear term
17:20	<bakkot>	then yes, the complex flow is the problem, and FP doesn't have nearly as much of that particular kind of flow
17:20	<Michael Ficarra>	I like that we are acknowledging this ecosystem schism, I don't think we've really explicitly talked about this enough
17:21	<shu>	a schism suggests there was some unified whole that split
17:21	<shu>	there are two paradigms
17:21	<shu>	i don't understand why the difference is so harmful yet
17:22	<Michael Ficarra>	it's entirely possible that you can mix paradigms in the language in a way that does not discourage their use together in programs
17:22	<shu>	and we have a semblance of that today
17:22	<shu>	i don't quite understand the line being drawn here as the one contended to be harmful
17:24	<Michael Ficarra>	method call syntax and function call syntax don't mix as well as they could, so it currently forces you to pick a lane and stick to it
17:24	<bakkot>	"zero cost" is also not true here; the FP paradigm gets megamorphic real fast, in a way the OO paradigm maybe does not
17:24	<shu>	that's the contention. i don't see why that's so harmful
17:25	<bakkot>	I think that "zero cost" line of thought comes from statically compiled languages
17:25	<Michael Ficarra>	bakkot: that's a good point
17:25	<Justin Ridgewell>	Other delegates have argued it's harmful, I think JSC is trying to explain it's not that bad.
17:25	<shu>	also this interop argument is a new argument to me: i though the main motivation thus far has been word order for the FP stuff
17:26	<Justin Ridgewell>	This is to explain that the schism some delegates are afraid of is actually improved by adding the call-op.
17:26	<Justin Ridgewell>	You can interop between the two styles better with both pipe and call.
17:28	<shu>	bakkot: the runtime polymorphism point is very good, yes
17:29	<shu>	if you have two distinct methods `ClassA.F` and `ClassB.F`, you've split it manually by just how you organize code into two contexts that gather type feedback independently
17:29	<shu>	i have looked at automatically inferring such splits for functional-style programs in VMs and have never had any success
17:30	<shu>	would be a fun grad problem but i don't know of any good heuristics
17:30	<shu>	once you're into the optimizing tier you can get splitting like this for free with deep inlining, but the point is this is way way before all that, before you decide to even gather type feedback
17:33	<Michael Ficarra>	shu: it's also worth considering that this feature may be used most often for high-level organisation and therefore may usually not be in the hot path
17:34	<shu>	what is "this feature"?
17:35	<Michael Ficarra>	I was thinking about the pipe operator
17:35	<shu>	very skeptical of that claim, i don't think method chaining is any less likely in hot paths, if that's a suitable analogy
17:35	<shu>	nor normal function application, if this makes some cases of that easier to read
17:42	<bakkot>	I think the point that call-this is only useful for late-binding APIs, and at that point you are not using the OO paradigm at all and so should not be talking about `this`, is very good
17:43	<bakkot>	like there's no reason not to just pass the context argument as the first API, over using call-this
17:43	<bakkot>	no reason whatsoever
17:44	<jschoi>	We’ve seen that `.call` is already one of the most common methods in the entire language, though. Like for conditional switching between methods.
17:44	<Justin Ridgewell>	like there's no reason not to just pass the context argument as the first API, over using call-this Call site ergonomics will prevent adoption of this.
17:44	<bakkot>	jschoi: again, I don't think "people are already doing this" is a good enough reason to add it to the language
17:44	<Justin Ridgewell>	Firebase is so strange in a language that has settled on OOP designs
17:45	<bakkot>	(also I didn't find your data all that convincing, to be frank)
17:45	<bakkot>	Call site ergonomics will prevent adoption of this. I don't think inventing entirely new syntax actually does amount to being a more ergonomic syntax
17:47	<ljharb>	Firebase is so strange in a language that has settled on OOP designs the language hasn't "settled" on that tho, it's just parts of the ecosystem that have.
17:47	<jschoi>	Are there any specific problems that you see in the corpus analysis? Let me know, maybe later over DM or something, and I can see if we can examine them more closely. I’m not sure how we could have done better. Your point is taken that “just because people are doing it, we shouldn’t necessarily encourage it,” but that’s separate from the validity of the data themselves.
17:48	<Robert Pamely>	Firebase is so strange in a language that has settled on OOP designs I've always found JS very unopinionated about whether applications should be written with an OOP pattern, and I see quite a lot of code written in a more functional style. Usually it's a mix.
17:48	<Justin Ridgewell>	the language hasn't "settled" on that tho, it's just parts of the ecosystem that have. This is where the puck is heading, libraries designed for code splitting will become more prevalent
17:49	<ljharb>	right but those aren't OOP
17:49	<ljharb>	those are more functional
17:49	<ljharb>	they may use some kind of "mixin" magic, or pipeline, to pretend it's OOP, but that doesn't make it that style - just written in that style
18:00	<bakkot>	`super` actually is totally reasonable
18:00	<bakkot>	if it refers to the superclass, anyway
18:01	<TabAtkins>	`this` is just a variable name; i had no idea it was distinguished in the grammar in any way and find that very surprising.
18:01	<Christian Ulbrich>	jschoi: Thx. for the presentation. It gave me a good overview and you addressed a lot of good points. Personally I agree with you - JavaScript is a multi-paradigm language and we should keep it that way. However I am also unsure, what that really means. :)
18:03	<bakkot>	TabAtkins: so you would be surprised that `this = 0` fails to parse?
18:03	<Michael Ficarra>	TabAtkins: I don't believe you
18:03	<TabAtkins>	Assignment and reference are different contexts that I'm okay to distinguish between
18:03	<TabAtkins>	Michael Ficarra: you don't believe me? how? what?
18:04	<Christian Ulbrich>	Prior art I'd say. Decorators have been using the `@` for ages...
18:04	<Michael Ficarra>	TabAtkins: working on pattern matching, you became familiar with the fact that undefined/Infinity are identifiers, which means you should know that things like `this`/`null`/`true` are not
18:05	<TabAtkins>	???? I have no idea why you'd think that's a necessity, notably the idea that `this` is definitely grouped in with the other values.
18:05	<TabAtkins>	(But also, uh, "I don't believe you" is a pretty sucky thing to allege, dude.)
18:06	<TabAtkins>	All those other things are literals in practice, even if they're technically identifiers for technicaly/legacy reasons. `this` is something completely unrelated
18:08	<ljharb>	HE Shi-Jun: `class X { static decorate() {} } class Y extends X { @super.decorate foo() {} }` something like that
18:11	<bakkot>	this isn't even a case we'd need to leave to a linter
18:12	<bakkot>	either it's a sensible thing to do, in which case people would do it and a linter shouldn't ban it, or it's not, in which case there's no need for a lint rule
18:12	<ljharb>	right, this stuff - edge cases or not - only makes sense if someone actually has a decorator to reference
18:12	<TabAtkins>	If there's not an actual problem with allowing them, then any restriction which requires authors to understand arcane details of the grammar is an unreservedly bad idea
18:12	<ljharb>	if it's there, why not allow it? if it's not there, they'll get a TypeError anyways
18:12	<Michael Ficarra>	(But also, uh, "I don't believe you" is a pretty sucky thing to allege, dude.) no offense meant, all I was saying is that I'm sure that if you had thought about it for a second, you'd have been able to figure it out, since the proposal you presented at this meeting specifically accounts for all identifiers that people don't think of as identifiers
18:14	<TabAtkins>	I had thought about it for a second, and would not have figured it out, because you're assuming that I've read the grammar deeply and recently enough to immediately know what is "identifier" and what is "other things which look similar syntactically but are a different category". I assume you've done so, but I definitely have not.
18:16	<TabAtkins>	I can rattle off the tip of my tongue arcane details of CSS syntax that would very likely confuse you (because I wrote the CSS Syntax spec and have written two parsers) but I don't have that level fo knowledge for JS.
18:17	<Mathieu Hofman>	HE Shi-Jun: `class X { static decorate() {} } class Y extends X { @super.decorate foo() {} }` something like that What does `super` reference here? It's decorating an instance method, so why would it reference the super constructor and not the super instance ?
18:17	<HE Shi-Jun>	@shu Ok, after second thought, I have to say disallowing @meta.property seems too strong... I'm still need some time to think about `@this` `@super`...
18:17	<shu>	understood. now i'm confused again what the conclusion is
18:18	<HE Shi-Jun>	One question, do we allow `@this class {}` now?
18:19	<ljharb>	why not, as long as the `this` resolves to a decorator it'd work
18:19	<bakkot>	shu: no conclusion
18:19	<ljharb>	"that thing that falls out of consistency seems gross" is a reason to lint against it, not a reason to make it a parse error
18:19	<HE Shi-Jun>	I mean, because the issue is whether to allow `@this.dec`
18:19	<shu>	bakkot: ok, thanks
18:19	<Rob Palmer>	A reminder: Rob recuses as chair during Types as Comments.
18:21	<HE Shi-Jun>	I mean, because the issue is whether to allow `@this.dec` Ok, I read the issue, `@this` is also not decided. I see.
18:21	<bakkot>	What does `super` reference here? It's decorating an instance method, so why would it reference the super constructor and not the super instance ? I would assume it has to be the super constructor; it shouldn't switch based on the kind of thing you're decorating
18:21	<bakkot>	also the decorator is called before any instance is constructed
18:21	<bakkot>	so calling an instance method (even from the prototype) is incoherent
18:22	<bakkot>	the super constructor is the only thing which actually exists at that point
18:24	<pzuraq>	bakkot: so the context currently of decorator evaluation is the same as dynamic property name evaluation
18:24	<pzuraq>	so what does
18:24	<bakkot>	hmm
18:24	<TabAtkins>	My policy as a 10+ year language designer is that the line between "valid" and "invalid" code should be, as much as possible, simple and obvious from inspection by people with an average amount of experience and familiarity with the language. Mentally, the boundary that cleaves the two should be "smooth", rather than fractally textured, to the extent possible. Exceptions are allowed when something is actually problematic (but then, it might be good to disallow more than is strictly required to make the boundary smoother and easier to remember); exceptions for "nobody would do it" are bad unless they also serve to smooth out the boundary.
18:24	<pzuraq>	`class C { [super.foo]; }`
18:24	<bakkot>	I kind of assumed it would be the same as `static {}` blocks
18:24	<pzuraq>	evalution to?
18:24	<bakkot>	I should've caught that before
18:24	<pzuraq>	I would expect it to be the `super` of the surrounding class, should it exist
18:25	<bakkot>	`class C { [super.foo]; }` refers to the `super` from the outer context, yes
18:25	<pzuraq>	which would be the same as `this`
18:25	<bakkot>	but `class extends B { static { super.x } }` refers to `B.x`
18:25	<pzuraq>	yeah, decorators evaluate before static blocks and generally have the same scope as code immediately outside of the class
18:26	<pzuraq>	same as property names
18:26	<bakkot>	boo :(
18:26	<pzuraq>	I still think that we should allow these keywords
18:27	<pzuraq>	I just don't think there are many good use cases. It would be gnarly code
18:27	<ljharb>	ok so `class Parent { static decorate() {} } class Outer extends Parent { static x = @super.decorate class {}; }`
18:27	<HE Shi-Jun>	Well I found that there could be use cases of `@super.deco class {}`, and it even could have use case of `@this.deco class {}`. but still such code look confusing. And people could always write `@(super.deco) class {}` if they want...
18:27	<ljharb>	it's fine if bad code looks confusing
18:27	<pzuraq>	ljharb: I would expect that to be a syntax error
18:27	<ljharb>	why?
18:27	<ljharb>	it's important we don't make the parsing rules confusing; linters can keep the code clean.
18:28	<bakkot>	same reason `class Outer extends Parent { [super.x] = 0; }` is a syntax error
18:28	<HE Shi-Jun>	I think Wardmar 's point stands, @keyword seems like some special magic thing.
18:28	<bakkot>	because `super` comes from the surrounding context, not from the class
18:28	<pzuraq>	same rules as dynamic properties, is why
18:28	<bakkot>	I think the dynamic property rules are the wrong ones
18:28	<bakkot>	static block rules would be better
18:28	<bakkot>	or static initializers, even
18:29	<pzuraq>	the timing is more like dynamic props
18:29	<bakkot>	ehhhhh
18:29	<bakkot>	I don't think that difference matters in a relevant way for `super`
18:31	<HE Shi-Jun>	I also remember some people discussed the possible syntax like `@this` `@@this` in dsl proposal.
18:31	<shu>	i'm pretty sure types that differ from all existing type checkers, especially with semantics, is a hard nonstarter
18:31	<shu>	and i don't really see value in broadening the problem statement in that way
18:33	<ptomato>	sorry, what is exactly being claimed here? is Waldemar's claim that Daniel says he is willing to consider other approaches but secretly will not be?
18:33	<yulia>	ill interupt
18:34	<shu>	i don't agree with this actually. i did not take "types in JS" as the problem statement put forth by the champions
18:34	<shu>	agreeing to that problem statement is a very different proposal to me
18:34	<HE Shi-Jun>	I think the high-level motivation should be narrow the gap between js and ts (or other type checkers).
18:35	<Michael Ficarra>	I would be interested in hearing the TypeScript team's stance on whether they would adopt new syntax based on a syntax space we carve out, if that's what we decide to do
18:36	<Robin Ricard>	the slide before implies that yes ts would probably take hints from the standardization process
18:36	<Robin Ricard>	I mean that is how I interpret it
18:37	<Robin Ricard>	it's a two-way discussion
18:39	<bakkot>	so like, concretely, if tc39 is like "all these declaration forms are too much, we're going to standardize on letting `:` be a new comment marker with unusual rules", would TS try to encourage users to shift over that or would they keep having `type x = 0;`
18:39	<Christian Ulbrich>	We are TC39. We are not M$. "They" present a proposal for stage 1. There is nothing, that suddenly explodes into a full-blown 200 page spec that we cannot block in any way. danielrosenwasser Has taken into consideration the various concerns and I see the proposal as broad as it should be. It is just stage 1.
18:39	<Michael Ficarra>	bakkot: I'm gonna ask exactly that
18:39	<Robin Ricard>	bakkot: from what I understand, this discussion is on the menu for stage 1
18:40	<bakkot>	ok cool
18:40	<bakkot>	I am fine with stage 1 as long as those discussions are in scope
18:40	<Robin Ricard>	I mean I am no champion so let's see what is the answer to Michael's question
18:43	<Michael Ficarra>	I'm unsure whether my topic counts as a reply anymore? that topic was kind of meandering
18:44	<Michael Ficarra>	chairs: feel free to move it if you want
18:46	<shu>	why should we tiptoe around singling out TS? i am kind of confused
18:46	<shu>	it is special in the ecosystem
18:46	<TabAtkins>	The idea that we need something close to TS to express type semantics seems overstated on its face; mypy gets by reasonably on literally nothing more than `Foo[Bar, Baz]` for its types.
18:46	<shu>	we are not picking winners
18:47	<bakkot>	shu: for one thing, TS keeps adding new syntax, so sticking with their current syntax is bad even if you ignore any other type checkers
18:47	<shu>	that's not what i'm saying
18:47	<bakkot>	seems reasonably likely that the type syntax of 2040 does not look like TS
18:47	<bakkot>	even if it's still called that
18:47	<shu>	i'm saying a non-technical thing, that it is fine to call out TS as part of the problem statement
18:47	<bakkot>	(and it might not be)
18:47	<bakkot>	hm
18:47	<shu>	i agree that merging the grammars is infeasible
18:48	<shu>	but apparently the two statements are somehow equivalent in folks' minds? that's confusing to me
18:48	<TabAtkins>	yeah, calling out TS as something that should be accommodateable seems reasonable for the problem statement
18:48	<shu>	like, i do not want the problem statement to be "types in JS"
18:48	<shu>	that's not a problem i'm actually interested in solving! but narrowing gap to TS certainly is
18:49	<bakkot>	who's the speaker? for the notes
18:49	<Michael Ficarra>	Francisco Tolmasky
18:49	<yulia>	Francisco Ryan Tolmasky I
18:49	<Richard Gibson>	shu I very much appreciated your earlier reframing to something like "non-functional syntax that is unambiguously associated with a parse node"
18:50	<bakkot>	this person does not have an acronym
18:50	<shu>	Richard Gibson: thank you
18:50	<yulia>	like, nowhere?
18:50	<Michael Ficarra>	hmm, that's surprising
18:51	<SoftwareChris>	https://github.com/tc39/notes/blob/main/delegates.txt
18:51	<SoftwareChris>	not seeing them
18:51	<yulia>	...
18:51	<shu>	what's their affiliation?
18:51	<Pieter Ouwerkerk>	he's from RunKit
18:51	<Michael Ficarra>	somebody skipped an onboarding step
18:51	<shu>	is that a member?
18:51	<Pieter Ouwerkerk>	the application to TC39 was in his name but I'll add the issue to GitHub
18:52	<Robin Ricard>	RunKit, Inc. is an SPC member
18:52	<yulia>	thanks folks
18:53	<SoftwareChris>	I'm not seeing any onboarding issue for them in GH
18:54	<Pieter Ouwerkerk>	(creating the onboarding issue, he was under the impression this was all done already)
18:55	<SoftwareChris>	that's not a problem i'm actually interested in solving! but narrowing gap to TS certainly is if the problem the proposal is trying to solve is specific to TS, that needs to be made clear
18:55	<shu>	genuinely asking, in what way is this currently unclear
18:55	<shu>	and to be clear, there is nuance to "specific to TS"
18:55	<shu>	it does not mean "make JS TS"
18:56	<shu>	it means "narrowing gap to TS is part of the goal"
18:56	<SoftwareChris>	the responses to WH sounded like it was not specific to TS
18:56	<Robin Ricard>	to be clear, it is not solely around ts and there should be efforts to accomodate flow as well for instance even if it is less used
18:56	<shu>	a solution can be not exclusive to TS and still be specific to TS
18:56	<shu>	is how i understood it
18:56	<Robin Ricard>	flow and ts could evolve their type system in the same standardized space
18:57	<Pieter Ouwerkerk>	(creating the onboarding issue, he was under the impression this was all done already) https://github.com/tc39/Admin-and-Business/issues/223
18:58	<Michael Ficarra>	can we put the scope clarifications in the conclusion of the notes?
18:58	<Michael Ficarra>	agree with ljharb we should be careful about community messaging
18:59	<shu>	big +1 to kevin's thing
18:59	<Christian Ulbrich>	Community is already afraid: -> https://medium.com/codex/the-typescript-team-is-going-to-kill-javascript-59c65937258c
18:59	<gkz>	Daniel said the other day on the record that they would not give special treatment to TypeScript and would maintain neutrality among TS vs. Flow vs. X (with the caveat that what the committee decides is not up to him)
19:00	<gkz>	Which we will hope to see in upcoming discussions
19:00	<gkz>	I assume the proposal repo will need to be updated to reflect this
19:00	<TabAtkins>	That blogpost is jumping to some very wrong conclusions, so shrug.
19:01	<Michael Ficarra>	Community is already afraid: -> https://medium.com/codex/the-typescript-team-is-going-to-kill-javascript-59c65937258c this person is already severely mistaken in thinking that there will ever be a type system built into JS
19:02	<bakkot>	we really gotta make, like, a formal statement about that somewhere
19:02	<TabAtkins>	lol, but even if we did, we're still cool to do so with a pragma.
19:02	<bakkot>	people keep thinking it will happen
19:02	<shu>	how is TS's system not "real"
19:02	<shu>	lol
19:03	<ljharb>	i dunno, depends how you define "real" :-p
19:03	<shu>	i define it by a thing that exists?
19:03	<bakkot>	things not in the JS specification are not real
19:03	<bakkot>	for example, console.log is fake
19:03	<shu>	new worldview
19:04	<TabAtkins>	"understood and given meaning by the browser" is a reasonable definition of "real" in this context
19:04	<Kris Kowal>	Thank you yulia. That was much needed.
19:04	<HE Shi-Jun>	Very great, where is the slide?
19:05	<yulia>	https://docs.google.com/presentation/d/1ls5RZiBaLekVrJoj4Ju8hBSGQdKLTXU1uI-0XcjcDvs/edit#slide=id.g1210bab1685_0_75
19:05	<yulia>	spec is here: https://ci.tc39.es/preview/tc39/ecma262/sha/efb411f2f2a6f0e242849a8cc8d7e21bbcdff543/#sec-apl-expression-rules
19:05	<HE Shi-Jun>	I'd like to share it to all chinese delegates because they are sleeping now
19:05	<yulia>	pr is here https://github.com/tc39/ecma262/pull/2717
19:05	<yulia>	it is april 1st in china, so we are shipping a bit early but it is april first somewhere
19:05	<shu>	TabAtkins: i had thought this, but! not being in ecma262 isn't what's stopping browsers from interpreting TS with a typechecker
19:06	<Michael Ficarra>	we made it through everything?! no overflow! thanks chairs!
19:06	<pzuraq>	bakkot: another thing to consider re: `super` in decorators is that decorator evaluations are interwoven with dynamic prop evaluations
19:06	<pzuraq>	it would be possible to switch the context back and forth for each one, but certainly confusing
19:06	<pzuraq>	and I'm not sure if possible performantly
19:07	<pzuraq>	I guess in implementation it's probably different than in spec
19:18	<Luca Casonato>	Congrats on stage 5 yulia! Really record setting championing right there!
19:23	<ioanna>	Really the best proposal ever! 👏 💯 😁
19:31	<bakkot>	it would be possible to switch the context back and forth for each one, but certainly confusing that's already how it works for `static` properties
19:31	<pzuraq>	?
19:31	<pzuraq>	static properties initialize in a separate phase interleaved with static blocks, after computed property names
19:31	<pzuraq>	the context remains the same for the whole phase
19:32	<bakkot>	what, really
19:32	<bakkot>	could've sworn we said it was going to be interleaved
19:32	<bakkot>	well, whatever
19:32	<bakkot>	I don't think anyone is actually going to notice the timing stuff
19:32	<bakkot>	it would be confusing if you were an interpreter, but it's fine when you're just reading the code, since they're visibly different kinds of things
19:47	<shu>	who among us can say we are not interpreters
19:52	<Rob Palmer>	"Types as Comments" is now renamed to "Type Annotations" as per Waldermar's suggestion https://github.com/tc39/proposal-type-annotations
23:46	<shu>	turns out there were many tests testing for the weird `Symbol.species` path in TypedArray constructors: https://github.com/tc39/test262/pull/3460
23:46	<shu>	another data point for test262 is the main determinant of interop