►
Description
This week we reviewed the arguments for and against symbols as weakmap keys and began a conversation about bulk revocation of proxies.
A
Oh
welcome
to
the
new
year
everyone
we're
recording
for
the
s
meeting
the
first
of
2022,
it's
2022
right
and
we
have
two
topics
on
the
agenda,
but
a
couple
of
announcements.
First,
there's
there
will
be
a
meeting
at
3
p.m:
pacific
today,
where
a
group
of
formal
methods
folks
are
going
to
present
their
work
and
how
it
pertains
to
our
work.
A
A
I
will
update
that
zoom
link
if
it
changes-
and
I
do
not
know
whether
that
will
be
recorded,
but
I
presume
that
we
will
ask
and
that
they
will
ascend,
and
I
can
make
sure
that
a
link
to
that
recording
appears
in
our
agenda
and
minutes
here,
so
that
people
can
catch
up
if
they
like
and
if
they
can't
attend
the
the
other
announcement
is
that
some
new
changes
in
the
schedule
for
other
meetings.
A
Apart
from
sas,
the
we've
been
having
a
weekly
endo
sync
previously
at
another
time,
but
we're
going
to
be
having
that
this
year,
every
wednesday
immediately
following
this
meeting,
that's
11
a.m:
pacific
wednesdays,
in
order
for
us
to
be
able
to
collaborate
with
a
new
collaborator
in
poland
and
the
endo
project
is
starting
to
take.
A
The
requirements
are
starting
to
take
shape.
So
this
we're
building
an
electron
browser
that
will
serve
as
a
power
box
that
manages
an
endo
daemon
that
speaks
capd
and
can
host
host
plugins
from
strangers,
and
it
can
connect
on
to
web
pages
on
the
web
or
chrome
extensions
or
browser
extensions
in
general.
That's
the
that's
the
general
plan
and
that's
it
for
announcements.
A
The
first
topic
for
today
is
a
catch-up
on
symbols
as
weak
map
keys,
where
a
topic
that
leo
and
matthieu
have
been
both
very
involved
in-
and
our
second
topic
is
from
alex
alex-
wants
to
talk
about,
revocation
of
multiple
proxies
simultaneously.
B
Okay,
thank
you
yeah,
so
the
symbol
as
weak
map
keys
is
being
historically
co-championed
by
many
delegates.
B
Many
member
arcs
of
tc39
karidia
and
I
are
and
rake
our
co-champions
of
this
proposal
with
some
people
from
regalia
some
people
from
bloomberg,
and
one
of
the
reasons
we
wanted
to.
B
We
are
working
on
this
proposal
and
I
presented
it
to
this
situation
and
the
last
time
trying
to
achieve
stage
three
one
of
the
reasons
that
is
that
we
want
to
explore
the
membrane
systems
using
the
new
shadow
realms
with
a
way
to
to
have
the
symbol
as
weak
map
keys,
to
have
a
lower
footprint
on
the
membrane
system.
B
B
By
the
time
I
presented
to
tc39,
because
records
and
tuples
was
still
discussing
about
box,
but
it
seems
that
box
is
not
going
to
be
a
tactical
now.
B
So
bloomberg
is
now
interested
in
putting
more
weight
on
the
symbol
as
weakness
proposal
as
like
in
support
of
to
to
have
to
provide
some
alternative,
viable
alternative
for
the
lack
of
boxes
in
records
and
temples,
saying
that
the
proposal
has
got
more
weight
on
it.
For
the
motivations
one
of
the
motivations
was
the
membrane
system.
Now
we
also
got
records
and
tuples.
B
Among
little
others,
but
I
think
these
two
are
the
strongest
motivations
so
far
and
with
the
motivations
we
also
have
contention
points.
B
B
That
means
these
are
symbols
you
register
with
symbol.4
and
you
can
retrieve
them
with
symbol.q4,
also
like
e4
or
retrieve
them
with
symbolic,
four
as
well.
You
register
and
retrieve
them
with
symbol.4.
there.
As
someone
say
in
the
github
thread,
there
is
a
fictional
spec
or
fictional
implementation
of
this
global
registry,
because
this
is
like
how
implementation
decides
to
do
that.
But
you
have
this
global
registry,
and
this
global
registry
is
like
not
only
limited
to
to
a
realm
global,
but
it's
shared
among
any
realms.
B
So
if
you
have
a
global
registry,
you
register
a
symbol
there.
It
means
the
symbol
is
going
to
be
there.
It's
probably
going
to
be
alive.
Even
if
you
delete
that
symbol,
if
you
try
to
get
again
the
same
same
symbol
with
the
same
key
you're
supposed
to
get
the
same
symbol,
value.
B
So
the
contention
point
has
two
like
from
the
condition
point:
we
have
two
directions
we
need
to
work
through.
One
of
them
is
just
allowing
these
symbols
to
be
used
as
we
map
keys.
B
That
brings
a
case
where
these
symbols
are
not
value,
valuable
to
be
used
as
weak
map
keys,
but
that's
a
concern
for
the
user
and
the
other
direction
is
disallowing.
B
These
specific
symbols.
Symbols
are
in.
The
global
registry
should
not
be
allowed
in
the
as
with
map
keys.
That
would
create
a
verification
when
you
use
a
symbol
as
a
weak
map.
Key
you
end
up
like
verifying
if
that
symbol
can
be
used
or
not.
So
you
also
like
tell
if
that
symbol
is
in
the
global
registry.
B
As
like,
not
a
like
synthetical
thing,
it's
more
like
api
based
thing
and
there
is
precedent
for
of
observing.
If
the
symbol
is
right
or
not,.
B
I
just
want
to
find
the
winning
path
for
stage
three
and
I
hope
like
we
can
get
more,
maybe
some
discussion
here.
Where
is
the
direction
we
should
try
harder?
Honestly,
as
as
I
say,
I
am
neutral
to
that,
all
I
want
is
a
regular
symbols
to
be
used
as
weak
map
keys.
B
D
Yeah
there
seems
to
be
a
position
on
both
sides.
Here
I
originally
started
in
the
opinion
that
it
shouldn't
matter.
D
But
now
having
dealt
a
little
bit
more
with
box,
object,
placeholder
and
the
use
cases,
I
actually
do
believe
that
it
makes
no
sense
to
allow
registered
symbols
as
weak
map
keys,
because
we
will
have
other
with
the
records
and
tuples.
I
believe
we
shouldn't
allow
either
a
tuple,
for
example,
that
doesn't
contain
a
symbol.
So,
for
example,
you
just
have
a
tuple
that
has
zero
in
it.
We
shouldn't
allow
that
as
a
weak
mac
key.
D
However,
we
should
allow
a
couple
that
has
a
symbol,
a
unique
symbol
in
it,
because
that
would
be
required
for
membranes.
So
since
we
already
need
to
do
a
detection
that
is
not
based
on
the
type
of
of
the
value,
I
I
believe
we
should
just
buy
the
bullet
now
and
introduce
a
predicate
that
it
can
be
used
to
test
whether
a
certain
value
can
be
used
with
weak
collections,
but
yeah.
D
There
are
concerns
that
this
is
a
departure
that,
like
it
wouldn't
until
now,
a
lot
of
the
that
type
of
testing
has
been
done
based
on
type
of,
and
this
this
would
be
something
new.
E
Yeah,
so
not
based
upon
weak
maps.
Weak
maps
are
what
we
talk
about
a
lot
in
this,
but
was
there
any
discussion
about
finalizers
and
weak
ref
in
their
behavior
with
symbol
keys,
if
you
put
them
there,
because
it
should.
D
E
E
E
If
we
have
some
things
that
are
eternal,
they
never
get
garbage
collected
like
the
symbols
that
are
registered.
There
are
a
few
other
things
that
also
never
get
collected
realistically.
D
I
I
think
so
so
I
think
the
distinction
here
would
be
between
registered
symbols
and
symbols
that
appear
on
the
symbol
global.
So
I
don't
know
if
we
have
a
name
for
that,
so
symbols
that
are
available
by
walking
from
from
the
global
objects
and
that
are
can
be
recreated
anytime.
You
create
a
realm
because
symbols
are
roundless
so
intrinsics,
I
don't.
D
I
don't
think
well.
Mark
said,
like
it's
probably
a
mistake,
that
the
global
symbols
are
not
registered
symbols,
but
that's
what
it
is
now,
in
my
opinion,
things
that
can
get
collected
is
an
implementation
detail
that
shouldn't
be
visible
to
something
like
a
weak
map
or
or
finalization
registry.
D
So
if
it's
something
that's
always
reachable
because
of
some
detail
of
the
implementation
or
because
of
the
language
spec,
it
shouldn't
matter
here
in
this
case
we're
really
talking
about
the
way
I
see
it
is
is
talking
about
forgivable
values
and
unforgivable
values.
D
You
can
forge
a
registered
symbol,
the
same
way
as
you
can
forge
any
string
or
any
number
where
unique
symbols
are
unforgivable,
and
this
is
the
distinction
in
my
mind
and
the
reason
why
I
believe
numbers
strings
and
registered
symbols
shouldn't
be
allowed.
As
with
my
keys
the
same
as
tuples
that
can
be
that
solely
contain
other
forgeable
values.
E
A
little
bit
interesting
there,
so
the
thing
wasn't
necessarily
that
something
does
get
garbage
collected
for
me,
but
for
finalization
you
test.
If
something
has
garbage
collection
semantics,
so
not
that
it
will
ever
be
garbage
collected,
but
that
it
does
have
a
lifetime
associated
with
it.
It
is
affecting
the
garbage
collector.
D
So
that
probably
would
match
what
I
define
as
forgivable
right.
E
Or
unfortunately,
we
could
argue
and
bicker
about
this.
I
my
main
curiosity
is:
there
is
a
carve
out
in
finalization
registry
when
it
was
put
in
that,
if
a
value
is
no
longer
reachable,
it
is
allowed
to
be
garbage
collected,
which
would
fire
the
finalization
registry.
So
if
you
could
ensure
that
symbol.4
and
the
realm
constructor
are
no
longer
reachable,
you
could
collect
them
in
such
a
carve
out-
and
I
don't
know
the
behavior
here
regarding
those
things.
C
D
E
Registered
symbols
are
deniable.
I
don't
think
all
the
built-in
symbols
are
deniable.
If
I
remember
right.
D
D
E
D
So
yeah,
so
I
I
think,
as
leo
mentioned,
that
global
registry
is
a
spec
fiction.
The
the
fact
that
some
implementations
create
a
unique
representation
and
story
and
actually
store
those
in
in
some
kind
of
map
is,
is
an
implementation
detail
like
an
implementation,
could
as
well
just
forge
a
new
value.
D
That
says
this
is
a
symbol,
and
this
is
description
within
it
that
is,
or
the
string
or
number
that
was
passed
in
and
whenever
you
call
symbol
four,
you
always
recreate
that
value
and
whenever
you
call
a
symbol.key
for
you
just
unwrap
that
value,
so
the
fact
that
a
map
actually
exists
and
that
there
is
a
unique
identity
for
those
is
an
implementation
detail,
and
one
of
my
concerns
is
that
this
would
force
some
implementations
to
actually
create
this
map
so
that
they
can
associate
so
they
can
be
used.
D
Those
original
symbols
can
be
used
in
weak
map
with
collections.
You
are
right,
however,
that
since
those
are
only
those
values
can
only
be
created
or
used
through
a
symbol,
foreign
symbol,
key
for
it's
deniable
and
technically
you
could
prevent
the
program
from
ever,
creating
them
or
getting
the
back
of
it.
Yeah.
B
One
of
the
concerns
that
you
has
mentioned
in
the
github
triad-
and
I
want
to
help
like
observing
that
was
the
concern
of
like
implementations-
have
been
some
complexity
to
on
verifying
the
the
aspect
of
the
the
symbol
and
also
like
just
one
thing
to
correct
myself.
I
mentioned
the
global
registered
symbols,
but
also
the
well-known
symbols
are
also
like,
always
retrievable
among
different
realms.
B
So
in
in
this
case,
there
is
a
concern
of
like
this
complexity
to
affecting
implementations,
but,
as
I
think,
as
justin
ritual
has
mentioned
there
on
the
tread,
we
should
probably
observe
this
with
the
the
actual
implementations
I
don't
know
like
we
can
do
our
diligence
to
ask
the
browser
implementers,
but
I
also
like
to
have
the
opportunity
to
ask
peter
hardy
like
if
having
this
verification
when
reusing
symbols,
weak
maps
and
like
blocking
symbols
that
are
well
known
or
registered,
is
that
a
complexity
like
not
a
complexity
tool?
B
Is
that
a
tool
on
is
that
at
all
on
all
the
implementation
of
like
from
registered
observing
this
aspect
will
impact
performance
complexity
is
from
this
implementer's
perspective.
Is
that
a
an
actual
like
how?
How
should
we
do?
That?
Is
that,
because
I
agree
with
matthew
like
we
are
introducing
a
complexity,
but
maybe
this
is
not
a
big
thing,
and
I
would
like
to
to
get
this
perspective
from
implementers
as
well.
F
Hi,
I'm
I'm
I'm
joining
late.
Sorry
I
I
did
send
out.
I
did
upgrade
the
meeting
that
was
on
the
calendar
and
sent
out
invites
to
the
people
that
I
knew
were
interested
if
you're
interested
in
that
meeting
today
at
three
o'clock-
and
I
didn't
invite
you
please
let
me
know,
but
with
regard
to
leo
the
question
that
you're
raising,
I
have
been
following:
the
symbols
and
registered
symbols
and
the
weak
map
and
all
that
issue.
But
what
was
the
particular
question
that
you
were
just
raising.
B
So
mark
just
as
a
recap,
I
was
saying
that
the
symbols
as
weak
map
keys-
we,
I
think
the
contention
point
here-
is
allowing
or
disallowing
symbols
that
are
subjective
to
like
that.
Have
pro
issues
with
liveness,
like
always
live
like
as
symbols,
are
registering
the
global
civil
registry
and
well-known
symbols
right
and
one
of
the
the
questions
for
for
this
contention
points-
and
this
is
just
one
of
them.
There
are
many
aspects
I'm
trying
to
take
this
one
granular
granule,
granularly,.
B
Matthew
has
mentioned
like
this
might
be
initial
for
implementations,
because
the
way
the
global
symbol
registry
is
implemented
today
is
is
not
like
fully
specified
like
the
implementation
should
handle
this
as
they
prefer,
because
this
is
internal
and
not
the
only
parts
are
observable
or
when
we
get
like
the
symbol,
description
or
not.
D
Mark,
basically,
you
made
me
realize
the
other
day
that
implementations
and
that
you
expected
implementations
would
implement
registered
symbols
as
just
wrapping
the
description
and
creating
a
new
value.
Every
time
when
calling
symbol,
4
and
simply
comparing
those
type
of
symbol
by
content
instead
of
comparing
them
by
identity
and
some,
it
appears,
I'm
not
sure
if
any
implementation
actually
does
it
that
way.
D
I'm
I
don't
want
to
speak
for
peter,
but
we
did
look
at
the
modable
access
implementation
and
we
did
find
that
they
were
using
a
hashmap
that
actually
leaks.
If
you
create
an
infinite
amount
of
symbol,
even
if
you
don't
reference
them
anymore,
that
ash
map
will
grow
forever.
D
F
Okay,
so
so
how
does
the
the
question
about
what
the
implementations
do
affect
the
question
of
of
what
we
should
propose?
This
should
be
in
the
standard,
since
the
standard
only
deals
with
observable
things
right,
there's
no
observable
difference
between
these
two
implementation
strategies
so.
D
I
I
raised
the
question
of
requiring
more
complexity
and
implementations
if
there
was
an
implementation
that
actually
does
this
comparison
by
value
and
forging
a
new
value.
Every
time
in
that
case,
requiring
them
to
support
registered
symbols
in
weak
map
would
effectively
require
branching
and
parallel
implementation
for
weak
map
and
weak
ref
and
all
those
things
where,
when
they
add
a
registered
symbols
they
put
in
them
in
a
map
instead
of
a
weak
map,
for
example,
and
I.
F
Since
all
implementations
already
have
a
map,
this
doesn't
seem
like
a
lot
of
complexity.
Well,.
D
It's
a
complexity
because
now
they
need
to
branch
on
the
instead
of
branching
on
like
oh,
when
you
I
try
to
add
something
we're
not
going
to
allow
this
value.
This
is
a
very
simple
branch
that
doesn't
have
ongoing
impact,
whereas,
like
now,
you
need
to
check
every
time
you
have
a
has
or
if
you
have
like
an
addition
or
something
you
need
to
check
on
the
type
of
the
thing
and
use
either
the
the
weak
map,
effemiron
implementation
or
use
the
actual
map,
implementation.
F
I'm
just
saying
that
that
that
additional
complexity
I
mean,
if
we
were
doing
it
at
the
user
level
right
and
it
would
be,
it
would
be
a
small
amount
of
code.
So
I
think
it's
a
small
amount
of
implementation
complexity.
Anyway,
if
you're
worried
about
the
the
performance
cost
of
the
extra
branch,
you
could
have
it
be
a
sub-branch
of
the
of
the
of
the
branch
check,
but
that
would
lead
to
rejection.
Otherwise,
so
I.
D
Agree,
it's
doable
and
performance
wise.
It
shouldn't
have
much
impact,
it's
just
requiring
a
bit
of
branching
code
and
which
I've
heard
before
implementers
being
concerned
about
that
type
of
special
casing,
especially
when
it
has
to
do
with
garbage
collection.
F
Okay,
so
so
let
me
see
if
I,
if
I
understand
the
overall,
the
overall
situation
right
now.
As
far
as
we
know,
no
implementations
use
this
other
representation
and
therefore
current
implementations.
F
If
they
were
going
to
allow
all
symbols
as
weak
map
keys,
would
not
need
to
do
a
branch
and
then
the
the
but
but
all
implementations
already
leak
registered
symbol,
storage
and
they
would
continue
to
leak.
All
current.
E
D
D
A
map
with
a.
E
Forgeable
key,
but
the
value
is
what
the
key
value
pair
lifetime
is
associated
with,
and
the.
F
D
Right
in
in
in
those
cases,
if
you
have
a
if
the
global
registry
is
implemented
internally
as
a
map
where
the
value
is
held,
weekly.
D
You
will
have
an
interaction
with
weak
map
because
when
you
add
those
symbol
into
the
weak
map,
now
you
need
to
the
weak
map
needs
to
keep
alive
the
registered
symbol,
yeah
or
else
you
would
be
able
to
observe
that
right,
yeah
yeah,
I
I
don't
remember
anyway,
I
I
I
wrote
that
one
down,
but
you
can't.
F
Yeah
has
to
keep
alive
the
registered
symbol,
because,
once
the
symbol
is
used
as
a
key
in
a
weak
map,
if
that
association
is
dropped,
since
the
symbol
can
be
regenerated,
it
can
be
observed
that
the
previous
association
was
dropped,
which
is
an
observe,
a
non-deterministic
observation
that
we
cannot
allow.
I
see
I
said
okay,
I.
C
C
Is
is
that
any
better?
Yes,
now
I
can
hear
you
yeah
there.
You
go
sorry,
one
too
many
microphones,
since
as
an
implementer,
I
thought
I
would
jump
in
so
the
earlier
comment.
Yeah
xs
absolutely
does
not
collect
symbols.
So
that's
an
addition.
The
the
conversation.
If
I
followed
it
correctly,
I'm
not
sure
I
have,
but
the
conversation
has
been
about
what
it
would
take
for
an
engine
to
collect
to
collect
symbols.
C
There's
one
part
of
that
that
I
that
I
think
we're
overlooking
and
again
at
least
from
xs's
perspective.
Is
that
not
only
does
it
matter
what's
observable
to
scripts,
but
it
matters.
What's
what's
observable
to
native
code,
because
native
code
can
create
a
symbol,
you
know
or
grab
onto
a
reference
to
a
symbol
and
it
can't
be
collected
until
that
is
also
cleared.
And
again
I
don't
know
other
engines
but
in
excess.
C
There's
certainly
no
way
today
to
express
the
fact
that
you're
holding
on
to
a
symbol,
so
that
would
have
to
be
added
as
well
to
allow
it
to
be
to
be
done
safely.
F
C
I
mean,
I
I'm
sure
it's
possible,
I
don't
know,
what's
what's
involved
in
in
doing
that,
but
but
it
said
it's,
the
the
tricky
part
is
that
if
they
do,
we
have
to
be
careful
with
native
code,
because
the
native
code
could
still
be
holding
a
reference
to
those.
So
it's
okay.
F
F
D
I
was
really
hoping
for
object
placeholder,
since
it
would
have
bypassed
all
those
concerns
and
we
would
have
a
new
type
to
do
this
specifically.
A
And
I
I
think
that
if
I
interpret
peter
correctly
by
not
a
light
undertaking,
I
think
it
means
a
breaking
change
to
the
ecosystem
of
native
code
right
that
there
would
be
existing
native
code
outside
of
the
modable
code
base.
That
would
need
to
be
updated
to
take
and
take
this
into
account.
C
Strictly
speaking,
yes,
the
practical
impact
of
that
may
be
very
small
just
because
we
don't
tend
to
do.
We
don't
tend
to
cache
simple
ids,
but
theoretically
could
be
done
so
yeah
we'd
have
to
look
at
it,
but
what
you
say
is
is
is
basically
true.
E
Usually
at
least
with
javascript
core
and
v8,
you
get
a
c
plus
handle
of
some
kind
and
the
c
plus
plus
handle
as
long
as
the
wrapper
kind.
Whatever
it
is
for
v8,
it's
called
the
local
or
a
different
kind
would
be
an
eternal
which
would
never
be
gc'd
or
persistent,
which
means
you
are
managing
the
lifetime,
whatever
the
rapper
kind.
It
requires
that
to
be
destructed
in
order
for
it
not
to
be
kept
alive
in
some
of
it.
Some
way.
E
For
v8
at
least
it's
all
three
of
those
depending
upon
what
you
want,
so
the
wrapper
kind
determines
the
garbage
collection,
semantics
held
and
so
yeah.
So
a
local
will
clear
when
the
scope
it's
held
in
is
destroyed,
standard
c,
plus,
plus
destructor
semantics
there.
E
The
persistent
will
hold
the
value
until
you
clear
it,
and
so,
if
you,
the
only
case
that
this
should
really
affect
would
be
a
local
and
since
local
is
clear,
when
you
kind
of
get
out
of
the
f
ffi
anyway,
I
don't
think
it's
affected
for
v8,
I'm
a
little
less
clear
on
js
object
from
javascript
core
and
how
that
would
work
semantically.
E
A
F
Okay,
so
let
me
let
me
state
a
hypothesis
that
okay,
the
the
controversy,
is
on
the
only
anonymous
symbols
as
keys
versus
the
all
symbols
as
keys
and
the
my
hypothesis
is
that
the
implementation
burden
for
either
choice
is
mild,
and
therefore
this
question
should
not
be
decided
on
implementation
burden
concerns.
It
should
be
decided
on
on.
You
know,
language,
semantics
and
user
complexity
at
least
surprise
concerns.
F
E
F
Yeah,
and
and
and
the
implementation
burden
here
would
be
a
registered
symbol.
That's
used
as
a
key
in
a
weak
map
would
have
to
not
be
subject,
would
have
to
to
not
be
subject
to
garbage
collection
or,
in
other
words,
a
weak
map
holding
a
registered
symbol,
as
the
key
is
effectively
holding
on
to
the
registered
symbol
strongly.
E
F
Hold
on,
if
they're,
in
a
key
in
a
weak
map,
the
the
any
situation
where
they
get
garbage
collected
where
the
weak
map
itself
is
still
live,
cannot
be
correct.
So
I
don't
believe
that.
D
Brad,
I
think
you
were
not
there
when
bradley
explained
his
use
case,
but
technically,
if
you
deny
the
realm
constructor
and
symbol,
4
and
e4,
you
have
no
way
of
unwrapping
or
recreating
registered
symbols,
and
if
you
delete
some
of
the
well-known
symbols,
the
ones
that
are
not
recreated
by
syntax
are
also
or
by
some
other
execution.
That's
not
denied
are
also
it's
also
impossible
to
recreate
them.
So
you
wouldn't
be
able
to
observe
them.
D
Yes,
if,
if
you
completely
deny
the
creation
of
a
realm
and
deny
the
symbol.4
in
your
current
realm
or
in
the
existing
realms,
there
is
no
way
to
recreate
registered
symbols.
F
F
F
E
Practical
usage-
I
hope
not,
but
it
does
change
at
least
what
people
might
be
expecting
for
finalization
handlers.
I
think.
F
I
think,
is-
is
no
one's
going
to
expect
garbage
collection
beyond
those
limits.
A
I
so
I
do
not
expect
that
we're
heading
toward
a
denouement
on
this
topic,
but
I
want
to
ask
the
group:
in
general,
we
have
15
minutes
left
and
alex
has
brought
forth
the
topic
of
broadcasting
revocability
to
multiple
proxies
simultaneously
is:
do
we
want
to
chase
this
one
to
the
ground
and
have
an
action
item
at
the
end
of
the
meeting,
or
would
we
like
to
entertain
alex's
topic
today.
D
Know
there
was
one
thing
I
I
we
didn't
really
touch
on
for
the
symbol.
It
was
with
my
key,
so
I'd
like
to
touch
on
it
really
quick
and
I'm
actually
surprised
bradley
you
didn't
bring
it
up.
Is
that
allowing
registered
symbols
as
a
weak
map
key.
In
my
opinion,
the
only
thing
it
allows
is
for
programs
to
shoot
themselves
in
the
foot
and
create
memory
leaks.
D
I
I
can't
imagine
an
actual
use
case
for
that
because,
as
we
said
like,
if
you
put
a
registered
symbols
on
weak
map
key,
you
have
to
hold
that
registered
symbol
alive
as
long
as
you're,
observing
it
through
the
weak
map
key
or
through
the
weak
ref.
So
that
means
you're
creating
a
leak
for
whatever
you
put
in
there.
It's
an
ineffective
map
instead
of
a
weak
map,
and
I
just
don't
know
why
we
would
want
to
allow
that
in
the
first
place.
F
So,
as
I
understand
it,
jordan
is
the
only
person
who's
who
continues
to
strongly
advocate
that
it's
either
all
symbols
or
no
symbols.
D
I
believe
so:
okay,
I'm
not
sure
if
other
delegates,
jordan
has
been
vocal
about
it.
I'm
not
sure
if
other
delegates
share
his
opinion
that
the
consistency
through
of
type
off
is
important.
F
Okay,
yeah
waldemar
would
be
a
good
one
to
try,
has
waldemar
stated
an
opinion.
B
It
might
be
good
to
check,
but
if
I
remember
correctly,
waldemar
was
not
fond
of
having
the
global
registered
symbols
and
well-known
symbols
used
as
weak
map
keys.
F
Okay,
so
so
you
know
so
my
just
summing
up
my
stance,
it
should
only
be
decided
from
the
user
perspective,
not
from
the
implementer
perspective
and
so
the
question
that
that
you
know
this
tension
between,
let's
say
matthew's
stance
and
jordan's
stance.
It's
perfectly
fine
to
to
think
about
that
from
the
user
perspective,
and
there
are
pros
and
cons
both
ways
and
altogether.
D
And
to
be
clear-
and
you
probably
missed
that
earlier-
I
I
think
we
should
introduce
a
predicate
to
allow
that
a
lot
of
testing
if
something
is
usable
in
a
in
a
weak
collection,
so
that
programs
can
switch
from
any
type
of
check
to
that,
because
that
will
be
useful
for
records
and
tuples
in
the
future
as
well.
E
D
In
it's
just
like
it's
cumbersome
to
do
a
try
catch
thing,
and
then
you,
if
you
don't
want
to
leak,
you
should
already
put
in
a
weak
set
and
delete
it
right
away
and
it
it's
doable
in
user
land.
But
I
think
we
should
just
provide
it
in
the
language.
A
All
right,
let's,
let's
at
least
give
alex
five
minutes
to
give
us
a
taste
of
what
we're
likely
to
be
talking
about
at
the
beginning
of
our
next
meeting.
G
Thank
you
chris
just
this
is
basically
following
up
on
the
idea
that
mark
pitched
last
april
april
2021.
he
pitched
a
realm.prototype.revoke
idea.
Can
everyone
hear
me
yeah,
okay,
my
system's
misbehaving
and
I
thought
about
it
and
it's
been
mulling
in
the
back
of
my
head
for
a
while
and
I'm
thinking,
maybe
we
can.
We
can
actually
improve
on
that
idea
by
having
a
a
revoker
set.
G
Constructor
hung
off
of
proxy,
where
the
idea
being
you
could
have
a
revoke
all
method,
that's
available,
and
then,
if
we
had
an
array
of
revoker
sets
that
we
could
pass
and
do
proxy.replicable
the
revoker
sets
would
each
get
a
reference
to
that
revoker
right
off
the
bat
and
then
anytime
you
wanted
to
revoke
the
proxies
in
a
particular
set.
You
called
the
sets,
revoke,
dot,
dot,
revoke
all
method,
and
I
think
that
mark's
idea
is
wonderful.
I
think
it's
fantastic,
I'm
just
trying
to
see.
G
Well,
maybe
this
this
can
go
on
the
main
proxy
part
of
the
spec
and
maybe
not
wait
for
realms
on
that.
One
don't
get
me
wrong
again.
I
think
the
realm
idea
is
wonderful
and
should
definitely
be
followed
up
on.
F
Okay,
so
alex
first
of
all,
thank
you
for
keeping
the
idea
alive.
You
actually
remember
it
much
better
than
I
do
the
could.
Could
you
have
like
a
a
draft
api
sketch
for
next
meeting
or
maybe
to
circulate
ahead
of
next
meeting.
G
I
can
try
to
work
up
something
over
the
weekend.
Yeah.
E
E
F
Alex,
if
you,
if
the
api
you
have
in
mind,
is
not
along
the
lines
of
what
bradley
suggested.
Let
me
suggest
that
bradley
wanted.
If
you
could
sketch
an
api
along
those
lines,
and
then
we
can
have
both
of
those
to
to
contrast
at
the
next
meeting.
E
G
I'll
have
to
rewatch
the
recording
literally
my
my
system
crashed
over
the
last
two
minutes.
D
I
I
think
bradley
was
saying-
and
I
was
I
was
gonna
say
the
same-
maybe
look
at
a
board
controller
and
make
it
similar
so
that
you,
the
ability
to
abort,
is
different
from
the
ability
to
from
the
capability
of
being
linked.
G
F
So
so,
in
that
case,
I
really
think
it's
best,
if
alex,
if
you
sketch
out
the
api
that
that
you
have
in
mind,
ignoring
a
board
controller
and
bradley
sketch
out
an
api
that
is
based
on
a
board
controller
or
or
along
the
lines
of
what
bradley
has
in
mind
and
being
able
to
look
at
both
of
them.
I
think
would
be
great.
A
Okay,
well
that
settles
what
our
what
we'll
begin.
The
next
meeting
with
next
meeting
is.
The
next
meeting
is
the
last
opportunity
to
discuss
topics
before
plenary.
So
if
there's
something
that
you
wish
to
get
onto
the
agenda,
it's
a
good
time
and
with
that
I
think
that's
a
cess
meeting
I'll
take
us
off
recording.
Thank
you.