2020-08-01
[17:37:08.0000] <devsnek>
down to 2500 failing tests 👀

[17:40:13.0000] <Bakkot>
we gotta start writing tests faster, I see

[18:08:28.0000] <devsnek>
step 4.a of IteratorDestructuringAssignmentEvaluation

[18:08:37.0000] <devsnek>
AssignmentElement  :DestructuringAssignmentTarget Initializeropt

[18:09:03.0000] <devsnek>
it references |AssignmentExpression| and |LeftHandSideExpression|

[18:09:23.0000] <devsnek>
i think its supposed to be Initializer and DestructuringAssignmentTarget, respectively?

[18:10:35.0000] <Bakkot>
sounds right to me

[18:11:23.0000] <Bakkot>
looks like a bad copy from the runtime semantics for AssignmentExpression

[18:12:40.0000] <Bakkot>
want to file the PR or shall I?

[18:26:38.0000] <devsnek>
if you want to i won't stop you

[19:00:58.0000] <Bakkot>
jridgewell: the last change in https://github.com/tc39/ecma262/commit/4886f4c6a362b48d23bffbc6d05f35e4803c5ecb is not intentional, right?

[19:05:05.0000] <Bakkot>
filed https://github.com/tc39/ecma262/pull/2121

[22:15:28.0000] <ryzokuken>
ciwsoljjexit

[22:15:36.0000] <ryzokuken>
oop

[22:15:41.0000] <ryzokuken>
sorry

[22:17:07.0000] <rkirsling>
lol


2020-08-02
[19:11:42.0000] <devsnek>
does the production LabelledItem : FunctionDeclaration only exist so B.3.2 can modify it

[19:25:43.0000] <jmdyck>
Modify its Early Error rule, yeah looks like it.

[20:53:08.0000] <devsnek>
so in regex

[20:53:10.0000] <devsnek>
\0 is nul

[20:53:23.0000] <devsnek>
\1 through \9 are meta "nth capturing group" magi

[20:53:25.0000] <devsnek>
magic*

[20:53:36.0000] <devsnek>
and any other digits are just an escape

[20:53:39.0000] <devsnek>
?

[20:54:33.0000] <jmdyck>
digits other than 0-9?

[20:56:43.0000] <devsnek>
like \123

[20:58:52.0000] <jmdyck>
no, \123 should be a reference to the 123rd capturing group

[20:59:30.0000] <devsnek>
> /\123/.test('S')

[20:59:55.0000] <jmdyck>
(but only if the regex has at least 13 capturing groups

[21:00:12.0000] <jmdyck>
"It is a Syntax Error if the CapturingGroupNumber of DecimalEscape is larger than NcapturingParens (21.2.2.1)."

[21:00:15.0000] <rkirsling>
yeah the magic only applies if the capturing groups exist

[21:00:19.0000] <rkirsling>
`/\1/.test('\1')` is true

[21:00:25.0000] <jmdyck>
(s/13/123/)

[21:00:35.0000] <devsnek>
this is evil i hate this

[21:03:28.0000] <jmdyck>
well, at least you don't have to interpret it as "\1 followed by '23'" if the regex has < 12 cap groups, or "\12 followed by '3'" if it has less than 123 groups

[21:04:02.0000] <devsnek>
i would've just not had octal escapes

[21:04:33.0000] <jmdyck>
Legacy!

[02:54:34.0000] <jackworks>
https://twitter.com/jackworks_asref/status/1289859760829812738

[02:55:00.0000] <jackworks>
CC people in the chrome team here 👀

[10:58:11.0000] <devsnek>
where's the definition of IteratorDestructuringAssignmentEvaluation for ObjectAssignmentPattern

[11:01:59.0000] <Bakkot>
devsnek: is IteratorDestructuringAssignmentEvaluation ever invoked for ObjectAssignmentPattern?

[11:02:05.0000] <Bakkot>
I don't see a path whereby that could happen

[11:02:05.0000] <devsnek>
like if you have

[11:02:08.0000] <devsnek>
[{}]

[11:02:37.0000] <devsnek>
that says do the IteratorDestructuringAssignmentEvaluation of AssignmentElementList

[11:04:48.0000] <devsnek>
oh wait the refinements are lazy

[11:04:53.0000] <devsnek>
this makes more sense now

[11:05:06.0000] <Bakkot>
IteratorDestructuringAssignmentEvaluation  is defined for `AssignmentElisionElement:AssignmentElement`

[11:05:30.0000] <Bakkot>
and for `AssignmentElement : DestructuringAssignmentTarget Initialzer_opt`

[11:05:37.0000] <devsnek>
yeah i see now

[11:05:45.0000] <devsnek>
when i was refining the ArrayLiteral

[11:05:50.0000] <devsnek>
i was doing it recursively

[11:06:17.0000] <Bakkot>
ah, yeah

[12:56:05.0000] <devsnek>
((x = eval('var x = 1')) => {})()

[12:56:12.0000] <devsnek>
apparently this is supposed to throw a SyntaxError

[12:56:55.0000] <devsnek>
i'm guessing from EvalDeclarationInstantiation step 3.d ish?

[13:01:05.0000] <Bakkot>
I believe so

[13:01:13.0000] <Bakkot>
this is fairly new; see https://github.com/tc39/ecma262/pull/1046

[13:02:32.0000] <devsnek>
spooky


2020-08-03
[18:16:45.0000] <devsnek>
does test262 have coverage for `export { a }; let a` in that order?

[18:17:13.0000] <devsnek>
i don't think there's such an occurrence in module-code

[09:53:46.0000] <jmdyck>
waah, rebasing 2007 to master us such a pain

[09:54:27.0000] <Bakkot>
jmdyck :(

[09:54:37.0000] <Bakkot>
I can take care of it this evening probably

[09:55:11.0000] <jmdyck>
tx

[09:55:43.0000] <jmdyck>
you may want to squash the 13 commits first

[10:01:08.0000] <devsnek>
is anyone working on moving `__proto__` into the main spec

[10:01:19.0000] <devsnek>
iirc we have consensus to generally smoosh things from annex b to the main spec?

[10:02:14.0000] <ljharb>
not everything, but many

[10:07:00.0000] <bradleymeck>
yea, i think the merging is more about things that are causing differences due to grammar collisions

[10:08:09.0000] <bradleymeck>
e.g. <!-- comments , mark had a presentation where XS which doesn't support them since they are optional actually evaluated code differently than other engines with same source text

[10:12:41.0000] <devsnek>
yeah the scary things aside

[10:12:54.0000] <devsnek>
if there's consensus to move __proto__ I might make a pr

[10:58:51.0000] <bradleymeck>
i don't want __proto__ to be required as some people state any env that disables/removes ECMA262 builtins to be non-complaint

[10:59:09.0000] <bradleymeck>
and __proto__ is a rats nest of bugs and I think it is reasonable to disable as a host

[10:59:46.0000] <devsnek>
bradleymeck: it can be normative optional I guess?

[10:59:57.0000] <bradleymeck>
sure

[11:00:24.0000] <Bakkot>
__proto__ in object literals is much more reasonable than the getter/setter

[11:00:31.0000] <devsnek>
agree with that

[11:04:25.0000] <devsnek>
could do syntax required, accessor optional

[11:04:31.0000] <devsnek>
or both optional

[11:06:00.0000] <bradleymeck>
syntax would need to be required per the grammar concern since it is really special

[11:06:08.0000] <bradleymeck>
but i don't think anyone is against that

[11:06:16.0000] <devsnek>
seems reasonable

[11:06:31.0000] <devsnek>
I'll open a pr at some point before the next meeting I guess

[15:34:28.0000] <bradleymeck>
trailing comma expressions... `general,; chaos


2020-08-04
[21:59:24.0000] <Bakkot>
jmdyck: rebased 2007

[22:03:50.0000] <Bakkot>
also rebased my in-progress branch on top of it, https://github.com/tc39/ecma262/tree/fix-math-fix

[08:56:53.0000] <devsnek>
DecimalEscape :: NonZeroDigit DecimalDigits [lookahead != DecimalDigit]

[08:56:56.0000] <devsnek>
what does that lookahead do

[08:57:53.0000] <devsnek>
s/DecimalDigits/DecimalDigits?/

[10:44:37.0000] <devsnek>
i think the `i` in the spec is broken

[10:44:41.0000] <devsnek>
in terms of the runtime semantics

[10:45:53.0000] <devsnek>
if you do `/x/i.test('X')` you get PatternCharacter x which does CharacterSetMatcher(['x'], false, 1)

[10:47:07.0000] <devsnek>
oh nvm i'm wrong

[11:36:48.0000] <devsnek>
> Let n be the number of elements in r's captures List. (This is the same value as 21.2.2.1's NcapturingParens.)

[11:36:56.0000] <devsnek>
wouldn't this be number of elements - 1

[11:37:25.0000] <devsnek>
the first element is undefined and then there is an element for each capturing paren

[12:01:00.0000] <jmdyck>
devsnek: I think the spec has some off-by-1 errors wrt captures List

[12:01:14.0000] <devsnek>
yeah that's what i'm thinking too

[12:01:40.0000] <devsnek>
i'm not familiar enough to regex to guess what is supposed to happen in all these loops and stuff

[12:01:44.0000] <devsnek>
i guess i can brute force it :P

[12:02:28.0000] <gibson042>
attempt to start improving that: https://github.com/tc39/ecma262/pull/2112

[12:03:00.0000] <devsnek>
oh wow

[12:03:07.0000] <devsnek>
btw i just completely rewrote regex in engine262

[12:03:12.0000] <devsnek>
it mirrors the spec pretty closely

[12:03:18.0000] <devsnek>
if you want to check your pr

[12:03:37.0000] <devsnek>
well i still need to push up a few more things

[12:07:54.0000] <jmdyck>
e.g., consider the two calls to BackreferenceMatcher... If you have a DecimalEscape like `\1`, then you evaluate the `1` to get the Number value *1*, and pass that to the first param of BackrefMatcher.

[12:08:24.0000] <devsnek>
i'm not against us doing a weird offset thing by having the first element be undefined

[12:10:16.0000] <jmdyck>
But if you have a GroupName-escape like `\k<foo>`, ... oh, it does work, never mind.

[12:11:32.0000] <gibson042>
I think the fundamental trouble in this space stems from https://tc39.es/ecma262/#sec-pattern : "indexed 1 through _NcapturingParens_"

[12:12:27.0000] <devsnek>
`\d-a`

[12:12:36.0000] <devsnek>
that's ClassAtomNoDash `-` ClassAtom

[12:12:40.0000] <devsnek>
right

[12:13:11.0000] <devsnek>
actually wait could that be

[12:13:25.0000] <devsnek>
ClassAtomNoDash ClassAtom ClassAtomNoDash?

[12:13:38.0000] <devsnek>
i guess that would make more sense

[12:15:06.0000] <jmdyck>
"indexed 1 through _NcapturingParens_" conflicts with 6.2.1's "The elements of a list may be randomly accessed using 0-origin indices." so 6.2.1 should at least reflect that possibility.

[12:26:00.0000] <devsnek>
gibson042: atm there's stuff like this "If there does not exist a member a of set A such that Canonicalize(a) is cc, return failure"

[12:26:15.0000] <devsnek>
what if the evaluation semantics were changed so that the sets were pre-canonicalized

[13:02:12.0000] <gibson042>
like what I'm already doing with _WordCharacters_, or something more?

[13:03:49.0000] <devsnek>
every pattern evaluator that returns characters would have to call Canonicalize on them

[13:04:47.0000] <devsnek>
like rn CharacterEscape returns CharacterValue of CharacterEscape

[13:05:00.0000] <devsnek>
so then it would return Canonicalize(CharacterValue of CharacterEscape)

[13:11:39.0000] <gibson042>
CharacterSetMatcher appears to be the only place for that, at least if my PR is merged

[13:28:11.0000] <gibson042>
so I think it would be something in that operation like "1. Let _C_ be the CharSet that contains Canonicalize(_a_) if and only if _A_ contains _a_." and then subsequent use of _C_ rather than _A_.

[13:44:14.0000] <gibson042>
I found a suspected off-by-one error at https://tc39.es/ecma262/#sec-atomescape . Evaluation of AtomEscape :: `k` GroupName invokes BackreferenceMatcher with 0-indexed _parenIndex_ rather than 1-indexed _parenIndex_ + 1

[14:22:52.0000] <jmdyck>
gibson042: No, I thought that too (see above), but _parenIndex_ is 1-indexed. I.e. the first (leftmost) group gets a _parenIndex_ of 1

[14:25:58.0000] <jmdyck>
because the GroupSpecifier that step 1 finds is *within* a group, so the leftmost GroupSpecifier still has one left-capturing paren to its left.

[14:32:47.0000] <gibson042>
I don't think that's right, AtomEscape :: `k` GroupName looks like `\k<foo>`—there may not *be* enclosing parentheses

[14:33:55.0000] <jmdyck>
parentheses around `\k<foo>` don't matter

[14:34:32.0000] <gibson042>
ah, I see

[14:34:55.0000] <jmdyck>
step 1 looks for a GroupSpecifier, which necessarily occurs within parens

[14:35:22.0000] <jmdyck>
specifically a left-cap paren to its immediate left

[14:37:23.0000] <gibson042>
yep

[14:37:41.0000] <jmdyck>
Might be worth a Note.

[14:38:06.0000] <gibson042>
I was thinking an assertion, but I'm not sure if it would be better in that evaluation or in BackreferenceMatcher

[14:39:48.0000] <jmdyck>
You could certainly assert that parenIndex >= 1 (in either spot), but that doesn't help explain why it's true.

[14:41:18.0000] <gibson042>
but it does head off the mistaken assumption

[14:47:00.0000] <jmdyck>
Maybe, if you put it right after the "Let parenIndex be...". If you put it in BackrefMatcher, it's still pretty easy to think that `k GroupName` fails to satisfy the assertion.

[14:49:56.0000] <jmdyck>
Maybe best would be a Note in `k GroupName` and an assertion in BackrefMatcher.

[15:44:48.0000] <gibson042>
jmdyck: https://github.com/tc39/ecma262/pull/2112/commits/6c45aff421737171d858e6361134ad5467506a06

[16:38:35.0000] <devsnek>
Bakkot: what did i do wrong https://gc.gy/64289291.png

[16:46:12.0000] <Bakkot>
devsnek: the linter does not expect method names to have underscores

[16:46:33.0000] <Bakkot>
I'll fix it before we land this

[16:47:32.0000] <devsnek>
aight

[16:47:58.0000] <devsnek>
ugh idk how to deal with https://tc39.es/ecma262/#step-json-parse-parse

[16:48:56.0000] <devsnek>
maybe a grammar parameter?

[16:56:08.0000] <devsnek>
very pretty https://twitter.com/GinoRaidy/status/1290684214673846273

[16:56:13.0000] <devsnek>
oops

[16:56:18.0000] <devsnek>
https://gc.gy/64290364.png

[16:56:20.0000] <devsnek>
stupid clipboard

[16:56:38.0000] <devsnek>
please disregard above association between "very pretty" and twitter link

[16:56:42.0000] <jmdyck>
devsnek: you mean how to deal with the extended PropertyDefinitionEvaluation semantics thing?

[16:57:19.0000] <devsnek>
yeah


2020-08-05
[17:00:37.0000] <jmdyck>
so you're thinking of a grammar parameter that doesn't affect the grammar at all, it's just there to convey some info to a deep node?

[17:02:21.0000] <Bakkot>
grammar parameter doesn't seem like the way to go to me

[17:02:32.0000] <Bakkot>
I would just spell it out in prose

[17:04:08.0000] <devsnek>
not sure how to spell it out with prose

[17:04:26.0000] <jmdyck>
same as it is now?

[17:04:37.0000] <devsnek>
"evaluate script except make sure that isProtoSetter is false"?

[17:04:51.0000] <devsnek>
jmdyck i'm working on moving __proto__ into the main spec

[17:05:07.0000] <Bakkot>
"except that in the semantics for PropertyDefinitionEvaluation of PropertyDefinition : PropertyName `:` AssignmentExpression steps 3 and 4 are replaced by 1. Let _isProtoSetter_ be *false*"

[17:05:09.0000] <Bakkot>
or whatever

[17:05:14.0000] <devsnek>
scary

[17:05:25.0000] <devsnek>
hmm

[17:05:36.0000] <jmdyck>
link to PR?

[17:05:40.0000] <devsnek>
what if i added a new definition for  PropertyDefinition : __proto__ : AssignmentExpression

[17:05:40.0000] <Bakkot>
and then in the actual algorithm add a subsequent step which says `1. Note: the above steps are replaced during JSON.parse`

[17:05:46.0000] <devsnek>
i haven't uploaded it yet

[17:05:49.0000] <jmdyck>
k

[17:05:54.0000] <devsnek>
going to in a minute

[17:06:10.0000] <Bakkot>
the "Replaced by" thing is a thing we already do elsewhere

[17:06:12.0000] <Bakkot>
see e.g. https://tc39.es/ecma262/#sec-built-in-function-objects-construct-argumentslist-newtarget

[17:06:31.0000] <Bakkot>
it's one of the things ecmarkup now explicitly supports

[17:06:35.0000] <devsnek>
unfortunate but ok

[17:06:42.0000] <Bakkot>
(well, the reference to steps, anyway)

[17:08:26.0000] <jmdyck>
you maybe don't need an "is replaced by" thing

[17:09:39.0000] <jmdyck>
wait, __proto__ in main spec, but it's still 'normative optional'?

[17:10:32.0000] <devsnek>
yeah

[17:10:49.0000] <jmdyck>
hm, then I should probably wait to see

[17:10:52.0000] <devsnek>
here https://github.com/tc39/ecma262/pull/2125

[17:11:03.0000] <devsnek>
jmdyck: to be clear, the syntax __proto__ is required

[17:11:12.0000] <devsnek>
the accessor __proto__ is optional

[17:13:53.0000] <jmdyck>
inconsistent whether hyphen between '__proto__' and 'is-proto-setter-true'

[17:14:08.0000] <jmdyck>
ref has it, def doesn't

[17:15:13.0000] <jmdyck>
Also, step-ids usually start with "step-". (Not sure if ecmarkup complains if they don't.)

[17:15:29.0000] <jmdyck>
(or is it ecmarkdown)

[17:15:57.0000] <devsnek>
ecmarkuparound

[17:16:42.0000] <jmdyck>
ok, i understand original the question now.

[17:17:35.0000] <devsnek>
idk how i'm going to implement this "replace step" thing in engine262 😢

[17:17:49.0000] <devsnek>
`globalThis.dontproto = 1`

[17:18:00.0000] <jmdyck>
i have a different suggestion

[17:18:13.0000] <devsnek>
sure

[17:18:43.0000] <jmdyck>
it'll take me a while to get the wording

[17:18:49.0000] <devsnek>
no rush

[17:25:16.0000] <jmdyck>
In the alg, start the new code with a step something like: If this |PropertyDefinition| is within a |Script| that is being evaluated for JSON.parse (see "step-json-parse-parse"), then \n Let _isProtoSetter_ be *false*.

[17:25:38.0000] <devsnek>
interesting

[17:26:11.0000] <jmdyck>
there's a sliver of precedent for the wording

[17:26:43.0000] <jmdyck>
https://tc39.es/ecma262/#sec-resolvebinding step 3

[17:26:48.0000] <devsnek>
i hate that

[17:26:54.0000] <jmdyck>
heh

[17:26:56.0000] <devsnek>
we need to get rid of that

[17:28:59.0000] <devsnek>
is there a way to build without the linter

[17:29:14.0000] <Bakkot>
just omit --lint-spec

[17:29:29.0000] <Bakkot>
`npm run build-only` will do it

[17:29:33.0000] <devsnek>
oh ok

[17:30:21.0000] <Bakkot>
next version of ecmarkup will be a little more helpful in telling you the options you want

[17:30:49.0000] <jmdyck>
Well, if you figure out a nice way to "get rid of that", you can apply it my suggestion.

[17:31:03.0000] <devsnek>
i don't have a better suggestion

[17:31:50.0000] <devsnek>
we should make emu-xref self closing

[17:32:15.0000] <jmdyck>
I don't think we can. ad hoc elements can't be.

[17:32:34.0000] <devsnek>
i mean we can emit them with </emu-xref>

[17:32:41.0000] <devsnek>
but in terms of authoring we could make them self closing

[17:32:42.0000] <jmdyck>
or at least, not in html. spec.html doesn't *have* to be html

[17:32:47.0000] <Bakkot>
we use an off-the-shelf HTML parser

[17:32:56.0000] <Bakkot>
don't really want to write my own at the moment

[17:33:39.0000] <jmdyck>
hah, I wrote my own in a few hours when I got tired of the off-the-shelf one.

[17:33:50.0000] <devsnek>
pr it into ecmarkup

[17:34:05.0000] <jmdyck>
it isn't written in js/ts

[17:34:54.0000] <Bakkot>
also it has to either emit the format jsdom expects or we also have to rewrite jsdom

[17:35:00.0000] <Bakkot>
or at least the relevant bits

[17:35:10.0000] <Bakkot>
or write an adapter I guess

[17:35:25.0000] <jmdyck>
my parser's pretty simple, because spec.html uses a very well-behaved subset of html.

[17:35:46.0000] <jmdyck>
but that's all it has to deal with, so why not?

[17:35:52.0000] <devsnek>
sounds like my rewrite of engine262

[17:48:49.0000] <jmdyck>
devsnek: s/Else, If/Else if/

[17:56:49.0000] <jmdyck>
Also, although I agree you don't need that sentence at [id="step-json-parse-parse"] any more, it might still be helpful to readers to point out that this evaluation is special-cased at <step-link>.

[17:58:35.0000] <jmdyck>
Or maybe not. Maybe I prefer it without.

[18:57:45.0000] <DerekNonGeneric>
is anyone able to review (and hopefully merge) my PR to the TC39 site? It fixes UI bug on mobile that is somewhat unsightly https://github.com/tc39/tc39.github.io/pull/206

[18:59:51.0000] <devsnek>
is the spec backwards https://gc.gy/64297783.png

[19:08:56.0000] <devsnek>
fixed it by flipping the alternative parser inside out https://gc.gy/64298329.png

[21:44:23.0000] <devsnek>
mathiasbynens: do you know a good way to map from the unicode property tables in the spec to the unicode-x packages?

[21:44:48.0000] <devsnek>
for example ID_Start/True -> Binary_Property/ID_Start

[21:53:28.0000] <mathiasbynens>
devsnek: https://github.com/mathiasbynens/regexpu-core/blob/b031e2721608f517588a97b06f847f015d65bc6d/rewrite-pattern.js#L43-L55

[21:53:58.0000] <devsnek>
is it literally just that one ternary

[21:54:20.0000] <mathiasbynens>
no, see the surrounding code as well

[21:54:47.0000] <mathiasbynens>
this is to go from source text to the unicode-x packages btw, not from the spec tables necessarily (but i suppose that's what you wanted?)

[21:55:06.0000] <mathiasbynens>
binary properties are always Binary_Property/*

[21:55:37.0000] <devsnek>
well i'm implementing the spec line for line so i end up with the result of UnicodeMatchProperty and UnicodeMatchPropertyValue

[21:55:49.0000] <devsnek>
handleLoneUnicodePropertyNameOrValue looks similar though

[21:56:03.0000] <mathiasbynens>
if there's Foo=Bar then you look for `${unalias('Foo')}/${unalias('Bar')}`

[21:56:26.0000] <mathiasbynens>
else it's `Baz`, which is `General_Category/Baz`

[21:56:42.0000] <devsnek>
or Binary_Property/Baz, right

[21:56:53.0000] <mathiasbynens>
right that's why you handle those first

[22:20:45.0000] <devsnek>
mathiasbynens: seems to be working, thanks 👍🏻

[22:21:11.0000] <mathiasbynens>
devsnek: yay 👍🏻

[22:21:37.0000] <devsnek>
although bundling these sets into engine262 may prove to be a problem

[22:25:47.0000] <Bakkot>
because of size?

[22:25:51.0000] <Bakkot>
just make it a peerdep or whatever

[22:26:05.0000] <devsnek>
well i want to use it in browser too

[22:27:26.0000] <Bakkot>
you can load the peerdep when someone asks for it

[22:29:31.0000] <devsnek>
trying to build it used 6gb of heap and then crashed 🎉

[22:29:41.0000] <Bakkot>
psh

[22:29:52.0000] <devsnek>
how do real engines pack this data

[22:30:07.0000] <Bakkot>
as my undergrad algorithms professor liked to say, algorithms are for people who can't order more RAM

[22:30:12.0000] <rkirsling>
bags of holding?

[22:32:26.0000] <devsnek>
hm i guess its just part of icu

[22:33:21.0000] <Bakkot>
cat /lib/icu | emscripten

[22:33:27.0000] <devsnek>
oh no

[07:47:19.0000] <jackworks>
https://github.com/NiceLabs/proposal-arraybuffer-equals

[07:47:46.0000] <jackworks>
does anyone interested in champion this? 🤔

[11:44:06.0000] <shu>
jackworks: IMO it needs better motivation. a byte-wise comparison of two entire buffers is easy enough to write and doesn't seem very common

[11:46:37.0000] <bradleymeck>
i might also be concerned with concurrent access for shared stuff

[11:48:03.0000] <shu>
i assumed it was for ABs, not SABs

[11:48:09.0000] <shu>
that thing ain't gonna work good for SABs

[11:53:52.0000] <devsnek>
ljharb: https://gc.gy/64358629.png

[11:55:00.0000] <ljharb>
devsnek: lol it’s a start, but I’d really suggest splitting those into a different PR, since i bet it’ll take a bit to workshop that, and to work out Kevin and my disagreement about optionality

[11:55:23.0000] <rkirsling>
how about angled red-and-yellow stripes :P

[11:55:29.0000] <devsnek>
now we're talkin

[11:55:41.0000] <devsnek>
i don't know how to do that but if someone knows how

[11:55:51.0000] <devsnek>
that sidebar being red/yellow stripes would be awesome

[11:56:22.0000] <devsnek>
ljharb: they're in every engine, if the only thing contentious is the note we put on them then i don't think it needs a separate pr

[11:57:26.0000] <ljharb>
i don’t want bad things required if they can be optional instead, even if everyone ships them already.

[11:58:21.0000] <devsnek>
so like

[11:58:27.0000] <devsnek>
would you want to make with statements normative optional

[11:58:34.0000] <devsnek>
in theory

[11:58:42.0000] <bradleymeck>
if the ecosystem can rely on the behavior that cannot be removed from engines for compat reasons, we shouldn't take stances on stylistic choices of which API to use

[11:59:02.0000] <devsnek>
yeah i mean like

[11:59:06.0000] <devsnek>
the spec says the how

[11:59:07.0000] <devsnek>
not the why

[12:02:00.0000] <bradleymeck>
we do take stances on things that break semantic stuff (e.g. document.all typeof and boolean nightmare)

[12:07:34.0000] <ljharb>
devsnek: I’m specifically talking about non-grammar

[12:07:46.0000] <devsnek>
idk what the difference is

[12:08:02.0000] <ljharb>
i can’t use js to delete the grammar

[12:08:15.0000] <devsnek>
i'm not sure what you mean

[12:08:15.0000] <ljharb>
or polyfill it, etc

[12:08:38.0000] <devsnek>
the question is not polyfillability

[12:08:40.0000] <devsnek>
the question is

[12:08:46.0000] <devsnek>
"is this a thing that is in the js language"

[12:08:50.0000] <devsnek>
the reality answer is "yes"

[12:08:50.0000] <ljharb>
I’m saying i see syntax and api as different categories

[12:09:08.0000] <Bakkot>
bradleymeck the stance that we took on document.all was for implementations, not for users

[12:09:11.0000] <ljharb>
and I’m still skeptical that there’s new code that uses defineGetter and friends

[12:09:27.0000] <devsnek>
we don't only support new code

[12:09:30.0000] <devsnek>
1js right?

[12:09:56.0000] <Bakkot>
ljharb I have seen defineGetter incode written within the last six months on web properties

[12:10:01.0000] <bradleymeck>
Bakkot: i'd agree with that statement but we likely wouldn't have said anything about style

[12:10:15.0000] <ljharb>
1js gets invoked arbitrarily. it didn’t make Module and Script unambiguous, E.G.

[12:10:18.0000] <bradleymeck>
the point was document.all semantics are problematic but needed to be explained

[12:10:23.0000] <ljharb>
Bakkot: what for?

[12:10:30.0000] <Bakkot>
ljharb defining a getter?

[12:10:40.0000] <ljharb>
Bakkot: like why couldn’t they rely on the syntax form, or O.dP

[12:10:45.0000] <Bakkot>
they could have but they didn't

[12:10:48.0000] <Bakkot>
welcome to javascript

[12:10:55.0000] <ljharb>
if you’re saying it’s an education problem then that imo supports my position

[12:11:17.0000] <ljharb>
people use bad things until they learn it’s bad. signals in the spec help with that. annex b helps with that

[12:11:37.0000] <Bakkot>
I am saying that __defineGetter__ will be with us forever

[12:11:50.0000] <Bakkot>
and no implementation intending to run existing JS can avoid shipping it

[12:12:00.0000] <Bakkot>
so we should not make it optional

[12:12:31.0000] <Bakkot>
I also disagree with the idea that the spec should be used for this kind of pedagogy. I do not think people who are putting __defineGetter__ in new code are reading the spec.

[12:12:34.0000] <ljharb>
I’m not convinced that’s true.

[12:12:49.0000] <ljharb>
node is trying to remove the proto mutator, for example

[12:13:07.0000] <ljharb>
(and yes, they won’t read the spec, but all the articles they read, if any, will be informed by it)

[12:13:14.0000] <Bakkot>
at the expense of breaking a bunch of code, which they're willing to do

[12:13:31.0000] <ljharb>
and being optional affords them that leeway to experiment

[12:13:37.0000] <devsnek>
to be clear large swaths of the ecosystem stop working when you get rid of __proto__

[12:13:43.0000] <devsnek>
the most downloaded package on npm uses __proto__

[12:14:04.0000] <Bakkot>
they can do that experiment whether or not it is optional

[12:14:09.0000] <ljharb>
no they can’t

[12:14:12.0000] <Bakkot>
yes they can?

[12:14:12.0000] <Bakkot>
what

[12:14:22.0000] <ljharb>
or rather, not without being out of compliance

[12:14:25.0000] <Bakkot>
right

[12:14:26.0000] <Bakkot>
which they can do

[12:14:29.0000] <ljharb>
i have zero cares for an engine that’s out of compliance

[12:14:30.0000] <Bakkot>
with zero cost

[12:14:32.0000] <Bakkot>
well

[12:14:39.0000] <ljharb>
what i care about is that they can experiment while remaining in compliance

[12:14:43.0000] <Bakkot>
tbh your prioritize seem... extremely... bad.

[12:14:49.0000] <ljharb>
how so?

[12:14:55.0000] <devsnek>
backwards

[12:15:05.0000] <Bakkot>
I think we are missing a _lot_ of background assumptions here

[12:15:12.0000] <Bakkot>
like what a spec is for

[12:15:18.0000] <ljharb>
it matters *a lot* to people what the spec says. I’m not saying the spec shouldn’t conform to reality in the general case, ofc

[12:15:55.0000] <devsnek>
fwiw ljharb

[12:16:06.0000] <devsnek>
if we're "experimenting" we aren't worried about compliance

[12:16:09.0000] <ljharb>
but for each place where we change the spec to match reality, we should be evaluating what the *ideal* would be, weighing if reality can change to match it or not, and doing the least bad compromise

[12:16:25.0000] <Bakkot>
sure

[12:16:31.0000] <ljharb>
devsnek: i doubt node would remove something by default that’s required by the spec

[12:16:31.0000] <Bakkot>
reality cannot get rid of __defineGetter__

[12:16:36.0000] <Bakkot>
so, we should match reality

[12:16:41.0000] <devsnek>
ljharb: we deleted Atomics.wake

[12:16:57.0000] <ljharb>
?

[12:17:14.0000] <ljharb>
Bakkot: I’m not sure that’s true. does xs need it, for example?

[12:17:22.0000] <devsnek>
xs has it

[12:17:28.0000] <Bakkot>
ljharb does xs intend to run existing code?

[12:17:31.0000] <ljharb>
Bakkot: “reality” isn’t solely defined by the corpus of existing js code imo

[12:17:42.0000] <Bakkot>
ljharb so like.

[12:17:44.0000] <Bakkot>
backing up a step.

[12:17:47.0000] <ljharb>
k

[12:17:56.0000] <ljharb>
devsnek: not sure what you mean about Atomics.wake

[12:18:18.0000] <devsnek>
node deleted Atomics.wake before it was removed from the spec

[12:18:34.0000] <devsnek>
as part of a semver major cycle

[12:18:38.0000] <ljharb>
why?

[12:18:56.0000] <devsnek>
because reality said it was being changed to notify

[12:19:07.0000] <ljharb>
ok so, anticipating an upcoming change

[12:19:14.0000] <ljharb>
I’m not being super pedantic here about “compliance”

[12:19:29.0000] <devsnek>
although i'm noticing that firefox still has Atomics.wake present

[12:19:30.0000] <ljharb>
if something isn’t expected to be non-required, then i would not expect node to ever remove it by default

[12:20:20.0000] <Bakkot>
ljharb your stance appears to be "I personally would prefer people not use this widely-implemented thing, whose use has no negative security implications, so we should not make it normatively required". I disagree with this entire category of argument.

[12:20:37.0000] <Bakkot>
I do not think that argument is relevant, at all, to whether something should be normatively required.

[12:20:59.0000] <devsnek>
to be clear, we're marking __proto__ optional because of security, not because we dislike it

[12:21:12.0000] <Bakkot>
devsnek right, that's the point of that qualification

[12:21:43.0000] <ljharb>
Bakkot: i think that “would this have ever been in the language if it had gone through a proper design process” is a reasonable question to ask when considering optionality

[12:21:43.0000] <Bakkot>
I am fine with keeping the __proto__ setter normative optional

[12:21:48.0000] <Bakkot>
ljharb why?

[12:22:25.0000] <ljharb>
because history, intention, and design matter when looking at usability and thinking about users?

[12:22:43.0000] <devsnek>
they do, this is why mdn has a big red box at the top of the __defineSetter__ page

[12:22:58.0000] <ljharb>
I don’t think it is appropriate or sufficient to only consider spec versus reality here, I’m concerned about users’ mental models

[12:23:02.0000] <devsnek>
but that doesn't have any bearing on the specifics of how __defineSetter__ is implemented

[12:23:35.0000] <Bakkot>
those things matter when communicating to users which parts of the language they should use, but that is not what we are discussing. we are discussing what things in the spec are optional for implementations.

[12:23:40.0000] <ljharb>
devsnek: and I’m glad we’re retaining that big red box in the spec when moving it out of annex b (making it more explicit, even)

[12:24:07.0000] <ljharb>
Bakkot: i suspect we have different experiences informing how much what the spec says actually matters to inexperienced users

[12:24:17.0000] <devsnek>
i don't think anyone here is against a note saying they suck

[12:24:26.0000] <ljharb>
Bakkot: in my experience, those users don’t read the spec, but they cite it *often* when justifying some decisions

[12:24:41.0000] <ljharb>
Bakkot: often because they saw the citation in a book or blog post

[12:25:09.0000] <ljharb>
if you’ll pardon the term, there is a very objective trickle-down effect that happens from putting discouragements or encouragement in the spec

[12:25:52.0000] <Bakkot>
again, we are discussing which features implementations are permitted to omit, not editorial notes about style preferences

[12:26:19.0000] <ljharb>
currently, anything in annex b “might not be there”, and so that leads people to avoid using them. Not all people, surely, but many.

[12:26:20.0000] <Bakkot>
I am happy to have a separate conversation about whether we should annotate the features in the spec we personally dislike with notes saying that

[12:26:57.0000] <ljharb>
that some of the features are always everywhere doesn’t change the effect.

[12:27:13.0000] <Bakkot>
ljharb those features _will in fact be there_. those people are being _misled_ by the spec's current totally false implication that they might not

[12:27:29.0000] <Bakkot>
I am strongly opposed to this philosophy of lies-to-children as a principle guiding normative decisions about what is in the spec

[12:27:29.0000] <ljharb>
yes, misled to everyone’s benefit

[12:27:44.0000] <ljharb>
not that i want to mislead people

[12:27:49.0000] <ljharb>
but my priority is the outcome

[12:28:30.0000] <devsnek>
i'm not sure what this has to do with the normative requirements of the spec

[12:28:55.0000] <Bakkot>
I am unwilling to lie to people just to get them to stop using a feature I dislike which has no negative security consequences.

[12:29:07.0000] <Bakkot>
I don't think the spec should do so either.

[12:29:18.0000] <Bakkot>
especially since the spec is also used by implementors.

[12:30:45.0000] <devsnek>
the point of the spec is to clearly communicate the requirements of an implementation to someone making an implementation

[12:41:32.0000] <shu>
reading backlog: strong agreement with Bakkot here

[12:42:38.0000] <rkirsling>
yeah, I think that's well-conveyed: it is an implementation guide, not a usage guide

[12:42:54.0000] <shu>
> I am happy to have a separate conversation about whether we should annotate the features in the spec we personally dislike with notes saying that

[12:43:09.0000] <shu>
^ i am not. the answer to that is "no we should not"

[12:54:13.0000] <ljharb>
well yeah, obviously the way Bakkot phrased that none of us would be on board with it, myself included

[12:54:58.0000] <ljharb>
rkirsling: the spec is very much a usage guide as well, whether that's intended or not

[12:55:22.0000] <devsnek>
how is it a usage guide

[12:55:26.0000] <devsnek>
it just says that things exist

[12:55:26.0000] <ljharb>
it's used as one

[12:55:36.0000] <ljharb>
and what arguments they take, and what types/shapes those arguments can take

[12:55:41.0000] <rkirsling>
but if a user grabs the spec, wouldn't it just be to prove that, e.g. "V8 is doing the wrong thing"?

[12:55:50.0000] <shu>
ljharb: link me some examples

[12:55:53.0000] <ljharb>
rkirsling: i'm not saying users grab the spec

[12:56:07.0000] <ljharb>
rkirsling: i'm saying that the things users read are written by people who cite the spec (and nobody looks up the citations)

[12:56:20.0000] <ljharb>
shu: off the top of my head i don't have any, but i will do so when i find some.

[12:56:36.0000] <ljharb>
shu: the majority of my opinion here is from many, many years of helping inexperienced JS programmers on IRC

[12:57:06.0000] <devsnek>
i don't understand what advice can be offered by reading the spec

[12:57:08.0000] <ljharb>
and the increased popularity of transpilation, and "compat tables" and whatnot, mean that average users are much more aware of what's standard and what's not

[12:57:39.0000] <ljharb>
shu: devsnek https://twitter.com/rauschma/status/644511281421111296

[12:57:50.0000] <ljharb>
to name one prominent author.

[12:58:10.0000] <devsnek>
so one time in 2015 some guy misrepresented annex b

[12:58:12.0000] <Bakkot>
I believe that these people exist. I just do not think this fact should guide normative decisions about what is required.

[12:58:13.0000] <ljharb>
https://twitter.com/phoddie/status/1150911833944907776

[12:58:20.0000] <ljharb>
devsnek: it's not a misrepresentation tho

[12:58:29.0000] <ljharb>
devsnek: that is how it's often been talked about in plenary by various delegates.

[12:58:39.0000] <shu>
that's the kind of misconception we're trying to combat by inlining it

[12:58:40.0000] <ljharb>
Bakkot: i think that's a fine discussion to have

[12:58:48.0000] <ljharb>
shu: imo it's not a misconception.

[12:58:55.0000] <shu>
it is a misconception

[12:59:02.0000] <devsnek>
in the tweet you linked

[12:59:14.0000] <devsnek>
XS found that it couldn't be a useful implementation without implementing those annex b things

[12:59:21.0000] <Bakkot>
either we are intending to guide usage, in which case we should the conversation about annotating the features in the spec we personally dislike, or we are not. in neither case is the right outcome that we use this input to guide normative decisions in the spec.

[12:59:41.0000] <ljharb>
in ES5: https://es5.github.io/B.html "This non-normative annex suggests uniform semantics for such properties without making the properties or their semantics part of this standard."

[12:59:50.0000] <Bakkot>
it seem very strange to me to say "I want to guide usage, but I only want to do so by making normative decisions about what's optional, to the detriment of implementors"

[12:59:52.0000] <ljharb>
Bakkot: guiding usage doesn't require "personal" dislike.

[12:59:57.0000] <Bakkot>
ljharb right, that note turned out to be wrong

[13:00:06.0000] <rkirsling>
yeah that's actually a super helpful point toward promoting that handful including __proto__

[13:00:14.0000] <ljharb>
Bakkot: how is it a detriment to implementors for things to be optional?

[13:00:17.0000] <rkirsling>
(that = Peter's tweet)

[13:00:21.0000] <Bakkot>
ljharb because they are in fact not

[13:00:40.0000] <Bakkot>
ljharb if you are writing an implementation, and omit __defineGetter__, your implementation will not be able to run the millions of lines of JS which exist

[13:00:45.0000] <ljharb>
"in fact" depends on what code is run in the implementation

[13:00:54.0000] <ljharb>
not every implementation needs to be able to run "all code in the ecosystem"

[13:01:07.0000] <Bakkot>
not everything needs to be a JS engine at all!

[13:01:13.0000] <Bakkot>
you can be a different language, that's fine

[13:01:15.0000] <Bakkot>
however

[13:01:16.0000] <ljharb>
how much JS code is there that has no browser globals or node modules/require, etc

[13:01:24.0000] <ljharb>
and that also uses these annex b things

[13:02:09.0000] <ljharb>
do you have any defineGetter examples that don't rely on a nonstandard module system, node core modules, browser globals/the DOM, or the ability to have i/o?

[13:02:23.0000] <devsnek>
what does that have to do with anything

[13:02:24.0000] <ljharb>
console.log isn't part of the standard either

[13:02:41.0000] <devsnek>
it probably should be

[13:02:46.0000] <devsnek>
but that's a separate convo

[13:02:49.0000] <ljharb>
devsnek: i'm saying that if the argument is "the spec must have X because everyone defacto has to implement X anyways" only works if the code in question is actually 262-portable

[13:02:56.0000] <ljharb>
if it has `window` in it, it's not

[13:03:00.0000] <ljharb>
eg

[13:03:16.0000] <Bakkot>
fricking _nashorn_ found they had to add __defineGetter__

[13:03:21.0000] <devsnek>
ouch

[13:03:56.0000] <ljharb>
lol fair, but any chance that's because nobody in the ecosystem was writing code for nashorn, and they wanted to be able to ride on the back of the existing ecosystem?

[13:04:05.0000] <shu>
ljharb: i don't understand what point you're trying to make

[13:04:31.0000] <Bakkot>
I am sure they did want to ride on the back of the existing ecosystem, and people's experience writing for it! that is the point of using JS instead of a new language in the first place! that is _why we have a standard_!

[13:04:36.0000] <ljharb>
shu: i mean the underlying point is that i think that things in annex b carry a connotation of being both deprecated and optional, and for API things, i do not want to lose that without careful consideration.

[13:04:41.0000] <devsnek>
"nashorn didn't want to create a new ecosystem they wanted to be part of the existing ecosystem"

[13:04:49.0000] <devsnek>
ugh what bakkot said

[13:05:02.0000] <ljharb>
Bakkot: people like using RN and react because the knowledge transfers even though the code largely does not

[13:05:16.0000] <ljharb>
Bakkot: you don't need to use *any* specific existing code to have it be useful to have a JS engine.

[13:05:39.0000] <ljharb>
(obviously the vast majority would be pretty reusable)

[13:05:58.0000] <ljharb>
but in the RN ecosystem, the packages that are shared between RN and react web are not that plentiful.

[13:06:04.0000] <ljharb>
and it's still useful that RN is javascript

[13:07:17.0000] <devsnek>
hermes, an engine written solely for running reactive native, has __defineSetter__

[13:07:28.0000] <devsnek>
react native*

[13:08:14.0000] <shu>
ljharb: okay. and we're saying your understanding of the connotation is a misconception. arguing here doesn't seem particularly productive because it has mostly been telling of your philosophical disagreement with what a standard ought to do, and what a standards developing organization ought to do, as Bakkot noted earlier

[13:08:26.0000] <ljharb>
hermes has relatively inconsistent support for parts of the standard, altho it's improving, and it's not clear to me which parts they added for parity with jsc (the previous RN engine) or out of necessity from existing RN code.

[13:08:58.0000] <ljharb>
shu: whether it's a misconception is not an objective thing, and i'm not the only one in the committee with it. i agree the philosophical debate isn't likely to be productive.

[13:09:14.0000] <Bakkot>
the philosophical debate is the only relevant debate here

[13:09:42.0000] <devsnek>
i thought at the october meeting we explicitly came to agreement on how annex b didn't imply the things shouldn't exist and that we should try to reconcile them with the main spec

[13:10:09.0000] <shu>
ljharb: not implying having misconceptions it not limited to you, no

[13:10:11.0000] <ljharb>
devsnek: see the notes, one of the bulletpoints is my explicit objection to indiscriminately hoisting API things out of annex b

[13:10:20.0000] <shu>
oops, too many negations there

[13:10:26.0000] <ljharb>
lol i think i know what you meant

[13:10:35.0000] <devsnek>
right there are things in annex b that would break certain requirements we have of the main spec

[13:10:38.0000] <devsnek>
like the regex grammar

[13:10:48.0000] <ljharb>
devsnek: grammar things i'm on board with hoisting up

[13:10:52.0000] <Bakkot>
ljharb the notes do not in fact say that

[13:11:19.0000] <ljharb>
Bakkot: "For non-grammar, the previous consensus holds but we keep in mind JHD’s request that we clearly mark things that we want to deprecate or discourage, perhaps in prose where Annex B once stood"

[13:11:23.0000] <ljharb>
https://github.com/tc39/notes/blob/7b2de881081abd34b02bc87bcdb662fd97555795/meetings/2019-10/october-1.md#conclusionresolution-4

[13:11:26.0000] <Bakkot>
right

[13:11:33.0000] <ljharb>
ie, plenary only discussed grammar

[13:11:36.0000] <Bakkot>
i.e., you want there to be non-normative notes about things being discouraged

[13:11:53.0000] <Bakkot>
this is very different from "my explicit objection to indiscriminately hoisting API things out of annex b"

[13:11:58.0000] <ljharb>
ok

[13:12:10.0000] <ljharb>
we did not explicitly discuss whether inlined api things would remain optional

[13:12:17.0000] <ljharb>
but the implication to me was that most things would remain optional

[13:12:33.0000] <ljharb>
either way the only thing we had consensus for, and the only thing the agenda item was about, was annex b grammar

[13:13:03.0000] <devsnek>
i'm not against things being optional

[13:13:05.0000] <devsnek>
__proto__ is optional

[13:13:11.0000] <devsnek>
but optional requires a good reason

[13:13:50.0000] <Bakkot>
anyway, let me repeat myself above. my stance continues to be: either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we personally dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it.

[13:13:53.0000] <ljharb>
change requires consensus. all things in annex b are already optional.

[13:14:06.0000] <ljharb>
Bakkot: you keep saying "personally" dislike

[13:14:10.0000] <ljharb>
Bakkot: that's a strawman

[13:14:24.0000] <ljharb>
Bakkot: we could annotate things the *committee* dislikes, sure. which we already do.

[13:14:27.0000] <ljharb>
just not everything.

[13:14:28.0000] <Bakkot>
ljharb uh

[13:14:48.0000] <devsnek>
we definitely have not taken a vote on whether we subjectively like __defineGetter__

[13:14:59.0000] <ljharb>
what i mean is, "personally" implies that individuals get to stamp their individual dislike on things

[13:15:04.0000] <ljharb>
which obv is not what anyone would want

[13:15:13.0000] <devsnek>
that seems to be what you've been arguing

[13:15:13.0000] <Bakkot>
ok, s/personally/collectively/, whatever

[13:15:30.0000] <ljharb>
devsnek: then i've done a bad job of expressing my points

[13:15:49.0000] <Bakkot>
my stance continues to be: either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we collectively dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it.

[13:15:57.0000] <ljharb>
everything in annex b is already specifically optional, and "being in annex b" already conveys "deprecated"

[13:16:28.0000] <ljharb>
a PR is editorial if it doesn't change the former (and possibly the latter, but we already seem to have consensus on adding the latter explicitly when inlining). it's normative if it does change the former, and we'd need consensus on that.

[13:16:34.0000] <devsnek>
and we have evidence that for implementations, __defineSetter__ is not actually optional

[13:16:59.0000] <ljharb>
i see no evidence that it being optional has been a detriment, though

[13:17:16.0000] <devsnek>
its detrimental to existence of the spec

[13:17:23.0000] <devsnek>
the spec's reason for existing

[13:17:30.0000] <devsnek>
is to tell implementers what they need to do

[13:17:34.0000] <devsnek>
if it doesn't do that it is failing

[13:17:39.0000] <Bakkot>
it is detrimental to lie to people because we want other people not to use a feature because we think it's stylistically bad

[13:17:50.0000] <ljharb>
and everyone implemented it already, so it seems that the spec making it optional hasn't stopped anyone from doing what they need to do

[13:18:01.0000] <Bakkot>
there continue to be new implementations with surprising frequency

[13:18:15.0000] <shu>
there has also been anecdotes of implementations learning, the hard way, that they have to implement it, like in nashorn and hermes?

[13:18:22.0000] <ljharb>
then there should be lots of examples of where it was a huge inconvenience/disruption for these things to be marked as optional

[13:18:22.0000] <Bakkot>
every time one of those happens those people end up finding out, usually the hard way, that the spec is lying to them

[13:18:42.0000] <ljharb>
shu: "hermes has it" isn't that; nashorn "having to add it" is indeed such an anecdote

[13:18:45.0000] <Bakkot>
ljharb I ran into this _perrsonally_!

[13:18:50.0000] <ljharb>
on?

[13:18:51.0000] <Bakkot>
I maintain a JS engine for my company!

[13:19:05.0000] <Bakkot>
when I wrote it the first time it did not get annex B right because I didn't know it was important!

[13:19:20.0000] <ljharb>
ok, so you built the engine without annex b, and how quickly ran into problems?

[13:19:23.0000] <devsnek>
the reproduction code for the function name issue used __lookupSetter__

[13:19:26.0000] <devsnek>
i couldn't run it in engine262

[13:19:36.0000] <ljharb>
"it wasn't right the first time" is not really a reliable rubric for good code :-p

[13:19:42.0000] <shu>
???

[13:19:51.0000] <Bakkot>
I gotta walk away from this conversation, I'm sorry.

[13:19:52.0000] <devsnek>
that's *the* rubric for the spec

[13:19:58.0000] <shu>
are you directly refusing to acknowledge implementers' lived experience?

[13:20:06.0000] <ljharb>
i mean like, was it exceedingly more difficult to implement annex b because you didn't realize at the beginning that you had to implement it

[13:20:06.0000] <shu>
i am baffled

[13:20:10.0000] <ljharb>
shu: no, i'm trying to understand it

[13:20:16.0000] <shu>
i am seeing no evidence of that

[13:20:25.0000] <ljharb>
shu: so far what i'm hearing is "i didn't know i needed it, so i didn't build it. then i found out, and built it"

[13:20:40.0000] <devsnek>
a bunch of implementers said "this was confusing" and you're saying "lol thats not so bad"

[13:21:11.0000] <ljharb>
devsnek: Bakkot and you have said you found it so, totally. please link me to examples of others?

[13:21:20.0000] <devsnek>
you linked one of xs

[13:21:22.0000] <devsnek>
shu shared the one about nashorn

[13:21:23.0000] <ljharb>
i'm not trying to marginalize those two examples, i'm just trying to understand them

[13:21:37.0000] <ljharb>
the xs one doesn't say anything about confusion

[13:21:37.0000] <shu>
Bakkot shared the one about nashorn, not me

[13:21:44.0000] <ljharb>
it's just a statement of fact about which subset of annex b xs implements

[13:22:08.0000] <shu>
ljharb: the understanding is that you take them at face value, in that one of the central points of a standard is to facilitate ease of entry into the market for newcomers

[13:22:10.0000] <ljharb>
engines make mistakes in implementations all the time, i don't see "i didn't do it right the first time" as evidence of confusion

[13:22:21.0000] <ljharb>
or rather, as strong evidence of it

[13:22:23.0000] <shu>
and here are people trying to enter the market place, and found out the standard did not facilitate that as well as it could have

[13:22:31.0000] <ljharb>
i understand that

[13:22:41.0000] <shu>
it is not for you to dismiss them and say "they didn't do it right the first time"?

[13:22:47.0000] <shu>
because they did -- the standard says it's optional

[13:22:47.0000] <ljharb>
i'm not trying to dismiss anything

[13:22:52.0000] <shu>
but the market says it is not

[13:24:48.0000] <ljharb>
i think that case can be made for individual parts of annex b, but not for all of it as a whole. i'm convinced of it with proto, and i'm not convinced with the defineGetter family.

[13:25:25.0000] <devsnek>
what would it take for you to be convinced

[13:26:08.0000] <ljharb>
that's a reasonable question to ask and i'll try to come up with an answer for it

[13:26:17.0000] <devsnek>
fwiw every non-browser js engine i'm aware of implements __defineGetter__ and co

[13:27:21.0000] <devsnek>
actually i take that back i found one, espruino

[13:28:28.0000] <ljharb>
i would certainly be interested to see examples of code that has been unchanged for long enough that it won't likely ever be updated, uses defineGetter and friends, and isn't part of a website.

[13:28:51.0000] <ljharb>
any new code using it is pretty likely to be easily updated to use defineProperty

[13:29:01.0000] <devsnek>
why should it be updated

[13:29:34.0000] <ljharb>
right now? because it's depending on optional parts of the spec.

[13:30:08.0000] <devsnek>
but every js engine supports it

[13:30:11.0000] <devsnek>
and it has no security issue

[13:30:18.0000] <ljharb>
the spec doesn't mention security issues either

[13:30:35.0000] <devsnek>
right but we change the spec to deal with security issues

[13:30:40.0000] <ljharb>
"every engine supports an optional thing" doesn't make it a safe thing to rely on forever, since it's optional

[13:30:48.0000] <devsnek>
for example SharedArrayBuffer global being optional

[13:31:05.0000] <ljharb>
right, which means that you can never safely write code that depends on it being present

[13:31:08.0000] <devsnek>
normal humans don't care what the spec says, they care if their code runs

[13:31:12.0000] <ljharb>
that such code may exist doesn't force us to make it required

[13:46:18.0000] <Bakkot>
either we are intending to guide style, in which case we should have the conversation about annotating all the features in the spec we collectively dislike, or we are not, in which case it is absurd to say that something should be normative optional because we want people not to use it. normative optionality is not the correct tool to guide style.

[13:47:01.0000] <Bakkot>
we should not lie to implementors about whether they need to implement something in order to run JS as it exists just because we want users not to use a feature. that is contrary to the core purpose of having a standard.

[13:53:19.0000] <devsnek>
+1

[14:44:42.0000] <devsnek>
weakref are merged

[14:44:49.0000] <devsnek>
js is finally good

[14:51:35.0000] <devsnek>
ljharb: "Let agentRecord be the surrounding agent's Agent Record"

[14:51:43.0000] <devsnek>
this seems.... not right?

[14:52:14.0000] <ljharb>
in the weakrefs PR?

[14:52:23.0000] <devsnek>
wait did this add a new thing

[14:52:35.0000] <ljharb>
cc shu/Bakkot re the weakrefs PR ^

[14:52:58.0000] <devsnek>
no i guess it just

[14:53:16.0000] <devsnek>
i guess this isn't wrong

[14:53:20.0000] <devsnek>
unexpected change though

[14:54:04.0000] <shu>
devsnek: why does that seem not right?

[14:54:24.0000] <devsnek>
it seemed not right before i realized there was a refactoring to make it right

[15:04:11.0000] <devsnek>
%WeakRef% and %FinalizationRegistry% aren't in the intrinsics table

[15:06:17.0000] <ljharb>
whoops

[15:06:21.0000] <ljharb>
i'll put up a PR to add them

[15:11:00.0000] <ljharb>
devsnek: https://github.com/tc39/ecma262/pull/2126

[15:13:14.0000] <devsnek>
when did the whole "agent record" thing happen

[15:16:33.0000] <ljharb>
devsnek: https://github.com/tc39/ecma262/pull/522 ?

[15:16:57.0000] <Bakkot>
reminder that https://searchfox.org/ecma262/source/spec.html

[15:18:03.0000] <devsnek>
the hell

[15:18:17.0000] <devsnek>
how did i never notice that agent records are a thing

[15:18:53.0000] <ljharb>
they must have been secret agent records

[15:18:57.0000] <ljharb>
… i'll show myself out

[15:19:16.0000] <devsnek>
wow you made jmdyck leave

[15:27:45.0000] <ljharb>
lol

[15:42:48.0000] <devsnek>
the new native function matcher test takes like 10 minutes to run in engine262

[15:42:49.0000] <devsnek>
big speed


2020-08-08
[18:30:02.0000] <devsnek>
leobalter: does this conflict the change you recently made to ecma262? https://gc.gy/64555178.png

[18:34:08.0000] <devsnek>
ah nvm found the test262 issue

[08:13:26.0000] <devsnek>
test262 is completely missing coverage for setBigUint64


2020-08-10
[19:41:46.0000] <devsnek>
is there a way we could make the website not change position when the window resizes

[19:43:56.0000] <jmdyck>
you mean the online spec?

[19:48:58.0000] <devsnek>
yeah

[19:49:15.0000] <devsnek>
how did you read a message from before you joined

[19:49:21.0000] <devsnek>
oh nvm we have logs

[19:49:27.0000] <jmdyck>
yup

[19:49:41.0000] <devsnek>
every time i resize my browser

[19:49:44.0000] <devsnek>
the spec jumps somewhere random

[19:50:11.0000] <jmdyck>
because it's reflowing the whole spec

[19:50:27.0000] <devsnek>
yeah i get it has to resize everything

[19:50:29.0000] <devsnek>
is this just like

[19:50:32.0000] <devsnek>
an unsolvable problem

[19:50:57.0000] <jmdyck>
I seem to recall reading something about it recently, but I don't remember where.

[19:51:22.0000] <devsnek>
on resize we could ask for whatever element is at the top of the screen

[19:51:29.0000] <devsnek>
and then after resize we could scroll to it

[19:52:27.0000] <Bakkot>
please no js-based scrolling

[19:54:24.0000] <devsnek>
it would only happen on resize

[19:54:38.0000] <devsnek>
to correct the browser's scrolling

[19:55:01.0000] <Bakkot>
don't care, no js-based scrolling

[19:55:08.0000] <Bakkot>
it is never, ever a good experience

[19:55:38.0000] <devsnek>
but this issue is dumb

[19:55:49.0000] <devsnek>
i have to permalink every time i want to resize my browser

[19:56:03.0000] <Bakkot>
open to finding other solutions to it as long as they do not involve scrolling the page using JS

[19:56:31.0000] <devsnek>
if there's a better solution sure

[22:02:19.0000] <ljharb>
+1 to Bakkot, js-based scrolling is terribad

[22:02:35.0000] <ljharb>
seems like a browser UX bug tbh

[04:33:31.0000] <mathiasbynens>
^ https://drafts.csswg.org/css-scroll-anchoring/ is in Chrome 56

[05:55:13.0000] <jmdyck>
Ah, that was it.

[05:56:14.0000] <jmdyck>
https://caniuse.com/#feat=css-overflow-anchor

[06:16:00.0000] <devsnek>
that proposal is in chrome and firefox and both of them scroll to random positions when the viewport size changes

[06:23:54.0000] <jmdyck>
hm, I guess window resize changes `width` of document, which suppresses the effect

[06:25:07.0000] <devsnek>
jmdyck: did you see this https://snek.dev/ecma262-multipage-demo/multipage/

[06:26:06.0000] <jmdyck>
no, hadn't seen that, thanks.

[06:34:54.0000] <jmdyck>
"Note: Suppression triggers exist for compatibility with existing web content that has negative interactions with scroll anchoring due to shifting content in scroll event handlers."

[07:40:36.0000] <mathiasbynens>
devsnek: ooh multipage! nice

[07:40:49.0000] <mathiasbynens>
devsnek: what else is needed for upstreaming this?

[07:41:13.0000] <devsnek>
well i didn't do it with ecmarkup

[07:41:31.0000] <devsnek>
the main issue is the links are rewritten on the client side with js

[07:41:46.0000] <devsnek>
because apparently changing `a.href` in jsdom takes about 100ms

[07:41:54.0000] <mathiasbynens>
yikes

[07:41:56.0000] <devsnek>
times 22000 links is 40 minutes

[07:42:04.0000] <mathiasbynens>
holy fuck what

[07:42:08.0000] <devsnek>
lol

[07:44:52.0000] <devsnek>
i started trying to do this in ecmarkup but there's so much going on in there i wasn't sure where to even start

[08:11:20.0000] <devsnek>
mathiasbynens: i found a hack, `a.setAttribute('href', whatever)` is not deathly slow, no more client side js

[08:14:27.0000] <mathiasbynens>
devsnek: neat! (and also weird that it makes such a big difference)

[08:14:37.0000] <mathiasbynens>
alright so let's upstream this

[08:14:43.0000] <mathiasbynens>
#hype

[09:06:55.0000] <devsnek>
does hermes just segfault on linux now

[09:50:24.0000] <Bakkot>
devsnek: re, doing this in ecmarkup, the place that most of the change would be is in Spec.ts, specifically somewhere around here: https://github.com/tc39/ecmarkup/blob/40d56a311165bb974e75ab50b8803115ee560700/src/Spec.ts#L365-L383

[09:50:40.0000] <devsnek>
yeah found that area

[09:50:51.0000] <devsnek>
mostly idk how to pull useful data out of the biblio

[10:06:11.0000] <devsnek>
is DateFromTime(NaN) defined?

[10:33:08.0000] <shu>
Bakkot: can you tell michaelficarra we got a funny problem with built-in Function#toString for legacy regexp getters

[10:34:01.0000] <shu>
Bakkot: right now SM prints `function $&()` and V8 prints `function get $&()` for RegExp.$&, the legacy "last match" getters

[10:34:03.0000] <shu>
getter*

[10:34:10.0000] <shu>
$& is not a PropertyName

[10:34:17.0000] <devsnek>
we just need to make `$&` a valid propertyname

[10:34:27.0000] <shu>
good luck with that

[10:36:06.0000] <shu>
oh maybe the spec isn't an issue here, just test262

[10:36:25.0000] <shu>
the spec allows for function ["$&"]() i guess?

[10:36:32.0000] <devsnek>
yes

[10:36:39.0000] <devsnek>
so does the test ftr

[10:36:57.0000] <shu>
ah indeed, there's a big complex implementation of native function matcher...

[10:37:03.0000] <shu>
well then

[10:37:06.0000] <shu>
this is... unfortunate

[10:38:02.0000] <devsnek>
does the internet break if you change it to `['$&']`?

[10:39:54.0000] <ljharb>
does it even need the brackets if it has quotes?

[10:40:10.0000] <ljharb>
like how `'foo'() {}` is a valid class method

[10:40:31.0000] <devsnek>
hm you're right

[10:40:39.0000] <devsnek>
i didn't add that to the native function matcher though

[10:40:57.0000] <devsnek>
`if (!eatIdentifier() && eat('[')) { stumbleUntil(']'); }`

[10:43:55.0000] <shu>
devsnek: i doubt it, but why find out

[11:19:48.0000] <bradleymeck>
function ['foo']() {} ... tis ugly

[11:36:39.0000] <ljharb>
in node, `Object.getOwnPropertyDescriptor({ get '$&'() {} }, '$&').get.toString()` prints out `"get '$&'() {}"`

[11:38:44.0000] <devsnek>
graalvm calls it `lastMatch`

[11:45:00.0000] <jmdyck>
devsnek: looks to me like DateFromTime(NaN) is not defined

[11:45:21.0000] <devsnek>
yeah i'm seeing `new Date(NaN).setMonth(whatever)` fail

[11:47:00.0000] <jmdyck>
ditto the infinities

[11:47:39.0000] <leobalter>
I've been seeing notifications for things that might not be yet on Test262

[11:47:55.0000] <leobalter>
please remember to file a bug there, it helps a lot

[11:48:16.0000] <devsnek>
the date thing is tested, i've just always skipped it

[11:52:11.0000] <Bakkot>
devsnek is it just setMonth which is bugged?

[11:52:15.0000] <jmdyck>
so the `new Date(NaN)` part is well-defined, but `setMonth` is making assumptions?

[11:52:18.0000] <Bakkot>
the others look like they all guarrd for NaN first

[11:52:35.0000] <devsnek>
setMonth calls DateFromTime

[11:52:43.0000] <devsnek>
with NaN

[11:53:12.0000] <Bakkot>
by comparison to setFullYear, I think setMonth should guard NaN

[11:53:28.0000] <Bakkot>
though, setUTCMonth has the same thing, hmm

[11:54:03.0000] <Bakkot>
yeah I think the month ops probably need guards

[11:54:14.0000] <jmdyck>
devsnek: that assumes LocalTime(NaN) = NaN, which it might, but it's unclear.

[11:54:19.0000] <Bakkot>
should be able to check if engines act as if the guards are there

[11:54:32.0000] <devsnek>
i wish there was a way to filter coverage by entrypoint

[11:54:58.0000] <devsnek>
i tried collecting coverage for each individual test but nyc oom'd

[11:55:28.0000] <jmdyck>
(new york city is out of memory?)

[11:56:02.0000] <devsnek>
https://github.com/istanbuljs/nyc

[13:53:48.0000] <devsnek>
Bakkot: so i could run this script more or less as it is written on `spec.doc` https://gist.github.com/devsnek/ef84045abae6b53688e497f101c9d2d6

[13:53:55.0000] <devsnek>
but is that ideal?

[14:02:55.0000] <Bakkot>
no, ideally ecmarkup would do it

[14:03:01.0000] <Bakkot>
as part of the build process

[14:08:38.0000] <devsnek>
Bakkot: yeah i mean in build() i would just do a bunch of querySelectors and whatnot on the `this.doc` or whatever

[14:08:46.0000] <Bakkot>
ahh

[14:08:49.0000] <Bakkot>
hmm

[14:09:09.0000] <Bakkot>
not ideal but I'd take it for now

[14:09:33.0000] <Bakkot>
before landing it'll need to be made to support redirecting when you navigate to an anchor on a page such that the anchor actually lives on a different page, though

[14:09:59.0000] <devsnek>
uhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

[14:10:16.0000] <devsnek>
like if you did `sec-intro.html#sec-promise.resolve`?

[14:10:20.0000] <Bakkot>
yup

[14:10:26.0000] <devsnek>
how would that even happen

[14:10:27.0000] <Bakkot>
specifically so that links to don't break when we reorganize stuff

[14:10:37.0000] <devsnek>
hm i guess

[14:10:42.0000] <devsnek>
can add a js script to do that

[14:10:49.0000] <Bakkot>
yeah, it'll need to be js

[14:11:02.0000] <devsnek>
css+html is turing complete

[14:11:02.0000] <Bakkot>
can't reasonably do it in pure HTML since it's a redirect

[14:11:13.0000] <Bakkot>
TC doesn't mean has arbitrary IO capabilities though

[14:11:20.0000] <devsnek>
*yet*

[14:12:33.0000] <Bakkot>
actually I think this might break the `References` thing too, as written

[14:12:40.0000] <Bakkot>
if the reference is in a different section

[14:13:03.0000] <Bakkot>
since I think those links are generated dynamically

[14:13:08.0000] <Bakkot>
but maybe they aren't, I don't know how that works

[14:14:06.0000] <devsnek>
ugh i just realized

[14:14:23.0000] <devsnek>
i would have to clone `this.doc`

[14:24:12.0000] <bradleymeck>
The year is 20XX, a timing side channel was introduced to HTML and now it has arbitrary read capabilities, no secrets are safe. This is the story of a grizzled language, JS, bringing HTML into the world of chaos that is has known all too well... *fade to title card and intro music*

[14:24:43.0000] <bradleymeck>
but yea TC has limitations even in HTML/CSS generally relying on tricks like focus transitions and not automatically running without input

[14:34:22.0000] <Bakkot>
devsnek: fwiw I think it makes sense to hold off on multipage builds until we do the SDO restructuring, since that will change layout significantly and might (not sure yet) change what sections there are

[14:34:43.0000] <Bakkot>
SDO restructuring is currently waiting on fixing math (2007), so that the math PR doesn't have to be rebased

[14:35:03.0000] <Bakkot>
which is blocked on figuring out what math to use for Dates, though I will probably just land it as editorial and assume we get consensus

[14:35:14.0000] <devsnek>
it's all connected

[14:35:19.0000] <devsnek>
I got the redirect script working

[14:35:22.0000] <Bakkot>
nice!

[14:35:30.0000] <devsnek>
like two lines of code

[14:36:31.0000] <Bakkot>
is it just a JSON.stringify + a JSON.parse

[14:38:08.0000] <devsnek>
fetch(links).then(if document.locstion in links document.location = links)

[14:38:20.0000] <devsnek>
behold my pseudocode

[14:38:40.0000] <Bakkot>
just inline the JSON, it can't be that large

[14:39:08.0000] <devsnek>
7.2mb

[14:39:50.0000] <Bakkot>
ok dedup the json first

[14:47:02.0000] <devsnek>
it's unique

[14:48:14.0000] <devsnek>
it's just a map of "#whatever": "page.html#whatever"

[14:48:42.0000] <devsnek>
I guess I could remove the # and not duplicate the fragment but eh

[14:49:58.0000] <Bakkot>
the `page.html` part is heavily duped

[14:50:04.0000] <Bakkot>
you go the other way and reverse it when you load it

[14:50:09.0000] <Bakkot>
page -> whatever

[14:51:41.0000] <devsnek>
page.html: [ids]

[15:51:44.0000] <devsnek>
Bakkot: deployed... https://snek.dev/ecma262-multipage-demo/multipage/#sec-promise.resolve


2020-08-11
[17:08:00.0000] <Bakkot>
devsnek very nice

[17:08:11.0000] <Bakkot>
devsnek you can drop the `_ref_xxxx` ones; those aren't stable anyway

[17:08:28.0000] <Bakkot>
for purposes of redirecting, specifically

[17:08:50.0000] <Bakkot>
also it'll load faster if you ship it as a string and JSON.parse it at runtime

[17:08:58.0000] <devsnek>
yeah I know

[17:09:43.0000] <devsnek>
this whole multipage project is layers of low hanging fruit lol

[17:36:55.0000] <jmdyck>
when github shows a commit diff, and it hides the no-diff chunks, are the "expand" widgets in the left column supposed to make them appear? If so, they're not working for me.

[17:37:08.0000] <Bakkot>
jmdyck yes they are, but they break for large files

[17:37:12.0000] <Bakkot>
including spec.html

[17:37:23.0000] <jmdyck>
hmph

[17:37:26.0000] <Bakkot>
and they break silently: they just go away rather than telling you that they're broken

[17:37:28.0000] <Bakkot>
it's dumb

[17:48:35.0000] <devsnek>
that's github for ya

[20:27:06.0000] <devsnek>
Bakkot: small changes https://github.com/tc39/ecmarkup/pull/237

[20:37:48.0000] <Bakkot>
devsnek is there a reason to do that now instead of when adding multipage support in general?

[20:38:19.0000] <devsnek>
i'm not sure how to get full support done but i know that change has to be made either way

[20:38:37.0000] <Bakkot>
Yeah, just seems weird to add it separately

[10:13:00.0000] <Bakkot>
condolences to mozilla folks re: today's news :(

[10:45:01.0000] <bradleymeck>
have we ever seen a `class Foo { super bar = 1; }` syntax in any proposal?

[10:45:31.0000] <devsnek>
what does that even do

[10:45:48.0000] <Bakkot>
not that I recall

[10:48:12.0000] <bradleymeck>
devsnek: thats a good question

[10:49:46.0000] <bradleymeck>
i can imagine many things personally but 1 in particular is the only thing that makes sense

[10:49:59.0000] <bradleymeck>
but 🤷 was more curious if the space was open

[11:00:23.0000] <Bakkot>
devsnek do you know if discord is blocked in China?

[11:00:29.0000] <Bakkot>
I would expect it to be, on priors

[11:00:42.0000] <Bakkot>
ah, wikipedia says yes

[11:01:09.0000] <devsnek>
i just generally assume everything is blocked in china

[11:02:29.0000] <Bakkot>
freenode wasn't last I looked, IIRC

[11:07:55.0000] <devsnek>
it could be at any point though

[11:27:43.0000] <ljharb>
bradleymeck: never seen the syntax; seems like it'd be invalid in a base class and would mutate a superclass, so i'm not sure what the use case would be

[11:28:31.0000] <bradleymeck>
ljharb: it would mutate the superclass?

[11:30:50.0000] <ljharb>
that's what it suggests to me

[11:32:54.0000] <bradleymeck>
I could see that for `class F { super.x = 1; }` since `super.x` has meaning

[11:37:08.0000] <ljharb>
`super` is what imo has meaning

[11:37:16.0000] <ljharb>
`super()` or `super.whatever` both building off of that meaning

[11:41:48.0000] <bradleymeck>
ljharb: what is the meaning of `super`? since it cannot be directly assigned to a variable?

[11:42:51.0000] <devsnek>
this syntax should not exist

[11:43:05.0000] <bradleymeck>
i'm neutral to the syntax

[11:43:58.0000] <ljharb>
bradleymeck: it refers to the superclass. `super()` invokes the superclass constructor, `super.x()` calls the superclass prototype's `x` method, etc

[11:44:29.0000] <ljharb>
i'd expect `super.x = 1` to *assign* to the superclass's `x` property, and i'd expect `super bar = 1` to define and initialize the superclass' bar property

[14:39:29.0000] <jmdyck>
ljharb: The merge of 1908 undefined sec-validatesharedintegertypedarray, which has been in master for a few years.

[14:44:13.0000] <devsnek>
is undefined a verb

[14:45:50.0000] <TabAtkins>
yes

[14:45:51.0000] <Bakkot>
past participle, technically

[14:45:57.0000] <Bakkot>
though I guess that is a subset of "verb"

[14:46:04.0000] <TabAtkins>
defined is a verb, undefined is a stadnard construction over that

[15:10:14.0000] <ljharb>
jmdyck: the diff has `oldid="sec-validatesharedintegertypedarray"` but maybe only `oldids` is valid?

[15:10:54.0000] <Bakkot>
yeah it's oldids

[15:11:01.0000] <Bakkot>
I have a note to lint this but haven't gotten to it yet :(

[15:12:30.0000] <ljharb>
k, all fixed

[15:40:33.0000] <TabAtkins>
Ah, I should lint that in Bikeshed, since I'm the one who introduced it and then ecmarkup took it too.

[15:45:26.0000] <Bakkot>
my plan is to have an explicit list of the expected attributes (at least for certain tags) and error out if you have any unexpected ones

[15:45:45.0000] <Bakkot>
s/error out/warn/, which will fail the build if you pass `--strict`

[15:46:08.0000] <Bakkot>
(or at least it will once I can convince michael to review https://github.com/tc39/ecmarkup/pull/235 so I can cut a release)

[15:55:20.0000] <ljharb>
sounds like the right plan


2020-08-12
[20:10:45.0000] <devsnek>
ljharb: how does the action in the template work?

[20:10:55.0000] <devsnek>
it runs but nothing happens

[20:10:59.0000] <devsnek>
no gh-pages or whatever

[20:34:11.0000] <devsnek>
cloning agendas with depth 1 takes longer than cloning the entirety of chromium

[20:35:11.0000] <devsnek>
oh i can't even push the commit out cool

[20:35:32.0000] <devsnek>
can someone push out the commit i did to agendas

[21:02:22.0000] <ljharb>
devsnek: huh?

[21:02:38.0000] <ljharb>
devsnek: i'm confused what you want done

[21:02:41.0000] <devsnek>
https://github.com/tc39/agendas/

[21:02:53.0000] <devsnek>
i accidentally committed to master instead of a new branch

[21:03:05.0000] <ljharb>
that's fine tho

[21:03:12.0000] <devsnek>
is it?

[21:03:21.0000] <devsnek>
i thought things had to be prd

[21:03:25.0000] <ljharb>
sure, PRs are only a courtesy notification, and only really important after the deadline

[21:03:33.0000] <ljharb>
if things had to be PRd, branch protection would have stopped you

[21:03:45.0000] <devsnek>
good point

[21:04:04.0000] <ljharb>
(i'd be totally fine to make that a requirement, but in the past, folks have preferred the ability to push directly to master, for things like crossing out completed items, slides/notes edits during plenary, etc)

[21:04:49.0000] <devsnek>
also

[21:04:52.0000] <devsnek>
on the template repo

[21:04:57.0000] <devsnek>
well in repos made from the template repo

[21:05:02.0000] <devsnek>
what does the workflow do

[21:05:24.0000] <devsnek>
it runs and does a green checkmark but there's no gh-pages or anything

[21:05:38.0000] <ljharb>
devsnek: did you follow the instructions in the template readme to turn on gh-pages?

[21:05:46.0000] <ljharb>
(it renders out of the default branch, not gh-pages)

[21:05:58.0000] <ljharb>
step 2 on https://github.com/tc39/template-for-proposals#create-your-proposal-repo

[21:06:08.0000] <devsnek>
ah no i deleted that without reading it like a pro

[21:06:59.0000] <ljharb>
☚(ﾟヮﾟ☚)


2020-08-13
[08:40:11.0000] <bendtherules>
I wish JS had labelled return statement

[08:41:00.0000] <devsnek>
bendtherules: it does

[08:41:18.0000] <bendtherules>
Like reusable return logic (return if something is not correct, but as reusable code)

[08:41:29.0000] <devsnek>
you're saying you wish js had goto

[08:42:35.0000] <bendtherules>
I mean if x is not correct, return from caller itself

[08:42:55.0000] <devsnek>
non-local return?

[08:43:14.0000] <bendtherules>
Say, how engine262 implements returnIfAbrupt

[08:43:31.0000] <devsnek>
non-local return

[08:43:31.0000] <bendtherules>
But without using macros

[08:43:38.0000] <bendtherules>
Yes, i guess

[08:43:40.0000] <devsnek>
yeah in some ways its cool

[08:43:46.0000] <devsnek>
but its kind of a mess imo

[08:44:25.0000] <bendtherules>
Hmm true. If say, return was first-class

[08:44:40.0000] <bendtherules>
I could return a return completion 😂

[08:45:28.0000] <devsnek>
in engine262 they just model exceptions, in real code I'd use throw

[08:46:20.0000] <bendtherules>
Yes, was thinking about throw. Maybe if throw-catch was easier, as a expression

[10:38:35.0000] <Bakkot>
using exceptions for control flow is generally regarded as bad practice

[10:49:01.0000] <Bakkot>
you can always do `ret: { if (!x) break ret; foo(); return all_was_good_; } return all_was_not_good;`

[10:49:05.0000] <Bakkot>
but, uh, don't

[10:49:54.0000] <Bakkot>
(except in a code generator or whatever)

[10:49:55.0000] <bradleymeck>
/me wrote similar code to that... today

[10:50:30.0000] <devsnek>
i have a codemod for inlining functions somewhere

[13:19:28.0000] <devsnek>
Bakkot: ready for review btw https://github.com/tc39/ecmarkup/pull/238


2020-08-14
[10:34:22.0000] <devsnek>
i can just delete this test right? https://gc.gy/65131443.png

[10:43:49.0000] <Bakkot>
devsnek that test looks fine to me?

[10:44:04.0000] <Bakkot>
except the description is weird I guess

[10:44:06.0000] <devsnek>
Bakkot: we already have a test for `delete identifier` in strict mode

[10:44:10.0000] <devsnek>
aside from that test

[10:44:40.0000] <Bakkot>
ah, yeah, it's plausibly redundant I guess

[10:44:48.0000] <Bakkot>
don't see much advantage in deleting it though

[10:45:08.0000] <devsnek>
at the very least it would save future devs about 30 seconds of confusion

[11:29:38.0000] <devsnek>
fuck things are failing

[11:30:16.0000] <devsnek>
oops wrong channe

[11:55:50.0000] <devsnek>
Bakkot: i decided to just always raise early errors for CoverInitializedName, and then clear those errors if its arrow params or an assignment expression

[11:56:31.0000] <Bakkot>
devsnek that's a reasonable approach

[11:56:38.0000] <Bakkot>
saving the errors lets you get the right location information for them

[11:56:45.0000] <Bakkot>
make sure you don't accidentally clear other errors, ofc

[11:57:10.0000] <Bakkot>
`({ x = function(){ let a, a; } }) => {}` or whatever

[11:57:27.0000] <Bakkot>
(I have had that bug)

[11:58:09.0000] <devsnek>
atm i'm just tracking down everywhere in the for statement parser where i need to clear the errors

[12:38:09.0000] <devsnek>
rwaldron: engine262 rewrite is finished, coverage info not stale anymore :D


2020-08-15
[18:25:10.0000] <devsnek>
did we ever determine what the problem with Date.prototype.setMonth is

[18:38:05.0000] <Bakkot>
devsnek I don't think it's specifically a setMonth problem

[18:38:32.0000] <Bakkot>
setMinutes etc also does arithmetic without a NaN guard

[18:38:55.0000] <Bakkot>
setYear guards because it can be used to make an invalid date into a valid one, weirdly enough

[18:39:28.0000] <devsnek>
setMinutes works though

[18:39:51.0000] <Bakkot>
define "works"

[18:40:14.0000] <devsnek>
doesn't have out of range behaviour

[18:40:32.0000] <Bakkot>
yes it does

[18:40:53.0000] <devsnek>
where

[18:40:57.0000] <Bakkot>
`let s be SecFromTime(t);`

[18:41:08.0000] <Bakkot>
secFromTime performs floor

[18:41:12.0000] <Bakkot>
floor is not defined on NaNs

[18:42:31.0000] <devsnek>
ok but like that's just fp math

[18:43:39.0000] <Bakkot>
not sure what you mean by that

[18:43:54.0000] <Bakkot>
the spec explicitly defines "floor", and the definition it gives does not make sense if you give a non-finite value

[18:44:26.0000] <devsnek>
aight

[18:47:32.0000] <Bakkot>
anyway I'm pretty sure all the setX date proto methods except setYear (and its variants) should explicitly guard for NaN right after doing all the (observable) type coercions on the arguments

[18:47:38.0000] <Bakkot>
that matches what engines seem to do, anyway

[18:48:17.0000] <devsnek>
if (isnan) { return new Date(NaN) } ?

[18:48:40.0000] <devsnek>
or return this i guess

[18:48:40.0000] <Bakkot>
not a new date, the current one

[18:48:42.0000] <Bakkot>
yeah

[18:50:24.0000] <Bakkot>
actuallhy NaN

[18:50:27.0000] <Bakkot>
they return NaN

[18:50:34.0000] <Bakkot>
and do not mutate this

[18:52:46.0000] <Bakkot>
you can see the explicit guards in v8: https://github.com/v8/v8/blob/4b9b23521e6fd42373ebbcb20ebe03bf445494f9/src/builtins/builtins-date.cc#L529

[18:54:54.0000] <devsnek>
would you call this normative or editorial

[18:55:44.0000] <Bakkot>
ehhhh editorial probably? in that it is unimplementable as written, by a strict reading, and the intent pretty clearly can't be anything other than this

[18:55:49.0000] <Bakkot>
i.e. "spec bug"

[18:59:49.0000] <devsnek>
https://github.com/tc39/ecma262/pull/2136

[19:00:50.0000] <Bakkot>
thanks!

[19:00:54.0000] <Bakkot>
you have a couple stray ones

[19:00:58.0000] <Bakkot>
the year methods already have the guards

[19:01:02.0000] <Bakkot>
and don't need new ones

[19:01:15.0000] <Bakkot>
(... I think)

[19:02:57.0000] <devsnek>
i believe you are correct

[19:48:02.0000] <ljharb>
these are all checking if the receiver is NaN, what about the provided argument?

[19:48:35.0000] <Bakkot>
those already have guards, at least in the cases I've looked at

[19:48:49.0000] <ljharb>
ah k

[19:48:52.0000] <ljharb>
i'll try to double check

[19:49:30.0000] <ljharb>
would it be simpler to redefine MinFromTime and friends to handle NaN?

[19:50:14.0000] <Bakkot>
ehhh... probably not, I think

[20:05:00.0000] <ljharb>
kk

[20:51:48.0000] <devsnek>
#JustSayDraftGang strikes again https://gc.gy/65168485.png

[08:58:59.0000] <devsnek>
should this test be in annex b? https://gc.gy/65212135.png

[08:59:28.0000] <devsnek>
cuz afaict `\1` is a valid DecimalEscape and that's always allowed

[09:00:53.0000] <devsnek>
well allowed aside from the early error about nCapturingParens

[09:32:25.0000] <Bakkot>
right, I am pretty sure this is a syntax error because of that error

[09:32:47.0000] <Bakkot>
the "It is a Syntax Error if the CapturingGroupNumber of DecimalEscape is larger than NcapturingParens" noe

[09:37:08.0000] <devsnek>
hm maybe the description is just confusing

[14:08:09.0000] <devsnek>
we should deprecate the parser tests repo or merge it into test262 or require it to be updated along with test262 or something

[14:49:12.0000] <Bakkot>
yeah, I haven't had time to maintain it :(


2020-08-16
[19:24:38.0000] <Bakkot>
I have been enjoying Allen's "JavaScript: The First 20 Years" paper

[19:24:40.0000] <Bakkot>
http://www.wirfs-brock.com/allen/posts/866

[19:24:51.0000] <Bakkot>
warning: ~200 pages of JS history

[19:25:17.0000] <devsnek>
definitely a good read

[19:35:51.0000] <Bakkot>
oh hey this bit features my dad

[19:41:57.0000] <devsnek>
lol

[20:09:08.0000] <jmdyck>
Bakkot

[20:09:16.0000] <Bakkot>
jmdyck pong

[20:09:32.0000] <jmdyck>
if I create a PR against caiolima:mathematical-values-fix, can you merge that?

[20:09:56.0000] <Bakkot>
Yup

[20:10:32.0000] <Bakkot>
hm, looks like that PR needs a rebase again; would you prefer I do the rebase before or after your PR?

[20:11:17.0000] <jmdyck>
well, my PR is a button-push away,

[20:11:40.0000] <jmdyck>
so rebase after merging it?

[20:12:35.0000] <Bakkot>
sgtm

[20:12:55.0000] <jmdyck>
or, hm, is that going to mess me up later

[20:13:44.0000] <jmdyck>
probably not, i can always do a rebase --onto.

[20:14:03.0000] <jmdyck>
https://github.com/caiolima/ecma262/pull/9

[20:14:06.0000] <Bakkot>
this one isn't too bad

[20:14:43.0000] <Bakkot>
.... apparently I was mistaken; I can't merge this PR in github even though I have write access to the branch

[20:14:50.0000] <Bakkot>
so I guess I'll do it manually

[20:15:07.0000] <jmdyck>
this isn't nearly everything, it's just an easy first tranche

[20:16:11.0000] <jmdyck>
after these commits, I start fiddling with whether particular aliases are Numbers vs mathematicals

[20:18:50.0000] <jmdyck>
hm, it might be easier for me if you merged in my stuff, then let me fetch it and rebase, then you do the rebase you mentioned.

[20:19:10.0000] <Bakkot>
will do

[20:19:38.0000] <Bakkot>
I'm going to squash these down to a single commit for ease of rebasing, if that's alright

[20:20:00.0000] <Bakkot>
(but thanks for splitting them up iniitially; makes the review easier)

[20:20:05.0000] <jmdyck>
fine with me.

[20:21:27.0000] <Bakkot>
Pushed

[20:22:16.0000] <jmdyck>
ok, let's see...

[20:23:17.0000] <jmdyck>
hmm

[20:25:06.0000] <jmdyck>
I think I have to squash mine too, for the rebase to go smoothly

[20:26:32.0000] <jmdyck>
yup.

[20:31:28.0000] <jmdyck>
ok, done.

[20:32:21.0000] <jmdyck>
so you presumably don't need jmdyck:2007_ed_interim any more

[20:32:52.0000] <jmdyck>
(Bakkot)

[20:33:06.0000] <Bakkot>
nideed

[20:33:13.0000] <Bakkot>
*indeed

[20:34:36.0000] <jmdyck>
closed the PR, deleted the ...interim branch

[20:36:19.0000] <Bakkot>
for the next batch if you'd prefer you are welcome to just push up a branch to your fork and link the top commit here, rather than opening a PR

[20:36:57.0000] <jmdyck>
yeah, sounds like me making a PR doesn't help


2020-08-18
[09:35:12.0000] <ryzokuken>
mfw IsValidTimeZoneName exists in 402 but not IsValidCalendarName

[09:36:02.0000] <ryzokuken>
probably because calendars are handled through BCP 47?

[09:36:20.0000] <ryzokuken>
anywho, I am adding it to the Temporal spec, but we can upstream it if required

[13:54:13.0000] <ryzokuken>
does anyone remember a static method that is an instrinsic?

[13:54:22.0000] <ryzokuken>
intrinsic*

[13:54:38.0000] <ryzokuken>
I can't find any in the spec rn

[13:57:17.0000] <ljharb>
ryzokuken: Promise.all, Promise.resolve

[13:57:35.0000] <ryzokuken>
ljharb: thanks

[13:58:22.0000] <ljharb>
ryzokuken: https://tc39.es/ecma262/#sec-well-known-intrinsic-objects also has Promise.reject

[13:58:24.0000] <ryzokuken>
ljharb: ugh, it was in the list

[13:58:27.0000] <ryzokuken>
yeah

[13:58:35.0000] <ryzokuken>
I didn't look hard enough

[14:07:11.0000] <ryzokuken>
ljharb: funnily, the automatic linking still doesn't work

[14:08:06.0000] <ryzokuken>
aaaa, dfn

[14:08:09.0000] <ryzokuken>
by bad, sorry

[14:08:22.0000] <ljharb>
there's open PRs to fix those

[14:08:23.0000] <ljharb>
but yeah

[14:08:30.0000] <ljharb>
not automatic

[14:08:47.0000] <ryzokuken>
I thought the %s implied dfn lol


2020-08-19
[18:04:24.0000] <jschoi_>
I’m trying to get back to building and editing https://github.com/js-choi/proposal-smart-pipelines/, but I’m getting an error from ecmarkdown about my old spec source code: “expecting ordered list, got ul”. Is there a way to get a location of the error in the spec source?

[18:05:11.0000] <Bakkot>
jschoi_ you can use the version of ecmarkdown on github, which has significantly better error messages: https://github.com/tc39/ecmarkup/

[18:05:27.0000] <jschoi_>
Great, thanks.

[18:05:30.0000] <Bakkot>
especially if you pass --verboose

[18:05:33.0000] <Bakkot>
*--verbose

[18:05:51.0000] <Bakkot>
*ecmarkup, not ecmarkdown, sorry

[18:06:06.0000] <jschoi_>
Thanks, forgot about `--verbose` too. Been a long time.

[18:06:07.0000] <jschoi_>
Verboose…

[18:07:24.0000] <Bakkot>
I guess I should cut a release and update the docs. I'd been holding off because I wanted to address a last case for ecma402, but it's probably worth getting the error messages released

[18:33:49.0000] <Bakkot>
jschoi_: I just published ecmarkup v4.0.0, so you can switch to that one instead of pointing at github

[18:35:23.0000] <jschoi_>
Bakkot: Thank you very much!

[19:21:05.0000] <jmdyck>
oo, github is down

[19:21:33.0000] <Bakkot>
freeeeeeeeedom

[19:22:49.0000] <Bakkot>
aw it's back up

[19:29:25.0000] <rkirsling>
IRCCloud was down earlier too

[02:49:14.0000] <annevk>
Anyone here familiar with the TypeScript community? Is https://github.com/heycam/webidl/issues/60#issuecomment-676033407 intentional?

[02:58:08.0000] <jackworks>
Because there is no observable difference between return undefined or implicitly return

[02:58:24.0000] <jackworks>
Therefore I think it's okay

[02:59:49.0000] <annevk>
Well, but it's not, right? It says there's an error

[03:04:08.0000] <jackworks>
Yeah. But maybe I can find some reason for it. I don't know if it is intentional, the return type annotation means you should return something. If you type it as void you are telling the type system that this function should not have return value or it's return value should be ignored. if you are type at anything else you are telling the type system that you must explicitly return something of type T.

[03:05:25.0000] <jackworks>
Yeah. But maybe I can find some reason for it. I don't know if it is intentional, the return type annotation means you should return something. If you type it as void you are telling the type system that this function should not have return value or it's return value should be ignored. if you are type at anything else you are telling the type system that you must explicitly return something of type T.

[03:16:15.0000] <annevk>
Thanks, if you find out please leave a comment in the above issue or ping me.

[09:41:29.0000] <TabAtkins>
It's not unreasonable for a richer type system to distinguish between "undefined" and the bottom value (what's returned from a "no return value" function).

[09:42:05.0000] <TabAtkins>
JS doesn't draw a distinction there, but I think it's okay for TS to draw such a distinction, at least theoretically. (There may be practical reasons to not do this, I dunno.)

[09:43:21.0000] <TabAtkins>
Basically what JackWorks said - an type that means "you shouldn't use the return value of this function at all" is reasonable to distinguish from "this function can return undefined" in a type system.

[10:30:53.0000] <ljharb>
i agree - also that it doesn't make sense for webidl or JS to distinguish them

[10:52:30.0000] <annevk>
jgraham found https://stackoverflow.com/questions/58885485/why-does-typescript-have-both-void-and-undefined which justifies void for a different reason that seems super reasonable


2020-08-20
[09:50:57.0000] <devsnek>
ToInteger can return Infinity

[09:51:03.0000] <devsnek>
but IsInteger says Infinity is not an integer

[09:51:06.0000] <devsnek>
who is correct

[09:51:55.0000] <devsnek>
this causes a spec assertion to fail when you have `fn.bind()` where `fn.length` is `Infinity`

[09:58:02.0000] <ljharb>
devsnek: the prose description of ToInteger is clearly wrong

[09:58:46.0000] <ljharb>
devsnek: and i do see the spec assertion failing

[09:59:07.0000] <ljharb>
devsnek: so i also think, that since you can set Infinity as a length, that the *assertion* in https://tc39.es/ecma262/#sec-setfunctionlength is wrong

[09:59:24.0000] <ljharb>
iow, length is either a NonNegativeInteger, or, it's ±Infinity

[10:03:40.0000] <Bakkot>
devsnek arithmetic is broken throughout the spec :)

[10:03:46.0000] <Bakkot>
I am working on fixing that one

[10:04:09.0000] <Bakkot>
in-progress branch here, which needs rebasing: https://github.com/tc39/ecma262/tree/fix-math-fix

[10:05:32.0000] <devsnek>
one of the things engine262 can't really catch is reals vs numbers


2020-08-21
[19:08:23.0000] <devsnek>
does test262 cover `for (a = b of whatever) {}`

[19:23:49.0000] <Bakkot>
test262 does not have tests for things which don't match the grammar at all, in most cases

[19:25:16.0000] <Bakkot>
though I guess I did add some for `for (a = b in whatever)`, as part of https://github.com/tc39/ecma262/pull/614

[19:25:23.0000] <devsnek>
seems like a good candidate though

[19:25:42.0000] <devsnek>
given how it has to be implemented

[19:26:14.0000] <Bakkot>
how so?

[19:26:49.0000] <devsnek>
you have to parse as expression and then validate that it's a lhsexpr

[19:57:38.0000] <jmdyck>
Bakkot: could you resolve 2007's merge conflicts again?

[19:57:44.0000] <Bakkot>
jmdyck will do

[19:57:49.0000] <jmdyck>
tx

[21:48:16.0000] <Bakkot>
jmdyck: done

[08:33:48.0000] <gibson042>
lol @ `eshost -se 'Object.defineProperties(function(){}, {length:{value:Infinity}}).bind(null, ...Array.from({length:990})).length'`... we can get 0 from some implementations, Infinity from others, and any integer in [0, 2**53-1] from XS. Reminds me of https://en.wikipedia.org/wiki/Riemann_series_theorem

[08:38:34.0000] <devsnek>
gibson042: and an assertion failure in engine262 :P

[08:38:45.0000] <devsnek>
graal also does the weird number thing

[08:38:55.0000] <jackworks>
Lol

[08:38:59.0000] <devsnek>
https://gc.gy/65729338.png

[08:39:53.0000] <jackworks>
Should make a list "you don't know JS (ub version)"

[08:48:13.0000] <gibson042>
the GraalJS limit is a *fascinating* 0x8000_0000_0000_00C0

[08:50:11.0000] <gibson042>
2**63 + 192

[08:52:00.0000] <devsnek>
in other new, node's value inspect function is broken https://gc.gy/65730112.png

[09:21:12.0000] <gibson042>
`eshost -se 'Object.defineProperties(function(){}, {length:{value:0x8000000000000480}}).bind().length'` is even more hilarious

[09:21:45.0000] <Bakkot>
... huh

[09:26:01.0000] <rwaldron>
Bakkot or ljharb (or anyone interested). I'm trying to resolve a decade old issue, want in?

[09:26:09.0000] <Bakkot>
rwaldron sure, what's up?

[09:26:19.0000] <rwaldron>
undeclared = (this.undeclared = 5);

[09:26:50.0000] <rwaldron>
In the top level global scope, in strict mode, that does what?

[09:28:17.0000] <rwaldron>
I would interpret that to evaluate `this.undeclared` first, then evaluate 5, then assign 5 to this.undeclared. Next, it would evaluate `undeclared` (which is now not-so-undeclared) then evaluate the rhs of = and assign it to `undeclared`

[09:28:17.0000] <devsnek>
rwaldron: the spec throws a reference error, most impls don't

[09:28:57.0000] <Bakkot>
we just landed a tweak to the other side of this: https://github.com/tc39/ecma262/pull/2094

[09:28:58.0000] <rwaldron>
I think the implementations interpret it the way I have, with some assumption about the innermost assignment expression gets to go first

[09:29:01.0000] <devsnek>
in particular because the lhs `undeclared` it resolved to Reference { env: undefined, name: 'undeclared' }` before the rhs is evaluated

[09:29:35.0000] <Bakkot>
but yeah my reading agrees with devsnek

[09:29:39.0000] <Bakkot>
see also https://github.com/tc39/ecma262/issues/467

[09:30:01.0000] <rwaldron>
devsnek that certainly makes more sense.

[09:30:41.0000] <rwaldron>
Bakkot lol, one in the same.

[09:30:49.0000] <rwaldron>
I started here: https://github.com/tc39/test262/issues/1964

[09:31:00.0000] <rwaldron>
Cool. I'm going to ship a test for this.

[09:31:03.0000] <rwaldron>
Thanks!

[09:31:41.0000] <devsnek>
will the test say all the impls are wrong

[09:31:43.0000] <rwaldron>
This was how I mapped it for test writing purposes

[09:31:47.0000] <rwaldron>
    Let rval be ? GetValue(rref).

[09:31:47.0000] <rwaldron>
    GetValue(V)

[09:31:47.0000] <rwaldron>
    If IsUnresolvableReference(V) is true, throw a ReferenceError exception.

[09:31:53.0000] <rwaldron>
devsnek yep

[09:32:46.0000] <devsnek>
well except quickjs and engine262

[09:32:51.0000] <devsnek>
fun stuff

[09:33:26.0000] <Bakkot>
since web engines all agree, probably we should fix the spec for this one...

[09:33:29.0000] <devsnek>
i feel like the time we spend discussing stuff is inversely proportional to how much it gets used in the real world

[09:33:46.0000] <Bakkot>
the spec is plausibly web-incompat

[09:33:56.0000] <rwaldron>
Aha, sure enough: engine262

[09:33:56.0000] <rwaldron>
test262-harness --hostArgs='--features=all' --hostType=engine262 --hostPath=/usr/local/bin/engine262 test/language/identifier-resolution/assign-to-global-undefined.js

[09:33:56.0000] <rwaldron>
Ran 1 tests

[09:33:56.0000] <rwaldron>
1 passed

[09:33:56.0000] <rwaldron>
0 failed

[09:34:00.0000] <rwaldron>
Nice one

[09:34:23.0000] <Bakkot>
I could easily see someone doing something like `x = function(){ / *...* /; window.x = foo; }()`

[09:34:23.0000] <devsnek>
this seems difficult to fi

[09:34:25.0000] <devsnek>
fix*

[09:34:44.0000] <Bakkot>
nah, it's pretty straightforward I think

[09:35:02.0000] <Bakkot>
currently: `If IsUnresolvableReference(V) is true, then: If IsStrictReference(V) is true, then: Throw a ReferenceError exception.`

[09:35:02.0000] <rwaldron>
Bakkot I agree that we should fix the spec, but we should have a test that demonstrates the current expected behavior, then we have something to change test wise when the spec change is in agreement

[09:35:14.0000] <devsnek>
this is only strict mode though

[09:35:16.0000] <Bakkot>
rwaldron yeah for sure, I am happy you are adding a test

[09:35:20.0000] <rwaldron>
Rad.

[09:35:29.0000] <devsnek>
does `x = function(){ window.x = foo }()` exist in strict mode

[09:36:16.0000] <Bakkot>
devsnek part of the reason I expect it to is, babel's old `let` transform didn't implement TDZ and some major library ran into ~this error because of it

[09:36:43.0000] <devsnek>
😢

[09:36:43.0000] <Bakkot>
where they had `let x = function(){ /* ... */ if (!x) x = 2 }()` or similar

[09:37:01.0000] <Bakkot>
which works with a non-TDZ transform, breaks if you implement TDZ properly

[09:38:33.0000] <Bakkot>
devsnek anyway, for the fix, I think you just put a step after `IsStrictReference` where you also require it to not currently be a property of the global object

[09:38:47.0000] <devsnek>
sounds like an observable check

[09:39:17.0000] <Bakkot>
only in hosts for which the global object has observable property-existence checks, which is not typical

[09:39:44.0000] <devsnek>
i think node might in vm contexts lol

[09:39:45.0000] <bradleymeck>
/me stares at Node

[09:39:54.0000] <Bakkot>
lol

[09:39:55.0000] <bradleymeck>
you don't even need vm to see it

[09:40:02.0000] <Bakkot>
does node currently observe the check?

[09:40:03.0000] <bradleymeck>
you can do... special things

[09:40:32.0000] <devsnek>
https://gc.gy/65733031.png

[09:41:37.0000] <Bakkot>
in such a context, what does `x = (x = 5);` do

[09:42:11.0000] <devsnek>
in strict mode?

[09:42:28.0000] <Bakkot>
yeah

[09:42:34.0000] <devsnek>
throws lmao

[09:42:34.0000] <devsnek>
https://gc.gy/65733151.png

[09:42:45.0000] <devsnek>
this is so cursed

[09:43:00.0000] <devsnek>
oh wait i meant to do this.x

[09:43:08.0000] <Bakkot>
ah, my bad, yes

[09:43:09.0000] <devsnek>
yeah ok doesn't throw

[09:43:15.0000] <devsnek>
we are safe for now

[09:43:21.0000] <Bakkot>
what if the check is observable?

[09:43:41.0000] <devsnek>
has own property on the global object in there calls get on the context object

[09:43:43.0000] <devsnek>
for legacy v8 reasons

[09:45:05.0000] <devsnek>
i guess the real question is if anyone would really care

[09:45:43.0000] <bradleymeck>
Bakkot: does it need to be an "own" check or can it be on the proto?

[09:45:51.0000] <Bakkot>
engines are unlikely to want to add overhead unless the overhead only applies in this obscure case

[09:46:20.0000] <Bakkot>
bradleymeck hard to say because in most engines you cannot redefine the proto of the global object, I think

[09:46:20.0000] <devsnek>
yeah i think it only applies when you create a v8 global object using the v8 weird legacy c++ proxy thing

[09:46:46.0000] <bradleymeck>
Bakkot: nah, you can but not the global proxy in the web*

[09:47:19.0000] <Bakkot>
bleh

[09:47:21.0000] <Bakkot>
dunno, then

[09:48:25.0000] <bradleymeck>
it doesn't throw if it is on the proto

[09:48:49.0000] <bradleymeck>
to be clear `'use strict'; global.x = (x = 5)` should work right?

[09:48:59.0000] <devsnek>
no

[09:49:04.0000] <devsnek>
`x = 5` will throw

[09:50:35.0000] <Bakkot>
'use strict'; let proto = {}; Object.setPrototypeOf(this, proto); x = (this.x = 0); y = (proto.y = 0);

[09:50:37.0000] <Bakkot>
chakra: works

[09:50:44.0000] <Bakkot>
JSC/SM: can't set proto of global

[09:50:55.0000] <Bakkot>
V8: ReferenceError: y is not defined

[09:51:01.0000] <Bakkot>
NB _y_, not x

[09:51:01.0000] <bradleymeck>
it throws normally on the global in node / a data prop on the global, but not if there is a proto setter

[09:51:26.0000] <bradleymeck>
data prop on the global proto*

[09:51:55.0000] <Bakkot>
bradleymeck so it looks like the answer to your question is, it really is just a check of the global, not its proto

[09:52:02.0000] <Bakkot>
in V8

[09:52:09.0000] <Bakkot>
but not in chakra

[09:52:20.0000] <Bakkot>
and the question is not posable in SM/JSC

[11:18:14.0000] <devsnek>
wow there are exactly 71000 tests (not including annex b and intl)

[11:21:05.0000] <leobalter>
let's freeze test262

[11:21:24.0000] <leobalter>
and hold PRs until we get the next round number

[11:21:39.0000] <leobalter>
maybe open an exception if it's a prime

[11:27:28.0000] <devsnek>
lol

[11:29:31.0000] <ljharb>
leobalter: as long as the next PR adds 17 tests it's cool

[11:30:12.0000] <devsnek>
or 117, 217, 317, etc

[11:33:55.0000] <ljharb>
palindrome-driven development


2020-08-22
[09:22:17.0000] <devsnek>
i don't have the fortitude to make multipage good enough to be in ecmarkup so i made a hacky github actions cronjob instead https://snek.dev/ecma262-multipage/

[09:42:40.0000] <Bakkot>
devsnek I can take over the PR if you want

[09:42:45.0000] <Bakkot>
can't promise I'll get to it right away

[09:55:44.0000] <devsnek>
Bakkot: if you want to I won't stop you lol

[10:11:07.0000] <devsnek>
font size of productions on mobile is a bit small https://usercontent.irccloud-cdn.com/file/vGz4BoQ8/Screenshot_20200822-121040.jpg

[10:11:20.0000] <devsnek>
might fix in a bit

[11:37:32.0000] <jmdyck>
except that "[empty]", woo.

[13:23:59.0000] <Bakkot>
jmdyck: hopefully going to work on 2007 soon. if you have a branch you've been working on, can you link it so I can start there and minimize conflicts?

[13:24:51.0000] <jmdyck>
Bakkot: I'll see if I can make sense of what I have

[13:32:52.0000] <Bakkot>
thanks!

[13:59:50.0000] <jmdyck>
Bakkot: (when you see the commits) when I say "make <some quantity> mathematical", you'll often find that the quantity isn't actually being treated consistently.

[14:01:43.0000] <jmdyck>
a better msg might be "<some quantity> is sometimes treated as a Number, sometimes as a mathematical, sometimes it's unclear. Treat it consistently as a mathematical".

[14:02:10.0000] <jmdyck>
but I'm not going to bother being that careful w msgs

[14:02:37.0000] <jmdyck>
(given that these will prob all get squashed in anyhow)

[14:03:06.0000] <jmdyck>
but I *am* separating things out for ease of review.

[14:09:46.0000] <Bakkot>
noted

[14:16:43.0000] <Bakkot>
rwaldron: re numeric separators, as the PR is currently written it allows numeric separators in numerics which appear in regexes: for example `/a{0,1_0}/u` becomes legal. that seems like it is probably not intentional. can you confirm?

[14:50:03.0000] <jmdyck>
Bakkot: not done yet, but I'm going to push what I have so far

[14:51:35.0000] <jmdyck>
https://github.com/jmdyck/ecma262/tree/2007_ed

[14:53:26.0000] <jmdyck>
note that it's based on 2007, which has fallen behind master again.

[14:54:35.0000] <jmdyck>
If you can avoid rebasing to master until after I've finished (prob some time tonight), that'll probably save me some grief

[15:01:32.0000] <Bakkot>
fantastic, thanks


2020-08-23
[19:49:00.0000] <jmdyck>
Bakkot: I'm approaching the end of my 2007 edits

[19:55:22.0000] <Bakkot>
jmdyck sweet. push to your branch when you are, and I'll review and pull them in before I do further work, yes?

[19:55:31.0000] <Bakkot>
*when you are done

[19:55:41.0000] <jmdyck>
ok

[19:55:52.0000] <Bakkot>
and then I'll rebase the result on master

[20:57:34.0000] <jmdyck>
Bakkot: ok, pushed.

[20:59:08.0000] <jmdyck>
It's not an attempt to be thorough (although each commit should be thorough in what it's doing), it's just where I'm stopping.

[21:01:57.0000] <jmdyck>
My goal was to use mathematical values (mainly non-neg integers) rather than Numbers as much as possible.

[21:04:06.0000] <jmdyck>
Generally, this also results in fewer math<->Number conversions.

[21:09:39.0000] <jmdyck>
I think I occasionally spelled "nonnegative" as "non-negative", which looks better to me but isn't spec style.

[21:10:30.0000] <jmdyck>
(didn't want to change the ones I'd already pushed)

[21:13:42.0000] <jmdyck>
I deleted some `Assert: ! IsNonNegativeInteger(_x_) is *true*.` when I changed _x_ from Number to math'al. I could have changed them to `Assert: _x_ is a nonnegative integer.`, but I already said that in the preamble.

[21:15:43.0000] <jmdyck>
I didn't touch anything in the Date mess, I think.

[21:21:38.0000] <jmdyck>
There are a lot of occurrences of `the mathematical value of ? ToInteger(_x_)` which are dubious, because ToInteger can return infinities, and 'the mathematical value' is only defined on finite values

[21:22:38.0000] <jmdyck>
Similarly `Let _i_ be ? ToInteger(_x_); ... R(_i_)` without an intervening check for infinities

[21:25:02.0000] <Bakkot>
yeah, I have an in-progress fix for that

[21:44:10.0000] <Bakkot>
https://github.com/tc39/ecma262/commit/3c869bd096661100e766684ec00513fcda455fb9

[21:44:20.0000] <Bakkot>
^ is the in-progress fix

[21:44:27.0000] <Bakkot>
(also includes some other stuff)

[21:53:50.0000] <jmdyck>
Oh, also, I changed the return type of some ops to be mathematical when they also can return abrupt completions, which means they supposedly are returning the math value in the [[Value]] of a Normal completion, which is supposedly not allowed. It's ok as far as I'm concerned, but you might want to do something different.

[21:56:24.0000] <jmdyck>
(ok with me because normal completions are unnecessary: https://github.com/tc39/ecma262/issues/497)

[22:08:53.0000] <Bakkot>
jmdyck I am fine with normal-completion-of mathematical values, as long as the same operation cannot also return normal-completion-of Numbers

[22:09:16.0000] <Bakkot>
there are already places where normal completions hold non-ECMAScript values, so whatever

[22:09:45.0000] <Bakkot>
fixing completioons is next up after this and the SDO restructure


2020-08-24
[08:00:32.0000] <jorendorff>
shu: ljharb: I just realized I don't know how to join this await.ops call. Got a link?

[08:02:15.0000] <jackworks>
+1

[08:03:18.0000] <mpcsh>
I saw a google meet link on the reflector but nobody's letting me in

[08:03:36.0000] <mpcsh>
https://github.com/tc39/Reflector/issues/315

[08:04:56.0000] <jorendorff>
Great, I found it and am now in the same holding pattern

[08:05:01.0000] <jorendorff>
Thanks mpcsh

[08:07:13.0000] <jackworks>
I'm stuck on "Asking to join" 👀

[08:09:38.0000] <jorendorff>
I think we are all waiting for shu to show up with the keys to the room.

[08:10:11.0000] <shu>
oh man i apologize totally lost track of time

[08:10:13.0000] <shu>
omw

[09:34:33.0000] <ljharb>
jackworks: sorry i couldn't make it, i look forward to reading the notes


2020-08-25
[10:13:37.0000] <howdoi>
in the spec text, what are `« kValue, k, O »` termed as?

[10:25:59.0000] <howdoi>
just `argumentsList` ?

[10:51:50.0000] <bradleymeck>
howdoi: thats a list, https://tc39.es/ecma262/#sec-list-and-record-specification-type

[10:53:21.0000] <howdoi>
bradleymeck: got it, thanks!

[10:53:31.0000] <howdoi>
> For notational convenience within this specification, a literal syntax can be used to express a new List value


2020-08-26
[04:41:30.0000] <bendtherules>
^ Now that there's a Record proposal, can it get little confusing between Record lang type and spec type?

[06:34:40.0000] <bradleymeck>
bendtherules: yes

[06:42:50.0000] <devsnek>
test262-harness says i'm failing some comment tests

[06:42:57.0000] <devsnek>
but my runner says i'm not

[06:43:16.0000] <devsnek>
why must life be this way

[07:31:50.0000] <ljharb>
bendtherules: we'd have to rename the spec type

[07:40:04.0000] <bendtherules>
@ljharb: yeah, makes sense. Would it be better to prefix all spec types with something, so that there is less chance of collision later?

[07:40:23.0000] <ljharb>
that seems like a lot of extra boilerplate for something that almost never happens

[07:40:47.0000] <ljharb>
considering that the next time it happens we'd just rename the spec type again

[07:41:55.0000] <bendtherules>
Ok. List sounds like a upcoming proposal to me 😀

[08:31:01.0000] <devsnek>
ljharb: realms

[08:32:54.0000] <devsnek>
we should just prefix them all with Abstract

[08:33:14.0000] <devsnek>
unless that's confusing with abstract module records

[09:12:54.0000] <ljharb>
devsnek: that assumes we wouldn’t just expose the spec realms

[09:13:08.0000] <devsnek>
unsure what you mean

[09:13:30.0000] <devsnek>
like define the spec in terms of `let realm be ? Construct(%Realm%)`?

[09:15:04.0000] <bradleymeck>
need a realm to get %Realm%

[09:15:57.0000] <devsnek>
yeah that's the direction i was heading lol

[09:16:11.0000] <ljharb>
I’m saying the only conflict is if the spec X is different than the JS X

[09:16:45.0000] <ljharb>
the spec doesn’t need the constructor

[09:16:48.0000] <devsnek>
i mean even if Realm records and Realm objects serve similar purposes

[09:16:55.0000] <devsnek>
they are different things

[09:18:05.0000] <ljharb>
true

[16:26:24.0000] <devsnek>
bradleymeck: you could do `\uD800*default*`

[16:26:32.0000] <devsnek>
:P

[16:41:42.0000] <bradleymeck>
My eyes

[16:49:46.0000] <devsnek>
how come all the engines use "not defined" for tdz variables

[16:50:54.0000] <devsnek>
ignore that i'm actually just crazy

[16:52:26.0000] <devsnek>
seems fine https://gc.gy/66190924.png

[16:58:17.0000] <devsnek>
i just realized that this will collide with v8's longstanding practice of using secret variables that begin with a period


2020-08-27
[19:41:42.0000] <bradleymeck>
devsnek: what will? the arbitrary namespaces PR never gets into bindings themselves just names

[19:57:14.0000] <devsnek>
bradleymeck: it has the same problem the spec has

[19:57:37.0000] <devsnek>
`.default` instead of `*default*` but same class of problem

[07:18:44.0000] <bradleymeck>
are async stack traces standardization part of some proposal?

[07:27:26.0000] <ljharb>
no, but it’s possible they’ll have to be considered in the stacks proposal

[10:19:48.0000] <devsnek>
anyone interested in a .mailmap for ecma262?

[11:12:11.0000] <ljharb>
devsnek: not sure what you mean, if we have mappings to do we can certainly add one

[11:13:01.0000] <devsnek>
i mean we definitely do

[11:13:16.0000] <devsnek>
i came up with this https://gc.gy/66256991.png

[11:14:08.0000] <ljharb>
devsnek: wait tho, github does most of these

[11:14:19.0000] <ljharb>
are you saying these are commits that github doesn't attach to the right account?

[11:14:33.0000] <devsnek>
i would imagine github is able to use accounts to figure it out

[11:14:46.0000] <devsnek>
but `git log` would need that map

[11:15:21.0000] <ljharb>
ah. i guess we could? seems like we'd want CI to be able to autogenerate it with the github api tho, so we didn't have to manually keep it in sync

[11:15:42.0000] <ljharb>
altho in that case it'd probably be better not to commit it at all, and just let folks run the command locally if they want to use it (because i don't think git uses a mailmap by default?)

[11:16:25.0000] <devsnek>
it uses it by default

[11:16:36.0000] <ljharb>
ah, since whne?

[11:16:42.0000] <devsnek>
idk

[11:16:45.0000] <devsnek>
before i started using git

[11:17:59.0000] <ljharb>
https://stackoverflow.com/questions/13777171/configuring-git-log-to-use-mailmap-by-default#:~:text=The%20default%20mailmap%2C%20located%20in,outside%20of%20the%20repository%20itself.

[11:18:11.0000] <ljharb>
according to that it's off by default

[11:18:21.0000] <Bakkot>
"True by default"

[11:18:31.0000] <ljharb>
ah ok, missed that

[11:18:37.0000] <Bakkot>
https://git-scm.com/docs/git-config#Documentation/git-config.txt-logmailmap

[11:18:40.0000] <ljharb>
thanks

[11:20:13.0000] <ljharb>
i still wonder when that changed; last time i looked into using a mailmap file it was not enabled by default, so i bailed on it

[11:23:18.0000] <devsnek>
is there anything in the spec that has a [[Construct]] but not a [[Call]]

[11:23:57.0000] <devsnek>
i'm thinking no

[11:24:29.0000] <bradleymeck>
> Every object that supports [[Construct]] must support [[Call]]

[11:24:42.0000] <devsnek>
sad

[11:30:08.0000] <ljharb>
i agree it's sad

[11:30:25.0000] <ljharb>
i'd love to refactor so that things could have Construct but not Call

[11:30:39.0000] <ljharb>
it'd require some nastiness in Proxy, and typeof function would have to check either slot

[11:32:23.0000] <devsnek>
luckily i already have a "ConstructorNonCallable" exception for symbol and map and whatnot

[11:33:10.0000] <bradleymeck>
ljharb: both Call() and Construct() check that they have the appropriate internal slot separately though at least idk what you need to do in proxy

[11:33:36.0000] <devsnek>
proxy needs a two line change

[11:33:45.0000] <devsnek>
specifically the removal of indentation

[11:34:08.0000] <ljharb>
it'd also be observable if Proxy threw when you provided `construct` to a callable non-constructible thing, or `apply` to a constructible non-callable thing

[11:34:35.0000] <ljharb>
but i haven't really looked into it

[11:36:34.0000] <bradleymeck>
ljharb: right now proxy doesn't throw if you add handlers that aren't going to be used (e.g. `new Proxy({}, {apply() {}})()` works)

[11:37:25.0000] <ljharb>
wait what

[11:37:41.0000] <ljharb>
why did i think it did

[11:39:10.0000] <ljharb>
ah ok nvm

[11:46:47.0000] <Bakkot>
it can't since it doesn't even read the handlers until you try to invoke the relevant trap

[11:51:17.0000] <devsnek>
i wish there was a way to invoke a constructor on an instance

[12:19:12.0000] <bradleymeck>
devsnek: what does that mean

[12:19:57.0000] <devsnek>
bradleymeck: for example invoke Map on an object to turn that object into a Map

[12:20:17.0000] <ljharb>
you can if the constructor takes an object

[12:20:18.0000] <bradleymeck>
create a new map?

[12:20:26.0000] <ljharb>
`new Map(Object.fromEntries(obj))` tho :-p

[12:20:34.0000] <devsnek>
like if you already have an instance

[12:20:48.0000] <devsnek>
the need doesn't fit our object model works

[12:20:50.0000] <devsnek>
there's no solution

[12:21:06.0000] <bradleymeck>
so same identity/ref but swapping out the structure

[12:22:10.0000] <devsnek>
yea

[12:25:19.0000] <devsnek>
does @@hasInstance of Function.prototype actually do anything?

[12:31:19.0000] <bradleymeck>
devsnek: isn't that what makes instanceof work for Function constructors?

[12:33:09.0000] <devsnek>
InstanceofOperator -> OrdinaryHasInstance(target, V)

[12:33:18.0000] <devsnek>
@@hasInstance -> OrdinaryHasInstance(this, V)

[12:34:09.0000] <devsnek>
i could be reading this wrong but isn't this the same

[12:34:58.0000] <ljharb>
not sure what you mean

[12:35:29.0000] <devsnek>
would the behaviour of js change at all

[12:35:37.0000] <devsnek>
if Function.prototype[@@hasInstance] was removed

[12:35:48.0000] <ljharb>
i don't think so

[12:35:50.0000] <ljharb>
but you can override it.

[12:35:58.0000] <ljharb>
`Object.defineProperty(Function, Symbol.hasInstance, { value: () => false }); Function instanceof Function // false`

[12:36:12.0000] <devsnek>
i was just trying to figure out why it exists

[12:36:14.0000] <ljharb>
most of the symbol protocols have identical fallbacks

[12:36:16.0000] <devsnek>
maybe in past editions it did more stuff

[12:36:20.0000] <ljharb>
it exists so non-builtins can opt into the protocol

[12:36:26.0000] <ljharb>
it's defined on builtins for consistnecy

[12:38:09.0000] <devsnek>
i see


2020-08-28
[14:06:49.0000] <rwaldron>
Bakkot sorry, I've been on vacation (still am). To answer your question: I don't believe that was intentional.

[14:07:04.0000] <rwaldron>
(back to vacation)

[14:09:36.0000] <Bakkot>
rwaldron: sweet, thanks! enjoy vacation

[14:26:29.0000] <keith_miller>
Can someone explain what the point of the invariants on Proxy object's [[Get]] are? Seems like they are kinda unnecessary, what do they actually prevent?

[14:29:30.0000] <devsnek>
i'm not 100% sure why those invariants exist in the spec but they aren't specific to proxies

[14:29:36.0000] <devsnek>
everything has to abide by them

[14:36:49.0000] <ljharb>
keith_miller: which invariants?

[14:37:11.0000] <keith_miller>
The value reported for a property must be the same as the value of the corresponding target object property if the target object property is a non-writable, non-configurable own data property.

[14:37:22.0000] <keith_miller>
The value reported for a property must be undefined if the corresponding target object property is a non-configurable own accessor property that has undefined as its [[Get]] attribute.

[14:37:44.0000] <keith_miller>
devsnek: Seems silly because I could just use a different target that doesn't have any own properties.

[14:37:59.0000] <devsnek>
i agree they are definitely annoying

[14:38:06.0000] <Bakkot>
keith_miller they are useful in combination with  the GetOwnProperty invariants

[14:38:38.0000] <keith_miller>
Bakkot: how so?

[14:38:51.0000] <Bakkot>
in combination with the GetOwnProperty invariants, they prevent you from observing the sequence "let { value, writable, configurable} = Object.getOwnPropertyDescriptor(p, 'prop'); !writable && !configurable /* true */; !Object.is(p.prop, value)`

[14:39:28.0000] <Bakkot>
the GetOwnProperty invariants prevent you from reporting a property as nonwritable-nonconfigurable unless the target actually has such a nonwritable-nonconfigurable property

[14:39:31.0000] <keith_miller>
what does it mean to observe the sequence?

[14:39:38.0000] <Bakkot>
uh, sorry

[14:39:44.0000] <keith_miller>
But why do I care?

[14:40:10.0000] <keith_miller>
If I want to get around the invariant a can just "swizzle" the target?

[14:40:12.0000] <Bakkot>
basically if a proxy reports a property existing and being nonwritable-nonconfigurable, then its value can't ever be reported to be something other than what it is reported to be at that point in time

[14:40:17.0000] <Bakkot>
you cannot just swizze the target

[14:40:20.0000] <keith_miller>
Is there a way to observe the target?

[14:40:25.0000] <Bakkot>
nope

[14:40:35.0000] <keith_miller>
Then yeah, why does it matter what the target is?

[14:40:56.0000] <keith_miller>
I could just tell you you are Array.prototype but really just an array

[14:41:02.0000] <keith_miller>
you are looking at

[14:41:03.0000] <keith_miller>
*

[14:41:27.0000] <Bakkot>
I don't know that it does matter what the target is?

[14:41:48.0000] <Bakkot>
but "basically if a proxy reports a property existing and being nonwritable-nonconfigurable, then its value can't ever be reported to be something other than what it is reported to be at that point in time" is still true

[14:42:32.0000] <devsnek>
i still don't get why that matters

[14:42:35.0000] <Bakkot>
the way this is accomplished is that in order to report a property existing and being nonwritable-nonconfigurable, you have to sort of "prove" that you will be consistent about its value in the future, by having the target as a "witness" in the proof sense

[14:42:50.0000] <keith_miller>
But what's the point?

[14:42:51.0000] <devsnek>
like if i want to confuse people with weird proxy traps why does ecma262 care

[14:42:53.0000] <Bakkot>
devsnek lotta code relies on that invariant, including security-sensitive code, is why that matters

[14:43:17.0000] <keith_miller>
how?

[14:43:57.0000] <Bakkot>
that's kinda SES's whole schtick

[14:44:27.0000] <keith_miller>
Seems like SES should just reject any incoming proxy objects or something

[14:44:33.0000] <ljharb>
if you can't rely on freezing something and having it stay frozen, a lot of code breaks

[14:44:36.0000] <Bakkot>
you cannot identify a proxy

[14:44:39.0000] <ljharb>
keith_miller: you can't have an isProxy

[14:44:48.0000] <keith_miller>
I was pretty sure there was a way to tell if an object is a proxy

[14:44:51.0000] <ljharb>
you can identify a proxy to any builtin that has slots

[14:45:08.0000] <keith_miller>
It's some weird sequence of code

[14:45:09.0000] <ljharb>
but you can't generically identify a proxy (unless you know it's claiming to be a slot-having builtin)

[14:45:17.0000] <Bakkot>
there is a way which works if the object has a mutable prototype chain, though this was unintentional

[14:45:21.0000] <ljharb>
oh right

[14:45:35.0000] <Bakkot>
doesn't work if the whole proto chain is fixed though

[14:46:12.0000] <keith_miller>
So, 99% of the time you can tell then?

[14:47:00.0000] <Bakkot>
in the relevant cases? not sure that's true, no; 99% of objects don't have any nonwritable-nonconfigurable properties, and the remaining 1% are disproportionately likely to have fixed prototype chains as well

[14:47:29.0000] <Bakkot>
but yes, you can tell some of the time, sure

[14:47:38.0000] <Bakkot>
this fact was not known when proxies were designed, mind

[14:47:40.0000] <keith_miller>
Well the relevant case is that you used 5x the CPU time to do get

[14:47:57.0000] <keith_miller>
so in that case SES will forever have bad perf

[14:48:31.0000] <Bakkot>
If your property access involves running JS code I don't think it is too surprising that you're gonna take a severe perf hit

[14:48:54.0000] <ljharb>
there are plenty of systems where perf doesn't really matter but correctness does

[14:48:54.0000] <keith_miller>
Isn't that almost everything in SES

[14:49:11.0000] <Bakkot>
yup, SES takes a severe perf hit

[14:49:18.0000] <Bakkot>
though not everything!

[14:49:33.0000] <Bakkot>
in particular, _because_ of this invariant, they don't have to wrap transitively-frozen objects

[14:49:40.0000] <keith_miller>
ljharb: Everyone says perf doesn't matter until they realize it's costing them 2+ hours of their phones battery life

[14:50:06.0000] <ljharb>
i mean, i still use the facebook app on my iphone

[14:50:25.0000] <ljharb>
so i'm not sure it starts mattering even then :-p

[14:51:03.0000] <Bakkot>
SES has chosen to make the tradeoff between security and performance in favor of performance, which is a fine decision for them to make

[14:51:28.0000] <Bakkot>
most people aren't gonna have any proxies and so don't pay any penalty for these invariants being enforced for SES

[14:51:35.0000] <keith_miller>
So SES owns proxies?

[14:51:44.0000] <Bakkot>
no?

[14:51:47.0000] <keith_miller>
What about people that want proxies and want things to be fast

[14:51:49.0000] <Bakkot>
sorry, let me state that another way.

[14:52:45.0000] <keith_miller>
Bakkot: Also, for what it's worth getter's don't really cost you anything. At least in JSC, once the optimizing compiler kicks in

[14:52:53.0000] <keith_miller>
Or the getter is crazy complicate

[14:52:57.0000] <keith_miller>
complicated*

[14:53:28.0000] <keith_miller>
which is exactly the problem here. I'd like to make the proxy traps effectively a getter but all the validation makes it too big to efficiently inline

[14:53:31.0000] <Bakkot>
the fact that proxies still enforce certain invariants means that all code in the entire ecosystem that wants to rely on those invariants can do so: otherwise every library would have potential bugs, including potential security bugs, if they assumed those invariants held as they did in ES5. and if they avoided bugs it would be at the expensive of significant complexity for every single user. I think it is good therefore that proxies

[14:53:31.0000] <Bakkot>
 do not allow you to violate language-level invariatns.

[14:53:38.0000] <ljharb>
keith_miller: getters have a cost that has nothing to do with runtime perf :-p

[14:54:02.0000] <Bakkot>
even though that comes with some performance cost for people who _do_ use proxies: because that price is paid _only_ by code that choses to use proxies, not by users of every single library which wants to rely on object invariants.

[14:54:28.0000] <Bakkot>
*chooses

[14:55:31.0000] <Bakkot>
(Now, I also happen to think that Proxies were a mistake in the first place. But I'm glad that they were done in such a way that you can still rely on certain invariants.)

[14:55:48.0000] <ljharb>
+2

[14:55:51.0000] <keith_miller>
Oh, I agree that Proxies were a bad choice, no argument there

[14:58:04.0000] <ljharb>
keith_miller: so who are the people that want to use proxies and also have them be fast, and what are their use cases? (obv not implying there's no such people)

[14:58:50.0000] <keith_miller>
ljharb: I've seen people use them for matrices on a single ArrayBuffer. That was the case I was trying to optimize

[14:59:29.0000] <keith_miller>
Basically they're migrating C code that has a float[3][3] and want to use the same coding style

[15:01:25.0000] <ljharb>
do you think "i want to use the same style as a different language" is a reasonable justification for invalidating existing language invariants?

[15:09:08.0000] <keith_miller>
ljharb: ? I don't think that's the only case where you'd want Proxies lol

[15:10:56.0000] <keith_miller>
I feel like that's a loaded gun question lol

[15:15:50.0000] <ljharb>
fair, sorry, i'm trying to understand why the invariants being there are a problem :-)

[15:20:43.0000] <keith_miller>
ljharb: Mostly the problem is that they're currently inconvenient for me :P

[15:21:16.0000] <ljharb>
lol ok


2020-08-29
[12:34:40.0000] <howdoi>
o/

[12:39:42.0000] <howdoi>
is there a way to list the internal methods of an Object? [AFAIR, we can only do it in the JS engine with some help of C++ methods]

[13:40:47.0000] <ljharb>
howdoi: you mean from JS?

[13:41:23.0000] <howdoi>
ljharb: yes

[13:41:45.0000] <ljharb>
if there were then they wouldn't be internal

[13:42:06.0000] <ljharb>
there's also no guarantee that they exist at all; they're just how the spec defines the observable behavior of objects

[13:44:21.0000] <howdoi>
nods, https://tc39.es/ecma262/#table-5 are the essential ones, right?

[13:47:52.0000] <Bakkot>
yup: `Table 6: Essential Internal Methods`

[13:48:24.0000] <Bakkot>
sidebar: we had a project to make tables have real IDs instead of numbers which get stale

[13:48:31.0000] <Bakkot>
we should get back to that

[13:49:41.0000] <Bakkot>
can't find an issue for it... guess I will open one

[13:49:43.0000] <howdoi>
nice! I would like to contribute to that effort.

[13:50:28.0000] <Bakkot>
aha: https://github.com/tc39/ecma262/pull/2060

[13:50:41.0000] <Bakkot>
just gotta get another editor to stamp it

[14:02:22.0000] <howdoi>
👍

[15:15:31.0000] <devsnek>
Bakkot: it occurs to me, the annoying part of the invariants is not so much that they exist, but that they're enforced against the proxy target

[15:15:46.0000] <Bakkot>
what else could they be enforced against?

[15:15:49.0000] <devsnek>
idk

[15:15:55.0000] <devsnek>
but like if your traps behave consistently

[15:16:00.0000] <devsnek>
and do things not related to the trap

[15:16:20.0000] <Bakkot>
it would probably be better if "target" had been called "witness"

[15:16:28.0000] <Bakkot>
since that's its actual function

[15:16:35.0000] <devsnek>
i had this issue when i was faking module namespace objects via proxies

[15:18:19.0000] <Bakkot>
yeah, the confusion is that the design suggests that the point of the "target" is that it is in some sense "the actual object", rather than serving a proof that the proxy is behaving consistently wrt the object invariants, which is the thing it actually does

[15:18:25.0000] <Bakkot>
*serving as a proof

[15:18:58.0000] <devsnek>
 well in terms of the ses use case of proxies it makes sense

[15:19:19.0000] <devsnek>
but if you're going for like "new exotic behaviour" it's a bit meh

[15:20:15.0000] <Bakkot>
IIRC SES uses "shadow targets" rather than directly wrapping the object, so I don't think the design even suits SES's use case

[15:20:47.0000] <devsnek>
well i'm definitely not an ses expert

[15:21:18.0000] <devsnek>
if you google "ses shadow target" it's just results for some handgun

[15:22:03.0000] <Bakkot>
mark mentions it here: https://github.com/Agoric/SES-shim/issues/88#issuecomment-552685187

[15:22:28.0000] <Bakkot>
but I think I got that idea from conversations with him; I don't know what they actually call it (and have not read the source lately)