►
Description
Mathieu Hofman briefly updates us on the latest position from him and Mark regarding the acceptability of async disposal and we conclude our conversation with Justin Ridgewell regarding AsyncContext.
A
Okay,
it's
an
assess
meeting,
it's
January
18th
of
2023.
We
have
a
couple
of
topics
leading
into
plenary
this
coming
week
or
weeks,
I,
don't
recall,
but
the
the
first
of
which
is
that
it
seems
that
we've
come
to
happy
compromises,
happy
enough
compromises
for
both
async
disposal
and
for
async
context
and
to
start
us
off,
I'd
like
to
give
the
floor
to
Matthew
to
talk
about
async
disposal.
B
Yeah,
so
at
the
scenery
we
had
raised
or
concerned
with
the
async
parts
of
the
resource
disposal
proposal
that
everyone
is
championing
mostly
around
the
lack
of
syntactic
points
for
interleaving.
When
so,
when
you
exit
the
blocks
originally
proposed.
When
you
exit
the
block,
be
the
resources
added
during
the
block
using
the
using
statements
would
have
been.
There
would
have
been
a
weight,
interleading
point
at
the
the
block
exits
and
that's
a
difference
from
what
happens
currently
in
in.
D
B
B
The
argument
was
put
forward
that
this
kind
of
syntactic
requirements
can
be
substituted
by
linting
and
basically
the
the
literature
could
realize
that
there
is
a
so
for
anyone
that
is
concerned
about
these.
These
awaiting
interleaving,
the
literary
can
help
and
tooling,
can
help
show
where
those
those
are
and
eventually
require
some
common
phase
syntax
to
to
to
show
where
those
would
occur.
B
So
that
means
if
there
is
a
break
statement
or
any
kind
of
conditional
exits
of
the
block
before
the
using
statement
is
reached,
there
won't
be
any
waiting
at
the
end
of
the
block,
but
there
will
be
a
an
awaiting
at
the
end
of
the
block,
regardless
of
the
value
of
the
binding.
If
the
statement
is
evaluated.
D
B
And
yeah,
so
that
is
the
proposal.
Ron
is
proposing
this
with
going
back
to
the
using
a
weight
Syntax
for
some
time.
We
had
suggested
that
async
using
was
a
better
approach,
but
that
was
in
the
context
of
having
an
explicit
weight
marker
at
the
end
of
the
block,
since
we're
moving
away
from
that,
we
believe
it
will
be
clear.
It
would
be
clear
with
using
a
weights
as
the
syntax,
because
the
weeks
were
being
used
suggests
that
there
will
be
a
Niger
leading
points.
B
A
All
right
well,
thank
you.
Matthew
I
think
that
that
is
a
very
happy
conclusion.
The
the
other
topic
is
following
on.
From
the
last
couple
of
weeks,
we
have
a
little
bit
of
follow-up
on
async
context
and
I
think
a
tentative
happy
conclusion,
and
Justin
and
Mark
previously
had
a
conversation
through
an
intermediate
meeting.
So
let's
just
follow
on
from
that
and
close
that
topic
out
for
now.
D
Yes,
you're
presenting
the
the
rewrite
slide:
good,
yeah,
okay,
so
there's
a
a
a
previous
bit
of
language
history
that
that
this
is
that
the
step
I'm
taking
here
is
enough
for
something
called
CPS:
transform:
communication,
Style,
pet
Community,
I'm.
Sorry,
continuation,
passing
style,
transform,
CPS,
transform
that
explains
one
level
of
language
by
translation
into
essentially
a
a
subset
of
the
same
language.
D
The
continuation
of
the
program
is
the
continuation
object
and
passing
it.
As
the
extra
argument
is
the
passing
Style
and
the
result
of
the
transform
is
that
you're
now
you
might
have
you
thought
of
it
as
translating
into
the
same
language
as
the
target,
but
you're
using
the
subset
of
the
language
with
no
call
return
you're
using
it
purely
as
a
one-way
message,
passing
language
that
everything
only
calls
nothing
ever
returns,
and
so
the
the
first
three
bullets
here
correspond
to
the
transparent
rewrite.
D
D
D
Sorry,
Justin's,
primitive,
as
just
as
code
manually
written
in
the
target
language
made
available
to
the
source
language.
So
in
particular
the
notion
of
extra
parameterization
should
only
require
passing
something
forward.
There's
no
use
made
of
there.
You
know
all
the
previous
takes
on
async
context,
all
had
a
try
catch
because
we
were
create
stacking
State
and
then
unstacking
state.
D
The
next
transformation
is
for
each
function,
definition
in
the
source,
language,
we're
going
to
add
a
new
function,
we're
going
to
add
a
new
parameter
named
capital
f
in
the
target
language
and
because
the
the
identifier
capital
f
in
the
target
language
does
not
begin
with
an
identifier.
You
cannot.
D
It
cannot
collide
with
anything
that
was
originally
written
as
an
identifier
in
the
source,
language
and
then
finally,
for
each
function,
call
in
the
target
language
we're
going
to
add
a
capital,
A
new
capital,
F
argument
in
the
source,
language
which,
if
we
do
nothing
else,
the
capital
F
argument
is
defined
in
the
lexical
scope
of
a
capital,
f
parameter
and
therefore
just
passes
it
through.
So
the
so.
D
The
result
of
the
full
first
three
bullets
is
that
there's
simply
this
extra
parameter
that
gets
threaded
through
everything
and
because
it's
threaded
through
everything
without
anything,
either
interfering
with
it,
manipulating
it
or
reading
it.
It
clearly
has
not
yet
changed
the
semantics
of
the
program.
Okay,
now
go
on
to
the
to
the
code,
okay.
D
So
what
we
do
in
this
slide
is
we're
manually
writing
a
new,
a
new
primitive
in
the
target
language.
Hence
the
name
making
a
sync
context:
that's
that's!
That's
the
identifier
that
we're
exporting
to
the
source
language
in
the
manually
writing
the
target
line
which
we
write
it
with
the
under
bar
because
make
Ace
in
context
in
the
source
line
which
takes
no
arguments
in
the
target
language.
It
takes
this
F1
argument,
F1
SP
and
we're
gonna
we're
gonna.
Have
since
we're
manually,
writing
the
target
language.
D
We
can
number
our
different
F's,
so
we
can
keep
them
straight
F1,
specifically,
that's
the
only
mention
of
it,
so
it's
not
actually
otherwise
used
in
this
code.
So
it
that's
the
one
that
doesn't
matter
which
makes
sense,
because
the
the
fluid
context
in
which
you
call
make
async
context
that
creates
a
new
async
context,
object.
New
fluid
variable
object.
The
fluid
context
of
that
call.
D
D
So
that's
the
place
where
we're
just
using
a
purely
functional
style
of
cleansing,
a
new
thing
onto
an
immutable
list
to
make
a
bigger
immutable
list.
In
this
case,
we've
taken
a
notational
shortcut
which
I
I
think
in
retrospect
by
make
things
more
obscure
than
clear
things
up.
But
in
any
case
the
form
of
cleansing
is
a
little
get
function.
That's
parameterized
over
a
transposed
map
and
the
important
thing
about
F3
is
well.
D
So
if
F2
is
transitively
immutable
and
perilous,
then
F3
is
transitive
and
perilous,
and
since
this
is
the
only
thing
that
makes
new
ones
out
of
old
ones,
if
the
first
one,
which
represents
the
empty,
fluid
context
which
no
matter
what
you
give
it
always
returns
undefined,
since
that
one
is
naturally
Transit
of
the
immutable
and
perilous,
then
by
induction.
All
of
these
are-
and
that's
the
reason
why
this
explanation
uses
the
transpose
map.
So
there's
two
different
techniques
used
in
this
explanation.
D
One
is
the
the
idea
of
the
defining
semantics
in
terms
of
a
transform
to
a
passing
Style
and
the
other
one
is
transposing
the
map.
The
the
key
thing
about
transposing
the
map
is
now.
We
can
see
that
in
the
target
language,
the
only
thing
that
we're
passing
through
that's
extra,
that's
that's
beyond
what
the
programmer
wrote.
D
In,
The,
Source
language
are
these
transitively
immutable
and
perilous
structures
and
therefore,
if
the
Primitive
that
we're
adding
that
extended,
the
expressiveness
is
introducing
a
danger
compared
to
the
semantics
the
programmer
thought
they
were
writing
in
the
source
language.
Well,
the
target
language
itself
is
still
an
object
capability
language.
D
So
the
the
difference
in
what
the
programmer
and
the
source
language
thinks
about
what
the
program
or
the
target
language
thinks
about.
Is
this
extra
fluid
fluid
scope
variable
the
F,
the
F
parameters
that
are
being
passed
through,
which
therefore
communicate
I,
I'm
going
to
say
only
information
but
I'm
going
to
revise
that
revise
that
to
observe
that
it's
only
it's
actually
identity
Which
is
less
dangerous
than
information
there
and
and
I
I
realize
there's
kind
of
this
hierarchy.
D
This
is
something
that
goes
beyond
what
this
is
a
thought
that
occurred
to
me
after
fry
in
there's
kind
of
this
hierarchy
of
danger,
which
is
ability
to
cause
effects,
mutable
State
IO
is
more
dangerous
than
information
and
information
is
more
dangerous
than
pure
identity.
So
there's
there.
So
it's
a
little
bit
counter-intuitive,
because
the
ability
in
object
capability
language,
the
ability
to
cause
effects,
are
capabilities.
Information
is
just
bits
and
then
unforgeable.
Identity
is
a
capability
again,
but
a.
D
So
so
the
specifics
here
is
that
the
but
the
transposed
map,
which
is
defined
up
on
line
eight
notice
that
that
there's
one
transposed
map
per
call
to
make
a
sync
context,
which
means
that
there's
a
transposed
map
per
fluid
variable
per
instance
of
async
context.
But
independent
of
you
know
all
of
the
bindings
of
the
same
fluid
variable
all
share
the
same
transposed
map.
D
D
So
then,
when
we
do
the
get
on
line
17
the
get
where
you
where
it's
you're
passing
in
the
hidden
fluid
scope.
It
then
the
fluid
scope
is
just
is:
is
at
the
in
the
target
language.
Is
this
get
operation
which
is
applied
to
the
transposed
map,
which
represents
the
fluid
variable,
and
what
it's
doing
is
the
get
is
adding
the
temporal
information
which
is
get
me
the
value?
That's
according
to
the
the
most
recent
binding
of
well,
the
current
binding
of
the
trigger.
C
D
Yeah,
good,
okay
and,
as
we
know
so
far
since
we
have
not
yet
introduced
rap,
we're
only
still
explaining
no
more
than
normal
synchronous,
fluid
scoping
that
you
could
have
written
safely
at
the
user
level.
So
we've
explained
it
in
terms
of
this
extra
parameter,
but
we
haven't
introduced
any
semantics
that
you
could
not
have
written
by
other
means
directly
in
an
object
capability,
Source
language.
Okay,
now
the
wrap
beginning
on
line
23
is
where
the
magic
happens
and.
A
D
Magic
is
that
on
line
30,
the
when
the
when
so
so
rap
takes
a
function
and
returns
a
new
function,
that's
doing
the
dynamic
equivalent
of
or
the
temporal
equivalent
of
closure
capture
and
I.
Think
I
have
a
slightly
better
way
of
explaining.
Why
why
closure
capture
is
so
powerful
and
why
it's
the
right
analogy
here,
better
explanation
than
I
had
that
for
I
am
which
is
when
you're
in
a
given
lexical
context.
D
You
have
certain
powers
by
virtue
of
being
in
that
lexical
context,
and
what
closure
capture
allows
you
to
do
is
to
be
able
to
use
at
a
later
time
the
powers
that
you
had
as
I'm.
Sorry
in
a
able
to
use
in
a
separate
context,
the
powers
that
you
had
by
virtue
of
being
in
that
context,
so
in
lexicals
and
and
with
lexical
closures
with
lexical
closure
capture.
D
So
the
the
key
thing
here
is
that
on
29
is
the
wrapper
function
that
is
then
invoked
later
and
when
the
wrapper
function
is
invoked.
It
then
invokes
the
wrapped
function
on
line
30,
but
it
passes
to
the
wrap
function,
F5
and
F5
rather
than
F6.
F6
is
the
temporal
context
in
which
the
wrapper
was
invoked.
D
F5
is
the
temporal
function
in
which
the
wrapped
function
was
wrapped
to
create
the
wrapper,
so
we're
restoring
the
the
the
temporal
scope
during
which
rap
was
called
so
when
the
wrapper
is
called
from
the
point
of
view
of
the
fluid
scoping.
It's
as
if
the
wrapped
function
was
called
during
the
call
to
wrap
only
for
you
know
only
with
regard
to
understanding,
what's
going
on
with
fluid
scoping,
it's
as
if
it's
going
on
at
that
time.
C
D
Right,
it
goes
away
simply
by
virtue
of
the
fact
that
F3
is
only
past
forward
outside
of
that
one
use
of
F3
the
the
rest
of
the
the
that
context
only
ever
mentions
F2,
so
so
there
that's.
Why
there's
no
side
effects
needed
no
pushing
and
popping
needed
in
an
imperative
manner.
Therefore,
no
try
finally
needed.
C
C
D
Yeah
this
is
my
my
third
attempt
to
understand
the
original
proposal
in
the
context
of
of
trying
to
map
it
to
object
capability
Concepts,
so
that
I
can
reason
about
what
risk
it
introduces
and
the
risks
it
introduces
are
only
I
think
are
now
clearly
only
information
leakage.
You
cannot
possibly
introduce
Authority
leakage,
permission
leakage,
ability
to
cause
effects
and,
and
therefore
the
attack
that
that
we
sh
that
we
showed
last
week
remains
I.
D
Think
representative
of
how
narrow
the
attack
surface
is
here
with
regard
to
code
written
in
the
source
language.
That's
not
sufficiently
aware
of
the
additional
dangers.
I
mean
it
looks
like
Carol,
the
hypothetical
Carol
and
the
attack,
which
is
code
written
in
the
source,
language
completely
unaware
that
this
new,
primitive
has
been
added.
D
Just
repeat
the
claim
that
as
far
as
I
can
tell
from
thinking
about
all
of
the
object
capability
code
that
I've
written
over
many
decades
over
most
of
my
career
and
all
of
the
object
capability
code,
that
I've
been
exposed
to
I,
actually
can't
think
of
any
code
who's
whose
intended
security
properties
would
be
broken.
If
Justin's
primitive
was
added,
as
in
in
this
manner
as
a
new
primitive
into
the
language
in
which
that
code
had
been
written
with
that
code
being
unaware
of
it
and
that's
a
pretty
strong
statement.
A
D
So
an
additional
issue:
that's
a
remaining
controversy
on
the
proposal
thread
that
I
think
this
fluid
passing
Style
explanation
speaks
to
is
the
fluid
scope?
Is
the
fluid
scoping
mechanism
per
realm
or
per
agent
when
it
was
explained
by
a
a
a
outer
top
level
shared
mutable
variable,
Justin's,
dunderbar
storage?
Variable,
you
know
you.
It
was
that
sort
of,
naturally
LED
you
know,
could
lead
to
expecting
it
to
be
per
realm.
Certainly,
cross
Realm,
shared
mutable
state
would
be
an
extremely
dangerous
thing
to
trafficking,
but
the.
D
If
we
explained
it
in
terms
of
that
and
with
the
transpose
Maps
the
transpose,
because
the
transpose
none
of
the
mutable
state
is
ever
across
realm,
the
only
thing
that
would
ever
be
communicated
across
realm
are.
These:
are
these
F
values
which
are
just
you
know,
functional
lists
of
symbols
to
be
looked
up?
C
S
that
would
actually
help
so
I
originally
chose
per
realm,
because
it's
the
simplest
to
explain
in
JavaScript
and
I.
Don't
have
to
do
anything
in
order
to
make
it
work,
and
it
also
when
I
was
doing
the
dnet
proposal,
it
was
told
that
I
was
told
that
I
needed
to
make
it
per
realm
so
that
there
wasn't
any
information
shared
having
it
be
per
agent.
Instead
is
actually
going
to
make
it
easier
for
browsers.
C
They
will
be
able
to
interact
with
the
current
storage
State
easier
because
they
don't
have
to
worry
about
which
context
the
code
that
is
currently
running
came
from
inside
of
their
agents.
If
you
have
like
an
iframe
that
has
shared
a
direct
reference
to
a
function
from
an
outer
realm
from
another
realm,
they
don't
have
to
worry
about
it
anymore,
it's
just
because
it
has
access,
it's
all
same
agents
and
they
can
just
snapshot
it.
It
also
helps
with
browsers
for
Native
host
code
that
doesn't
have
JavaScript
semantics
directly.
C
D
C
I
mean
that's
fine
with
me:
I
think
it
complicates
it
as
a
as
someone
trying
to
look
at
the
proposal,
I
don't
think
it's
straightforward.
The
only
reason
I
understand
is
because
I've
read
through
this
PR
several
times
in
order
to
understand
the
transform
maps
to
happen.
The
in
the
work
from
the
original,
my
proposal
to
the
explain
proposal,
and
it
doesn't
quite
carry
why
it
needs
to
be
that's
complicated,
essentially
as
a
security
model.
C
Yes,
I
I
could
add
a
security
document
onto
it
and
go
through
all
the
steps,
but
I,
don't
think
the
I
I.
Don't
think
the
initial
explanation
should
be
this
complicated
because
it's
not
targeted
at
security.
Folks,
it's
more
like
me
as
a
job
basic
JavaScript
developer.
What
does
this
thing?
Do?
Okay,.
A
D
C
D
And
that,
and
that
explanation
is
has
is
a
little
bit
more
complicated
with
the
transposed
map
is
essentially
still
works,
which
is
it's
no
longer
that
it's
the
map.
That
is
only
changed
once
it
is
The
Binding
of
a
map
and
a
key
to
a
value
that
is
only
only
ever
happens
at
the
moment.
The
key
is
created
so
for
the
same
key.
It's
never
going
to
be
bound
in
to
that's.