00:47
<ryzokuken>
does the meeting start dot at time?
00:47
<ryzokuken>
if one of the chairs could let me in, I'd ensure that my tech setup works one final time πŸ˜…
01:01
<devsnek>
hello everyone!
01:03
<Bakkot>
morning all
01:06
<ljharb>
rkirsling: you can't change your name unless you're a guest
01:07
<rkirsling>
πŸ‘
01:08
<ljharb>
are there slides being shown?
01:08
<devsnek>
yes
01:08
<ljharb>
damnit teams
01:09
<ljharb>
aha, switching out of the app and back fixed it for some reason
01:10
<ljharb>
fun hackmd thing, apparently making the days collapsible prevents clicking on links contained in the day heading
01:14
<jorendorff>
All the features are implemented in SM, actually, the slides are out of date
01:14
<jorendorff>
but, they're not shipping yet
01:14
<jorendorff>
to be fair, private methods are inefficient as implemented, we have to fix them before shipping
01:14
<ljharb>
jorendorff: yay, put that on the queue :-p
01:17
<littledan>
yay!
01:19
<shu>
who is speaking?
01:19
<ljharb>
"wenbo z"
01:20
<ljharb>
would it be useful for the chairs to clarify how our process works prior to a future advancement request?
01:21
<haxjs>
Wenbo Zhao is the GA rep of 360.
01:24
<akirose>
fyi devsnek i rearranged you and Frank so both of you have your own topics back to back instead of across two days
01:24
<devsnek>
ok
01:24
<devsnek>
if it makes the schedule better feel free to split mine up
01:25
<akirose>
Frank wanted his to be back to back and it worked really nicely with yours
01:25
<akirose>
but thank you β™₯️
01:32
<Bakkot>
re: mark's point: that shorthand syntax was indeed in an earlier version of this proposal; strong agree
01:32
<shu>
i see a lot of queue items reacting to the WeakMap-like reification: IIUC that's an explicit non-goal of this proposal and not included in this proposal
01:32
<littledan>
I deleted my queue item since I agree with Mark's various points; I don't have more to add
01:32
<devsnek>
i explicitly want us to reify private fields :(
01:33
<shu>
sure, that's not this proposal
01:33
<jorendorff>
Is it really true no language binds the name of a field to some reification of that field, rather than the value of the field?
01:34
<jorendorff>
statements of the form "no programming language has ever done X" have a low prior probability for me
01:34
<Bakkot>
jorendorff among languages which use `.` for field access? none that I'm aware of, though I don't know every language
01:34
<ljharb>
does any other language actually avoid breaking instance privacy with a reflection mechanism?
01:34
<rickbutton>
yep
01:34
<rickbutton>
no
01:35
<rickbutton>
i read that backwards
01:37
<littledan>
I'm really having trouble making sense of haxjs 's arguments here
01:38
<shu>
^ i am having trouble as well
01:38
<littledan>
Mark has explained how reification would be different from the syntax here (and has done so several times previously), both in terms of syntax and capabilities
01:39
<jorendorff>
ok so ... Alloy isn't an OO language, it's a relational language, but it uses `.` and fields are reified
01:39
<shu>
jorendorff: fascinating, link?
01:39
<jorendorff>
Alloy also isn't ... a programming language
01:39
<jorendorff>
but it IS fascinating
01:39
<devsnek>
the specification language?
01:39
<jorendorff>
yeah
01:40
<devsnek>
that thing is weird lol
01:40
<jorendorff>
shu: the best thing to read AFAIK is the language reference http://alloytools.org/download/alloy-language-reference.pdf
01:40
<rkirsling>
is it like, prolog but less expressive?
01:42
<rkirsling>
er like at a glance it's reminding me of something like LEAN or Coq but again...smaller?
01:43
<jorendorff>
huh. i think it must be weaker than Lean and Coq. feels more along the lines of prolog/datalog, but i don't know enough about that space to say more :-\
01:43
<ljharb>
jridgewell: you're a bit quiet btw
01:44
<rkirsling>
Yeah. I've used each of Coq and Lean a bit but never Prolog (though I know it's Yulia's favorite)
01:44
<jorendorff>
i like Lean
01:53
<jorendorff>
yes, good point. i would definitely assume that `#x` is an expression I can use anywhere, and then i would see the syntax error once, and then I'd be like "well this is stupid" (unjustly) and probably go look it up to make sure i understood
01:54
<rkirsling>
I mean I *definitely* don't think that anything in JavaScript should lead one to believe that `this.` would ever be droppable
01:55
<jorendorff>
yyyes, but mark's objection comes as a surprise to me, as worded
01:55
<rkirsling>
yeah sorry that was in reaction to his statement, not yours πŸ˜…
01:56
<jorendorff>
we're on the same page (you and I, not mark and I)
01:56
<rkirsling>
yeah
01:57
<devsnek>
what if we just make `#x` a thing you can use anywhere
01:57
<ljharb>
that would be the "private symbol" reification, which mark specifically has said wouldn't work
01:58
<jridgewell>
I think Waldemar actually made Mark's point stronger
01:58
<littledan>
I agree with Jordan here on this subset/syntax error point; this has been what the design of private fields and methods was based around
01:58
<jridgewell>
Having `#x.get` be something different than `this.#x.get` would be very surprising
01:59
<jridgewell>
(That' doesn't mean Mark is arging that `#x` should be shorthand for `this.#x`)
01:59
<jorendorff>
currently, if you go to type `this.toString()` and accidentally type `toString()` instead, it's weird
01:59
<jridgewell>
`#x` in Mark's comment would be a WeakMap
02:00
<devsnek>
who needs `#x.get(v)` when you have `v[#x]`
02:00
<jridgewell>
So `#x.get` would take an object to get from, where `this.#x.get` would be the value at `this.#x`, which apparently has a map API
02:00
<jorendorff>
but that doesn't seem to be a big problem?
02:00
<jridgewell>
devsnek: You can't pass around syntax lik e`v[#x]`
02:00
<jridgewell>
You could pass around `#x` if it reified to a map
02:01
<jorendorff>
jridgewell: I think devsnek means `#x` should be more symbol-like
02:01
<devsnek>
yeah like we should just make it a value
02:01
<jorendorff>
in that view, it is a value and you can pass it around
02:01
<devsnek>
every possible suggestion is causing confusion with expressions in some way
02:01
<jridgewell>
If it becomes a Private Symbol, then that would work
02:01
<jridgewell>
But I don't think we're going to get them
02:01
<devsnek>
confusion with them cuz lhs of `in`, confusion cuz `#x.y`, confusion cuz `x[#y]`
02:01
<devsnek>
there's no winning
02:02
<jorendorff>
hear me out, let's start over with R4RS scheme...
02:02
<jorendorff>
</joke>
02:03
<shu>
R*4*RS
02:04
<jorendorff>
shu: i think tradition has it that the first one you personally implemented is the last good one
02:04
<devsnek>
crazy to me that private symbols is outside the realm of people's mental models but adding a new kind of object is a-ok
02:04
<shu>
ah, very well
02:06
<devsnek>
new decorators look reasonable iirc
02:06
<ryzokuken>
super excited about it!
02:10
<michaelficarra>
I think this is supposed to say "bar"?
02:10
<michaelficarra>
Also foo/bar are terrible names, please don't use them in examples
02:10
<michaelficarra>
use Pokemon
02:11
<devsnek>
use js ui libraries
02:11
<devsnek>
there are thousands to choose from
02:12
<ryzokuken>
pokemon are fun tho
02:14
<jorendorff>
dynamic language features are also fun
02:14
<jorendorff>
I think we're meant to be learning that fun is bad
02:14
<devsnek>
dynamic scoping!
02:15
<rkirsling>
yeah that extended pokemon example was inspiring
02:16
<rkirsling>
definitely will use game references in future presentations
02:17
<ljharb>
might be a fun game, without googling, figure out which obscure universe is being referenced by names of things
02:17
<devsnek>
slide show but everything is don't hug me i'm scared references
02:17
<rkirsling>
devsnek: approve
02:18
<rkirsling>
throw error upon setting color to green
02:18
<Bakkot>
should start using the names of mathematical objects
02:18
<devsnek>
`let lattice = 4`
02:18
<ljharb>
for example, zummi/gruffi/grammi/tummi/sunni/cubbi/gusto/chummi
02:18
<ryzokuken>
I thought it would be more fun if people actually got the reference lol
02:19
<akirose>
ljharb: too easy
02:20
<akirose>
also just reading that makes my teeth hurt
02:20
<shu>
Bakkot: you mean like x, x', x'', x''', x''''
02:20
<ljharb>
akirose: only too easy for the cool kids
02:20
<leobalter>
did we all lost Chris' audio for a few seconds?
02:20
<leobalter>
ok sounds like yes
02:21
<devsnek>
just teams things
02:21
<ryzokuken>
I had to perform 13 satanic rituals to make it work
02:21
<littledan>
whew, what a relief
02:21
<devsnek>
glad it wasn't 14
02:21
<akirose>
ljharb: you mean people in their 30s
02:21
<ryzokuken>
(p.s. it still doesn't, I had to use chromium)
02:21
<gibson042>
ryzokuken: I too have used perl in anger
02:22
<leobalter>
my internet is also bouncy this week so it could be me as well
02:22
<ryzokuken>
lol
02:22
<devsnek>
wait when did this become not-tdz
02:22
<ljharb>
oops
02:22
<gibson042>
whoops
02:22
<akirose>
AHAHAHA
02:22
<mmarchini>
Teams is clearly trolling us
02:22
<shrutikapoor>
trololololol
02:23
<mmarchini>
Blocking proposal via technical issues
02:23
<ryzokuken>
petition to move to the most reliable mode of comms
02:23
<mmarchini>
πŸ™ƒ
02:23
<ryzokuken>
i.e. VNC for screenshare plus a SIP call
02:23
<leobalter>
is this the shareware version of Teams?
02:23
<devsnek>
lol
02:23
<leobalter>
pay for the full content
02:24
<ryzokuken>
"teams trial expired"
02:24
<leobalter>
This copy of Teams is not genuine
02:29
<rickbutton>
here just use this to activate: "FCKGW RHQQ2 YXRKT 8TG6W 2B7Q8"
02:29
<devsnek>
pf
02:29
<ryzokuken>
rickbutton: did you read the code from the CD?
02:30
<rickbutton>
from memory of course
02:30
<jridgewell>
Can else hear the WAREZ keygen music?
02:30
jridgewell
sees myself to TDZ
02:31
<michaelficarra>
how are people going to remember all these signatures for the different kinds of decorators and when they apply?
02:32
<devsnek>
aren't there just two
02:32
<devsnek>
(v, context) and ({ get, set }, context)
02:32
<michaelficarra>
I guess the same way people have to deal with options bags, look at the docs every time
02:33
<jridgewell>
I think this is actually the simplest decorators API yet.
02:33
<devsnek>
definitely the simplest one
02:33
<michaelficarra>
{method, initialiser} or something?
02:33
<akirose>
i can't imagine life without Alfred & Dash (& MDN)
02:33
<JemYoung>
I'm digging it so far
02:33
<akirose>
it's a lot to remember regardless
02:33
<akirose>
i'm not saying it's not a legitimate concernβ€”it's a v real concern for me
02:33
<akirose>
but also, it's already a lot to remember
02:33
<jridgewell>
v2 API was overflowing with customization
02:33
<devsnek>
when someone recites the splice signature from memory
02:33
<michaelficarra>
yeah I either MDN or just go straight to the spec, depending if I know exactly where to look
02:34
<michaelficarra>
devsnek: offset, length, replacements array? is that right?
02:34
<rkirsling>
devsnek: I mean it's not `tar` flags at least
02:34
<devsnek>
idk i'd have to check
02:34
<devsnek>
for tar i just always pass `-xvf`
02:34
<devsnek>
idk what they do but it seems to work
02:34
<jridgewell>
variadic insertions, not an array
02:35
<rkirsling>
what about -c
02:35
<michaelficarra>
jridgewell: ah, so close
02:35
<devsnek>
idk what -c is so i can't comment
02:35
<rkirsling>
me neither
02:35
<jridgewell>
I use it as an interview question 😈
02:35
<devsnek>
oh yeah you like javascript? name every function
02:35
<michaelficarra>
jridgewell: please no!
02:36
<ljharb>
for tar i have to memorize eXtract Ze Files, Verbosely
02:36
<jridgewell>
Lol. My interview question uses it, but knowing the signature isn't required.
02:36
<rkirsling>
devsnek: name every function on the `Math` namespace would be hard enough
02:36
<rkirsling>
ljharb: ohh it was -z not -c
02:37
<rkirsling>
so close
02:37
<devsnek>
overall this proposal seems pretty good
02:37
<ljharb>
shu: which use cases do you find least compelling?
02:38
<shu>
ljharb: hm, the least? probably metadata personally
02:38
<ljharb>
gotcha
02:38
<devsnek>
metadata is take it or leave it
02:38
<shu>
i don't have a use case in mind that is much less compelling than the others as much as i have a use case that is much more compelling than the others: fields
02:38
<rkirsling>
I've always felt terrified about the decorators proposal so this definitely seems like the least terrifying iteration
02:38
<shu>
class decorators as well, i don't find super compelling
02:38
<rkirsling>
oops I meant to say that in tdz
02:38
<devsnek>
shu: enough that you don't want them to be part of the proposal?
02:39
<shu>
devsnek: hard to say right now
02:39
<shu>
devsnek: i think the class decorator use case is probably fine with existing function call syntax, unless i'm missing something
02:40
<devsnek>
wdym "fine with existing function call syntax"
02:40
<shu>
devsnek: class C {} \n decorate(C) ?
02:40
<jridgewell>
`let Decorated = decorate(class Inner {})`
02:41
<devsnek>
isn't that true of everything
02:41
<shu>
not of fields, no
02:41
<devsnek>
decorate(C) where C has fields
02:41
<michaelficarra>
so decorated methods can be new'd?
02:41
<jridgewell>
That wouldn't give access to private fields
02:41
<devsnek>
is there some bad thing about class decorators i'm not aware of
02:41
<shu>
devsnek: there's no way to do the transform of data property -> getter/setter pair with function calls
02:42
<ljharb>
michaelficarra: that seems like a good issue to file - ensuring that decorated methods can't be newed
02:42
<michaelficarra>
ljharb: it doesn't sound like an issue, it sounds inevitable with this design
02:43
<ljharb>
ah right, it'd be weird if the decorator return got its [[Construct]] changed, so the only alternative is forcing them to `return { foo() {} }.foo` or something :-.
02:44
<michaelficarra>
yep
02:44
<Bakkot>
alternatively, we should make methods newable
02:44
<Bakkot>
they should always have been
02:44
<Bakkot>
static methods at the very least
02:44
<devsnek>
very important use case
02:44
<ljharb>
static methods, fair.
02:45
<devsnek>
at that point all methods
02:45
<michaelficarra>
Bakkot making things difficult
02:46
<jorendorff>
This really seems like it will pare down to a very, very nice MVP
02:47
<jridgewell>
keith_miller: What are the "local variable semantics"
02:47
<devsnek>
aside from metadata everything proposed seems reasonable
02:47
<keith_miller>
jridgewell: var @myDecorator foo = x;
02:47
<jridgewell>
Ahh
02:48
<keith_miller>
I assume that's like a getter on the scope variable
02:48
<leobalter>
I can confirm what Yehuda has said from our code base.
02:48
<keith_miller>
but still it's a bit wierd
02:48
<keith_miller>
I hadn't considered that before this meeting so maybe that's my b
02:48
<leobalter>
it's pretty convenient to add common accessors
02:51
<Bakkot>
re: littledan's point right now: how is a class decorator a position where there is no function call possible right now?
02:51
<Bakkot>
I am confused
02:51
<ljharb>
`export class C { }`?
02:51
<devsnek>
^
02:52
<ljharb>
also name inference with `const C = decorate(class { })`
02:52
<Bakkot>
`export let C = foo(class C{})` is equivalent
02:52
<ljharb>
sure, but then you have to repeat the name
02:52
<Bakkot>
that does not come _close_ to justifying new syntax
02:52
<akirose>
sorry about the english idiom, non-native english speakers
02:52
<devsnek>
Bakkot: you can also manually rewrite your fields to be getter/setters
02:53
<Bakkot>
devsnek right, but you have to do it manually, rather than ecapsulating it with a function call
02:53
<Bakkot>
but here you can do the encapsulation with the function
02:53
<Bakkot>
so I don't know what littledan means
02:53
<jridgewell>
I agree with Bakkot here
02:54
<akirose>
10 minutes
02:54
<jridgewell>
Burden of writing a `decorate(class {})` seems minimal compare to decorating a field
02:56
<jorendorff>
+2 to shu's last sentiment
02:57
<rbuckton>
hmm. I can't get to Reflector to get the link to TCQ ...
02:57
<devsnek>
looking forward to class {} |> decorate1 |> decorate2
02:57
<rbuckton>
nm, working now.
02:59
<gibson042>
❀️
02:59
<akirose>
wsdferdksl: should that be a new topic isntead of a reply?
03:00
<leobalter>
akirose: I believe it's a feedback on the current topic
03:00
<akirose>
i read it as parallel
03:00
<leobalter>
understanding the entire design as in a single proposal
03:01
<shu>
rbuckton: i'll delete my queue item if you've read it?
03:02
<rbuckton>
I've read it
03:03
<leobalter>
shu: would it be helpful for a better overview if I prepare a full set of Test262 tests for this proposal? I'd do my best to separate each part.
03:03
<leobalter>
like, I'm trying to improve the trade off
03:04
<shu>
leobalter: sorry i don't understand the question
03:04
<shu>
a better overview of what?
03:05
<rbuckton>
There are caveats to consider with class decorators, such as this case:
03:05
<rbuckton>
```
03:05
<rbuckton>
@decorator
03:05
<rbuckton>
class C {
03:05
<rbuckton>
static #x = 1;
03:05
<rbuckton>
static method() {
03:05
<rbuckton>
this.#x // could throw if `decorator` replaces class with subclass
03:05
<rbuckton>
C.#x // ok, accessing inner `C`
03:05
<rbuckton>
new C() // but this produces an inner `C`, not an outer `C`. Fixing this breaks the line above
03:05
<rbuckton>
}
03:05
<rbuckton>
}
03:05
<rbuckton>
```
03:05
<ljharb>
rbuckton: why would it throw if it's a subclass of C?
03:05
<Bakkot>
it sounded like class decorators were intended to replace the inner binding
03:05
<rbuckton>
Its a private static field.
03:06
<Bakkot>
ljharb static private has this problem
03:06
<rbuckton>
They throw for subclasses of `C`.
03:06
<haxjs>
another footgun
03:06
<ljharb>
oh right
03:06
<leobalter>
I was hoping I could provide some form to check each part of this proposal. I'm offering what I know how to do. It doesn't look like much valuable to do it before Stage 3 anyway
03:06
<ljharb>
i forgot because i have no use cases for private static
03:06
<leobalter>
I'm too tired, I'm sorry my ideas are too raw
03:07
<jorendorff>
littledan: nice work
03:07
<littledan>
jorendorff: Thank you
03:15
<rbuckton>
TypeScript's decorators rewrite the inner bindings of `C` to point to the class result of the decorator:
03:15
<rbuckton>
```
03:15
<rbuckton>
var _x;
03:15
<rbuckton>
var C_1;
03:15
<rbuckton>
let C = C_1 = class C {
03:15
<rbuckton>
static method() {
03:15
<rbuckton>
__classPrivateFieldGet(this, _x); // throws for subclass
03:15
<rbuckton>
__classPrivateFieldGet(C_1, _x); // throws for subclass
03:15
<rbuckton>
return new C_1(); // creates "decorated" C
03:15
<rbuckton>
}
03:15
<rbuckton>
};
03:15
<rbuckton>
_x = new WeakMap();
03:15
<rbuckton>
_x.set(C, 1);
03:15
<rbuckton>
C = C_1 = __decorate([
03:15
<rbuckton>
decorate
03:15
<rbuckton>
], C);
03:15
<rbuckton>
```
03:15
<rbuckton>
Except that TypeScript errors on `static #x` currently. There's no easy way *inside* the class to reference the binding *outside* of the class, currently [1]. This might be way haxjs was suggesting class meta properties yesterday (i.e., `class.current`, `class.decorated`) as a way to distinguish between the two.
03:15
<rbuckton>
[1] Other than `let C = @decorator class { ... }` maybe?
03:16
<rbuckton>
s/be way/be why
04:02
<ljharb>
akirose: robpalme update queue?
04:02
<devsnek>
i like this proposal
04:03
<akirose>
got u
04:03
<ljharb>
ty
04:03
<akirose>
holy shit i love this already
04:05
<michaelficarra>
please no more string literals
04:05
<michaelficarra>
also this is already valid syntax
04:06
<devsnek>
yeah but who is doing ``````
04:06
<devsnek>
that will just throw
04:06
<michaelficarra>
devsnek: me, and no it won't
04:06
<devsnek>
?
04:06
<Bakkot>
where's that gist
04:06
<devsnek>
strings are not functions
04:06
<michaelficarra>
tags can return tags
04:06
<jridgewell>
Yah, michaelficarra provided an `append` tagged template literal which continues to return a function after every tag invocation
04:07
<jridgewell>
But untagged is good to go. πŸ˜›
04:07
<Bakkot>
he provided it four years ago, even
04:07
<Bakkot>
https://gist.github.com/michaelficarra/70ce798feb25fdc91508f387190053a1
04:07
<devsnek>
so if you use append with empty strings on both sides
04:07
<devsnek>
as is very common
04:07
<devsnek>
:unconvinced:
04:08
<shu>
i am really confused by the previous slide
04:08
<shu>
the problem is that... you didn't dedent the string, therefore it's not === to an un-dedented string?
04:08
<shu>
why is that a problem?
04:08
<Bakkot>
yeah I am also confused
04:08
<jridgewell>
The syntax never exposes an un-dedented strings
04:08
<jridgewell>
Where the API can expose both
04:08
<jridgewell>
Whether that's really a problem is up to the dev
04:09
<drousso>
wouldn't this not work if the first line is not a newline?
04:10
<devsnek>
String.dedent is great except composing with other tag functions
04:10
<jridgewell>
Correct, unless that first line had the same common indentation.
04:10
<rbuckton>
https://usercontent.irccloud-cdn.com/file/0A5rHMJe/image.png
04:11
<michaelficarra>
Bakkot: scared me for a second there
04:11
<michaelficarra>
thought we were gonna have to fight
04:12
<littledan>
the syntax seems nice so that it can be based on the indentation where the opening quote is
04:12
<devsnek>
is there a widely understood way to compose template tag functions?
04:12
<rbuckton>
Also, this is valid code that executes and can be well behaved: https://usercontent.irccloud-cdn.com/file/KvA4SWj3/image.png
04:12
<rkirsling>
nice
04:12
<devsnek>
rbuckton: look up :P
04:13
<littledan>
let's use #` `#
04:13
<littledan>
html#`<div/>`#
04:13
<littledan>
everything with #!
04:13
<littledan>
tbh @ would work here as well
04:13
<rbuckton>
Scheme, but with ## instead of ()
04:14
<michaelficarra>
devsnek: I'd love to know if you fin an answer to that question
04:14
<devsnek>
what
04:14
<littledan>
#${ }# replaces ( )
04:14
<michaelficarra>
*find
04:14
<michaelficarra>
> is there a widely understood way to compose template tag functions?
04:14
<devsnek>
michaelficarra: i put it on the queue
04:14
<devsnek>
that's my primary reason for preferring the syntax
04:15
<devsnek>
if there's some easy way to compose String.dedent with other tags then i'm good with it
04:15
<michaelficarra>
uuhhhh that doesn't solve the problem still
04:15
<rkirsling>
oh damn we got elang on the queue
04:15
<devsnek>
E also had promises, now look where we are
04:16
<devsnek>
michaelficarra: my problem is not for N template it is for 1 template so it solves it for me :P
04:16
<devsnek>
s/template/tag/g
04:16
<michaelficarra>
devsnek:boring
04:16
<devsnek>
lol
04:17
<devsnek>
i just realized everything we're discussing is not stage 1 relevant
04:18
<michaelficarra>
true, I don't see this failing to reach stage 1
04:19
<Bakkot>
littledan "it can be based on the indentation where the opening quote is" would be bad, it makes the whitespace outside of the ``` significant
04:19
<shu>
i am now super confused
04:20
<rkirsling>
yeah none of this blocks stage 1 lol
04:20
<devsnek>
wont' stop us from discussing it
04:20
<littledan>
Bakkot: OK, if this is taken to be bad, I prefer a stdlib tag as well
04:20
<rkirsling>
if we can convince the champions to focus on the non-syntactic approach at this point, that'd be great, but not required
04:24
<haxjs>
does ``` conflict with markdown syntax??
04:24
<Bakkot>
?
04:24
<ljharb>
not in the sense that markdown syntax doesn't work in a js context
04:24
<ljharb>
conceptually, sure, it's also the same as "preformatted text" in slack or a bunch of other markdownish contexts
04:24
<haxjs>
i mean if u want to embed js code in markdown or verse vice
04:25
<ljharb>
markdown syntax also has single backticks
04:25
<ljharb>
so template literal syntax already conflicts.
04:25
<haxjs>
markdown could use `` double backtick
04:25
<jridgewell>
There was an option to allow 5 ticks in a row for markdown
04:25
<haxjs>
at least standard markdown
04:25
<jridgewell>
Or 7
04:25
<jridgewell>
etc
04:25
<haxjs>
oh !
04:25
<haxjs>
let's use 7 ```````
04:26
<haxjs>
not sure i enter the right count :)
04:26
<jridgewell>
Any number of ticks would continue until we encounter the same number of ticks
04:26
<rbuckton>
Markdown doesn't conflict with JavaScript. Also, markdown supports _n_-backticks for nesting:
04:26
<rbuckton>
```
04:26
<rbuckton>
`` allows ` in md ``
04:26
<rbuckton>
```
04:28
<haxjs>
but too many backticks just harm my eyes... :) really hope we can have some easy syntax :)
04:28
<rbuckton>
Somewhat amusing, I do have code that does something like this:
04:28
<rbuckton>
```
04:28
<rbuckton>
const fence = "```";
04:28
<rbuckton>
markdown`
04:28
<rbuckton>
${fence}typescript
04:28
<rbuckton>
...
04:28
<rbuckton>
${fence}
04:28
<rbuckton>
`;
04:28
<rbuckton>
```
04:28
<rbuckton>
(for mixing trusted and untrusted content when generating documentation for VS Code)
04:28
<rbuckton>
That didn't work well, heh.
04:28
<gibson042>
inline code spans can be wrapped in backtick strings of any length, e.g. ```code```: https://spec.commonmark.org/0.29/#code-spans
04:29
<rbuckton>
```
04:29
<rbuckton>
const fence = "`".repeat(3);
04:29
<rbuckton>
markdown`
04:29
<rbuckton>
${fence}typescript
04:29
<rbuckton>
...
04:29
<rbuckton>
${fence}
04:29
<rbuckton>
`;
04:29
<rbuckton>
```
04:29
<rbuckton>
That worked better...
04:31
<gibson042>
and code fences use 3 or more consecutive backticks
04:35
<rkirsling>
ooh πŸŽ‰ indeed
04:37
<michaelficarra>
yay, I much prefer Instant
04:37
<michaelficarra>
though I am bummed about negative durations
04:37
<Bakkot>
still don't understand your concern there
04:37
<Bakkot>
time has direction
04:38
<michaelficarra>
it's conflating the magnitude and the direction
04:38
<Bakkot>
it isn't conflating
04:38
<Bakkot>
it's representing both
04:38
<michaelficarra>
a duration is just a magnitude
04:38
<ljharb>
it's combining, surely
04:38
<haxjs>
if every other lib/lang have negative duration, we should have it :)
04:38
<michaelficarra>
sure, combining
04:38
<ljharb>
haxjs: in general i don't agree with that logic, but here i do :-)
04:39
<Bakkot>
whoosh, this is a _giant_ API
04:39
<Bakkot>
not necessarily bad but it is going to take forever to review it
04:39
<haxjs>
ljharb: I mean we need a strong reason to be difference. :)
04:39
<ljharb>
Bakkot: they're hoping we can all review it in 2 months
04:40
<michaelficarra>
they best be ready to rebase on top of 2007 because I'm not doing it for them
04:40
<rkirsling>
Bakkot: yeah it's basically the size of 402
04:40
<michaelficarra>
(quick, someone merge 2007)
04:40
<haxjs>
yeah it's a giant api and changing ...
04:40
<rkirsling>
so we need to consider it as if reviewing an entirely new spec
04:40
<Bakkot>
haxjs the idea is that they'll stop changing it and tell us and then we can review
04:40
<Bakkot>
which I think is what is currently happening
04:41
<Bakkot>
michaelficarra not sure they have a spec at all; I think the work was mostly in the polyfill
04:41
<haxjs>
bakkot: glad to hear that! but it seems there are still some new draft for new additions in the repo
04:41
<ystartsev>
Bakkot: hm, the spec isn't up to date?
04:42
<Bakkot>
ystartsev not sure, to be clear, I haven't been following closely
04:42
<Bakkot>
that was true at some point in the past
04:42
<haxjs>
like LocalDateTime (i am not sure ,this is what i saw last week)
04:42
<gibson042>
there's pending work in both the spec and the polyfill, but I think the polyfill is ahead
04:43
<michaelficarra>
someone post the Twitter vote link from the slides, I am too lazy
04:43
<ystartsev>
gibson042: we have done a review of the spec text in preparation for november, is that far behind?
04:43
<littledan>
btw the original Temporal API had something representing LocalDateTime, and it was a change from a couple years ago to try to remove it, for minimalism. The ensuing investigation taught us, Maggie Pint was right about ensuring it was present
04:44
<ljharb>
ystartsev: my sense from watching the repo is that it seems like it's changing in significant ways every day or three
04:44
<ystartsev>
hm... ok. is the plan still to advance this in november?
04:45
<gibson042>
ystartsev: I think so, many things will likely not change but you'll definitely need to re-review and it will probably feel more comprehensive than you'd like
04:45
<shu>
oh, we need to review Temporal for advancement by november?
04:45
<gibson042>
https://twitter.com/justingrantjg/status/1308619968632688640
04:45
<ljharb>
ystartsev: i assume that's still the hope, i'll be asking about review
04:45
<ljharb>
shu: yes, that's what they said in july
04:45
<michaelficarra>
wait, different calendars still use ISO 8601 instant formatting?
04:45
<shu>
okay, thanks
04:45
<Bakkot>
I am not confident we will all be able to review and address comments by november
04:45
<ystartsev>
gibson042: getting our domain experts to review it is quite a bit of work. i want to make sure that i don't ask them unnecessarily
04:45
<rkirsling>
hoo wow `DateAndTime` would be real bad
04:45
<ljharb>
Bakkot: me neither, which is what i said in july
04:45
<gibson042>
then I would hold off
04:46
<shu>
i would request the champion group to hold tutorial VCs for the reviewers + editors, if possible
04:46
<gibson042>
the current plan/hope is to have the spec ready sometime next month; there should be a slide on that coming up
04:46
<haxjs>
I hope we can have some time to introducing it to users and collect feedback before stage 3.
04:46
<gibson042>
with hope for advancement in January IIRC
04:47
<ystartsev>
gibson042: I've already requested a review and had it done prior to this meeting. It would be really good to only do that when the spec is ready. But outside of that there were no concerns
04:47
<michaelficarra>
shu: I think that's a good idea
04:47
<ystartsev>
ditto, i like shu's idea
04:47
<ljharb>
gibson042: ah ok, that's newly extended
04:48
<rkirsling>
I'm not a reviewer but I would like to attend such a meeting too
04:48
<jridgewell>
shu: Are we chartering a incubator again?
04:48
<jridgewell>
If so, can we sign up String.dedent?
04:49
<shu>
jridgewell: most definitely
04:49
<shu>
jridgewell: until further notice, there will be a 15-min chartering on the last day every meeting
04:49
<jridgewell>
πŸ‘
04:50
<littledan>
ystartsev: Yeah, sorry about the confusion about stability; I thought the expectation was that reviews would be requested before the next meeting, so I guess there wasn't a particular effort to telegraph the continued development
04:50
<michaelficarra>
jridgewell: you don't think you got enough feedback during plenary?
04:51
<ystartsev>
littledan: no problem, its not too much of an issue and we already have a good idea going into the next review
04:52
<littledan>
note that the champion group has done a lot of work to document rationale, but it's definitely a good idea to group it in one place
04:52
<jridgewell>
Yes, there's feedback, but I think we can solve some of the open questions during an incubator
04:53
<jridgewell>
Eg, whitespace-only lines affect "common whitespace", or whether to allow mixing whitespace.
04:53
<jridgewell>
These don't need full committee involvement to decide.
04:53
<michaelficarra>
jridgewell: are there open issues for these things? I'd prefer to weigh in on the issue tracker
04:54
<jridgewell>
Whitespace-only lines: https://github.com/mmkal/proposal-multi-backtick-templates/issues/13
04:54
<jridgewell>
I'll make one for mixing whitespace.
04:55
<Bakkot>
should look at what other languages do, too
04:55
<Bakkot>
often there is a common thing all languages do and we can just go with that
04:55
<jridgewell>
Each one seems to do something different. 😬
04:56
<jridgewell>
I personally like Python's impl, but there's enough competing prior art to choose anything.
04:56
<akirose>
my least favorite game: "this meeting has more [pick a dude's name] than women" 😭
04:57
<Bakkot>
a depressing game
04:57
<rkirsling>
yeah this is a bad one
04:57
<rkirsling>
you know it's bad when "Ross" is a name in the running
04:57
<ystartsev>
is it just me and aki this time around?
04:58
<ljharb>
ystartsev: shrutikapoor
04:58
<ystartsev>
ah good
04:58
<akirose>
No! shrutikapoor !
04:58
<akirose>
shrutikapoor: you're paypal, right?
04:58
<ystartsev>
i didn't see the name in the call but maybe she was on an earlier session
04:59
<ljharb>
wsdferdksl: your audio's getting a bit hard to hear
05:01
<Bakkot>
fun fact: you can spread own accessors if they're enumerable
05:02
<michaelficarra>
wow I did not know that
05:03
<ljharb>
that is true
05:04
<Bakkot>
(no reason to prefer that over frozen own data properties, though)
05:04
<Bakkot>
well, actually, I guess maybe laziness?
05:04
<haxjs>
record/tuple already have immutable own property? (or at least it behave like that?)
05:04
<keith_miller>
littledan: +1 on tutorial
05:05
<ljharb>
Bakkot: laziness but also, those own accessors would have to be nonconfigurable anyways to ensure immutability
05:05
<Bakkot>
yup
05:05
<jridgewell>
michaelficarra: mixing whitespace https://github.com/mmkal/proposal-multi-backtick-templates/issues/16
05:13
<michaelficarra>
whose phone keeps beeping? akirose?
05:14
<akirose>
nope i'm HW muted
05:21
<akirose>
i know i can be a little polyanna about things
05:21
<akirose>
but
05:21
<akirose>
i love this
05:22
<rkirsling>
no need to hesitate; language-level i18n is great
05:26
<ryzokuken>
i18n is amazing in general
05:27
<akirose>
YOOOOOOOO
05:27
<akirose>
BUDS
05:27
<haxjs>
i18n is hard! really like we improve the api ability to solve the problems :)
05:27
<akirose>
we need note-takers
05:27
<akirose>
can someone hop on
05:27
<ryzokuken>
akirose: let me try
05:27
<akirose>
so i don't have to interrupt
05:27
<akirose>
ty
05:27
<akirose>
(you don't have to take notes of the presentation of slides)
05:28
<ryzokuken>
okay, thanks!
05:28
<akirose>
having three cursors ready to go would be dope
05:31
<ljharb>
ystartsev: sorry, fixed the slides perms
05:31
<ystartsev>
The library exists but i don't know much about it ... that would be zibi or waldo
05:31
<ystartsev>
so, i have no idea in case anyone is wondering
05:31
<ystartsev>
ljharb: thanks!
05:45
<Bakkot>
I have no opinions on this issue
05:45
<Bakkot>
all options kinda suck
05:46
<devsnek>
lol
05:46
<michaelficarra>
oh good point from Mark
05:46
<devsnek>
we had this problem in node
05:46
<devsnek>
i don't remember how we solved it because its 1am
05:47
<devsnek>
aha we strictly control the type of the option so you can check `option: invalid type` throwing for it to be there
05:48
<Bakkot>
ljharb are you concerned that making an error into a non-error is breaking?
05:49
<devsnek>
Bakkot: new code can't be used on old runtimes
05:49
<ljharb>
in options bags only, yes
05:49
<Bakkot>
what's special about options bags?
05:50
<ljharb>
throwing on an extra property is the same as throwing on an extra argument
05:50
<ljharb>
we don't make apis that do the latter
05:50
<devsnek>
throwing on extra properties is weird to me
05:51
<Bakkot>
this isn't "extra property", it's "an unexpected value", as I understood it
05:51
<Bakkot>
"an unexpected value of an expected property"
05:51
<shu>
yes, that was the clarification just now
05:51
<devsnek>
yeah that should throw
05:52
<shu>
ljharb: i think you're misunderstanding
05:52
<shu>
shane is not proposing anything about unknown properties afaict?
05:53
<jridgewell>
Add a "clarifying statement" on TCQ?
05:53
<ljharb>
thanks
05:55
<ljharb>
my bad on misunderstanding the question i guess
05:56
<devsnek>
seems philipp misunderstood as well?
06:04
<ljharb>
many helpful anonymous animals
06:04
<ljharb>
(do that few people have a google account?)
06:05
<rkirsling>
anonymous-ness is document-specific
06:05
<rkirsling>
presumably everyone has a google acct
06:05
<devsnek>
anonymous is due to it being public
06:05
<jridgewell>
You have to click a button for you to expose your Google account
06:05
<ljharb>
oh, which button
06:05
<devsnek>
that one
06:05
<jridgewell>
By default on pub docs, everyone is anonymous
06:05
<ljharb>
i wanna click it, which one
06:05
<jridgewell>
It's at the top right...
06:06
<jridgewell>
It has a little pop up when you first open Docs
06:06
<ljharb>
ok but i've opened docs like a thousand times and i see no popup
06:06
<ljharb>
i'm logged into my gmail
06:06
<ljharb>
and the only name i see in the list is rob's
06:07
<jridgewell>
πŸ€·β€β™‚οΈ
06:07
<jridgewell>
There's always a pop-up fo rme
06:08
<ljharb>
i wonder if it has to be explicitly shared with someone for their name to show up
06:08
<michaelficarra>
I don't see this button either