| 02:06 | <devsnek> | is MethodDefinitionEvaluation of AsyncMethod and AsyncGeneratorMethod not supposed to handle private names? |
| 02:06 | <devsnek> | the other two do |
| 02:07 | <devsnek> | oh nvm i missed that its calling DefineMethodProperty instead of DefinePropertyOrThrow |
| 04:57 | <devsnek> | i don't think the default base constructor sets up private fields correctly |
| 04:57 | <devsnek> | i think it is missing a call to InitializeInstanceElements |
| 05:04 | <devsnek> | https://github.com/tc39/ecma262/pull/2462 |
| 05:20 | <bakkot> | yup |
| 05:20 | <bakkot> | all fields, not just private |
| 05:21 | <bakkot> | the fact that the spec differentiates built-in and ecmascript function objects is dumb |
| 05:21 | <bakkot> | I wonder if we can fix that |
| 05:45 | <devsnek> | why do all the new abstract ops take the property before the target object |
| 05:45 | <devsnek> | this is driving me nuts |
| 05:46 | <bakkot> | e.g.? |
| 05:46 | <devsnek> | DefineMethodProperty(propkey, object, ...) |
| 05:46 | <devsnek> | PrivateGet(P, O) |
| 05:46 | <devsnek> | etc |
| 05:47 | <bakkot> | uhhhh yeah that's super weird |
| 05:47 | <bakkot> | no idea |
| 05:47 | <devsnek> | lol |
| 05:48 | <bakkot> | PRs welcome |
| 05:48 | <bakkot> | I'll do it sometime this weekend if you don't |
| 05:48 | <devsnek> | we'll see where my motivation is |
| 05:53 | <devsnek> | hmmm |
| 05:53 | <devsnek> | MethodDefinitionEvaluation is duplicating calls to SetFunctionName |
| 05:54 | <devsnek> | that fails an assert |
| 05:54 | <devsnek> | ignoring the assert it probably breaks those changes to keep function property ordering consistent |
| 05:55 | <bakkot> | Which two steps do SetFunctionName? |
| 05:55 | <devsnek> | RS itself calls it |
| 05:55 | <devsnek> | and then it calls DefineMethodProperty |
| 05:56 | <devsnek> | which calls it again |
| 05:57 | <bakkot> | ah, just in the generator and async generator cases, yes? |
| 05:59 | <devsnek> | ye |
| 06:02 | <bakkot> | why do generators and async generators have .prototypes anyway |
| 06:03 | <devsnek> | cuz they create instances |
| 06:03 | <devsnek> | i think there's a flow chart in the spec :P |
| 06:05 | <bakkot> | oh god I did not realize that that the instances returned by invoking a function* f() {} inherit from f.prototype |
| 06:05 | <bakkot> | I wonder if anyone is using that for anything |
| 06:05 | <bakkot> | seems like kind of an odd thing to want |
| 06:08 | <devsnek> | oh man private fields have so many early errors this is gonna take forever |
| 06:16 | <bakkot> | fix for the SetFunctionName bug in https://github.com/tc39/ecma262/pull/2463 |
| 06:27 | <devsnek> | nice |
| 06:27 | <devsnek> | why is it a syntax error to do class { get #f() {} static set #f(v) {} } |
| 06:29 | <bakkot> | same reason it's a syntax error to do (class { #f; static #f; }), presumably |
| 06:29 | <bakkot> | you can make a private name for use on instances or for use on the class, not the same name for both |
| 06:32 | <devsnek> | idk it seems it could be well defined to me |
| 06:33 | <bakkot> | lotta things could be |
| 06:33 | <bakkot> | see previous discussion in at least https://github.com/tc39/proposal-static-class-features/issues/47 |
| 06:34 | <bakkot> | also https://github.com/tc39/proposal-class-fields/issues/256#issuecomment-511213911 |
| 06:48 | <devsnek> | [[PrivateMethods]] and [[Fields]] are not initialized for normal functions |
| 06:48 | <devsnek> | so calling InitializeInstanceFields fails there |
| 06:49 | <devsnek> | maybe OrdinaryFunctionCreate is a good place to set those to new empty lists? |
| 07:05 | <bakkot> | I think I'd prefer to either have [[ConstructorKind]] differentiate between class-based ctors and non-, or have InitializeInstanceElements guard on the existence of each slot before reading it |
| 07:06 | <bakkot> | though, I guess we do say in table 33 that all ES functions have those fields |
| 07:08 | <bakkot> | oh, or we could guard on [[IsClassConstructor]] |
| 07:09 | <bakkot> | but given that we do say every function has those two, probably having OrdinaryFunctionCreate initialize them to empty is correct, yeah |
| 07:26 | <devsnek> | i don't think test262 has a test for 'use strict'; delete x applying recursively, like 'use strict'; delete ((x)) |
| 13:19 | <jmdyck> | bakkot: "the fact that the spec differentiates built-in and ecmascript function objects is dumb" Why is that distinction relevant to 2462? |
| 13:41 | <HE Shi-Jun> | oh god I did not realize that that the instances returned by invoking a |
| 15:02 | <bakkot> | jmdyck: because InitializeInstanceElements was already invoked by the [[Construct]] method of ES functions, just not the [[Construct]] method of built-in functions |
| 15:18 | <devsnek> | dang this early error for arguments is especially weird |
| 15:23 | <jmdyck> | Hm. So for an ordinary built-in constructor, IIE is called from ordinary [[Construct]], but for exotic built-in constructor, exotic [[Construct]] doesn't/can't call IIE, so IIE must be called from the _behaviour_ supplied to CreateBuiltinFunction? |
| 15:25 | <devsnek> | class X { #y; foo() { eval('this.#y') } } |
| 15:25 | <devsnek> | how does the #y existing get piped into eval |
| 15:26 | <bakkot> | jmdyck: correct (for base constructors) |
| 15:29 | <bakkot> | devsnek: EvalDeclarationInstantiation step 6/7 |
| 15:29 | <devsnek> | oh i mean |
| 15:29 | <devsnek> | during parsing |
| 15:30 | <bakkot> | the rule is not applied during parsing |
| 15:30 | <devsnek> | wdym |
| 15:30 | <bakkot> | see the last item in https://tc39.es/ecma262/multipage/ecmascript-language-scripts-and-modules.html#sec-scripts-static-semantics-early-errors |
| 15:30 | <devsnek> | man |
| 15:30 | <devsnek> | ok so if eval, turn off private name validation |
| 15:31 | <bakkot> | well, that's how it's specified, yes |
| 15:31 | <bakkot> | same as for validation of super and new.target |
| 15:31 | <bakkot> | in practice, you'd just find the names before parsing and provide them to the parser |
| 15:32 | <devsnek> | uh |
| 15:32 | <devsnek> | oh you mean like as an optimization to skip having to actually evaluate? |
| 15:33 | <bakkot> | more as a matter of how parsers are implemented; they usually validate as they go, rather than after the fact |
| 15:33 | <bakkot> | but either way works |
| 15:33 | <bakkot> | I guess plausibly they'd keep a list of names that escape |
| 15:34 | <bakkot> | and return that, and do the validation just after parsing by comparing that list to the list of names available in the surrounding context |
| 15:34 | <devsnek> | when i press alt+1, to switch to my first browser tab |
| 15:34 | <jmdyck> | bakkot: So then if an implementation chooses to implement a built-in constructor as an ordinary function constructor, it has to 'ignore' the call to IIE in _behaviour_, because the ordinary [[Construct]] will call it. |
| 15:34 | <devsnek> | the multipage spec navigates to #sec-ecmascript-function-objects |
| 15:36 | <bakkot> | jmdyck: I suppose, yes |
| 15:36 | <bakkot> | at the very least, if we keep the distinction between the two, we really need to remove the bit that says you can implement built-in functions as ES functions |
| 15:37 | <bakkot> | it's already allowed by the as-if rule, the spec shouldn't have to care |
| 15:37 | <bakkot> | devsnek: it's navigating to your first pin, I think |
| 15:37 | <bakkot> | multipage or not |
| 15:37 | <devsnek> | ah |
| 15:38 | <devsnek> | i didn't realized that was pinned |
| 15:38 | <devsnek> | is that just firefox not capturing its own tab navigation event |
| 15:38 | <bakkot> | presumably |
| 15:38 | <devsnek> | 😔 |
| 15:39 | <devsnek> | so with this eval rule |
| 15:39 | <devsnek> | what handles the private field not existing at runtime |
| 15:40 | <bakkot> | EvalDeclarationInstantiation step 6/7 |
| 15:40 | <jmdyck> | bakkot: Isn't it observable whether a built-in is ordinary or exotic? |
| 15:40 | <devsnek> | ah |
| 15:40 | <bakkot> | jmdyck: uhhh I hope not |
| 15:41 | <jmdyck> | ok, maybe i'm misremembering |
| 15:41 | <bakkot> | It's entirely possible, there's some weird corners here |
| 15:41 | <bakkot> | but I hope not |
| 15:51 | <devsnek> | i think it used to be |
| 15:51 | <devsnek> | but someone changed that |
| 15:52 | <devsnek> | i recall a presentation discussing if builtins should appear to have been strict or not |
| 15:52 | <jmdyck> | if a built-in is ordinary, it's required to be strict |
| 15:54 | <jmdyck> | But couldn't an implementation say, it's exotic, but it happens to present like a non-strict ordinary? |
| 15:59 | <jmdyck> | What's the intended normative effect of requiring ordinary built-ins to be strict? |
| 16:00 | <devsnek> | under 200 tests failing :O |
| 16:01 | <jmdyck> | Presumably we don't have tests for this, because the test doesn't know how the implementation has implemented a given built-in. |
| 16:02 | <devsnek> | are there properties a function can't have in strict mode |
| 16:02 | <devsnek> | like caller or callee or something weird like that |
| 16:09 | <jmdyck> | Annex C says "An implementation may not extend, beyond that defined in this specification, the meanings within strict functions of properties named "caller" or "arguments" of function instances." |
| 16:10 | <bakkot> | yeah, but "Built-in functions ... also must not be created with such own properties" |
| 16:10 | <bakkot> | IIRC the strictness thing was to do with whether this was undefined or the global |
| 16:11 | <bakkot> | I will try to track it down |
| 16:14 | <jmdyck> | It looks like the sentence "Built-in functions that are ECMAScript function objects must be strict..." was added in wd20 of ES6. |
| 16:15 | <jmdyck> | (Sept/Oct 2013) |
| 16:19 | <bakkot> | I am having no lucking finding it |
| 16:19 | <bakkot> | but the this thing is at least plausible |
| 16:20 | <bakkot> | a lot of builtins operate on their this, and it makes sense to say that if you pull those off their containing object and invoke them directly they should not be operating on the global |
| 16:22 | <jmdyck> | The change-notes for rev 20 say "Elaborated in 9.3 that built-in functions can be implemented as either ECMAScript functions or as implementation defined exotic functions." but they don't mention the strictness thing. It might be in one of the many bugs that rev20 fixed. |
| 16:23 | <Jack Works> | That's... a familiar topic |
| 16:28 | <Jack Works> | I presented on Feb 2020 about to make all implementation defined functions in strict mode |
| 16:30 | <jmdyck> | For what normative effect? |
| 16:30 | <Jack Works> | No progress since then. Maybe I should open a PR |
| 16:30 | <bakkot> | https://github.com/tc39/notes/blob/master/meetings/2020-02/february-5.md#legacy-reflection-features-for-functions-in-javascript-for-stage-1 |
| 16:30 | <jmdyck> | No, I mean, what would have been the normative effect? |
| 16:35 | <Jack Works> | Back to time that was presented, Chakra (Classic edge) leaks native function (according to spec, strict function are not allowed to be leaked) in loose mode. Is that a normative effect? |
| 17:42 | <jmdyck> | What does "leak" mean? |
| 17:59 | <bakkot> | In this context, I'm pretty sure it means "appear as the .caller of a sloppy function" |
| 17:59 | <bakkot> | as in function f(){ console.log(f.caller); } function g(){ f(); } g() |
| 18:00 | <bakkot> | note the change if you put 'use strict' in g |
| 18:01 | <bakkot> | see the third slide in https://github.com/tc39/agendas/blob/master/2020/02_talk_codiy-dot-caller.pdf |
| 18:11 | <devsnek> | am i crazy or are class field tests like 1/10th of all test262 tests |
| 18:32 | <justingrant> | Just wait until Temporal lands. 2700 tests and lots more to come. |
| 18:56 | <devsnek> | i think class fields has around 16000 |