►
Description
Mathieu Hofman shares a chain of complications to boxes within records and tuples that force a design decision between a memory leak hazard and a correctness hazard for existing code.
A
All
right
welcome
to
the
assess
meeting.
Today's
topic
is
records
tuples
and
boxes
with
the
long
awaited
quorum
of
matthio,
nicolo,
daniel
and
mark,
and
so
that's
the
topic
for
the
day
unless
it
runs
short
and
other
people
with
more
topics
arrive
in
the
during
the
discussion.
So
take
it
away.
Mateo.
B
All
right,
so,
a
few
weeks
ago
mark
and
I
were
discussing
what
the
boxes
inside
recording
tuples
would
work
with
realms
and
through
membranes,
and
I
tried
to
capture
some
of
that.
I
actually
threw
together
a
few
slides
to
make
it
a
little
bit
more
visual,
because
it's
it's
a
little
bit
hard
to
follow
those
things
without
like
something
to
reference.
B
I
did
that
very
quickly,
so
please
don't
shoot
the
quality
of
it.
But
let's
share
my
screen.
Okay,
so.
B
So
first
I
I
wanted
to
recap
like
a
little
bit
of
what
we
discussed
before,
which
is
the
hazard
of
having
mutable
state
inside
a
primitive
and
really.
It
boils
down
to
the
fact
that
there
is
a
lot
of
code
out
there
that
checks,
if
something
is
a
an
object.
That
being.
B
Today,
yeah
here
we
go
sorry
missed
one
check
if
something
is
an
object
or
a
function,
which
is
also
an
object
and
basically
doesn't
do
any
processing
for
it,
because
it's
something
that
that
will
never
change.
They
will
never
change
and
doesn't
contain
anything
nested,
but
if
it
is
probably
gonna
recurse
in
it
and
try
to
figure
out
like
hey,
where
are
all
the
properties
or
or
the
indexes
for
the
array
and
and
so
on,
membranes
do
that.
B
But
there
is
a
lot
of
other
code
that
does
it
like
I've
done
it,
for
example,
for
logging
errors.
If
I
get
an
object
you
go
in
and
you
you
recurs
it
and
so
on.
Another
example
is
like
a
to
jason
or
the
reviver,
or
something
like
that.
So
the
problem
is
that
if
the
type
of
of
the
record
or
tuple
is
not
an
object,
then
existing
code
wouldn't
know
to
to
go
in
and
then
and
recurse
those
those.
B
Those
are
those
object-like
things
and
if
you
have
a
box
in
it,
it's
really
dangerous,
because
now
it
actually
can
create
a
communication
channel
that
might
have
been
unexpected
in
the
case.
For
example,
of
a
membrane,
if
the
membrane
is
just
trying
to
like
the
same
real
membrane,
trying
to
isolate
two
object
graphs
now
you
would
be
able
to
like
just
pass
immutable
data
through.
C
Matthew
just
notation:
what
is
dollar
open
square
bracket
supposed
to
mean.
B
I
think
it
probably
messed
up
the
whole
notation
for
records
and
tuples.
What
is
a
short
notation
again.
D
B
Very
quick
yeah:
where
is
the
replacement,
and
is
there
fine
dollar,
replace
with
hash
and
replace
all
done
cool
that
will
fix
it
presents
cool
that
will
actually
feel
better.
I
said
first
stupid
thing.
I've
done
so
cool.
B
So
to
avoid
this
hazard,
one
option
that's
been
brought
forward
is
having
a
record
in
tuples
as
identity-less
objects,
so
basically
what
it
means
that
the
type
of
the
recorder
tuple
would
be
object.
B
B
What
happens
in
the
case
of
minus
zero?
Like
we,
I
believe
some
of
the
discussions
want
to
have
a
minus
zero
inside
a
record
tuple
being
triple
equal,
but
that
should
be
the
same
object.
If
what
does
it
mean
to
have
in
the
case
of
an
identity
object?
That
is
false.
B
Right
so
that
means
you
cannot
create
the
same
objects
when
you
do
so.
This
is
where
it
becomes
a
little
weird,
because
now
it
means
an
object,
something
that
has
type
of
object.
The
semantics
of
triple
equal
is
different
with
the
semantics
of
the
object.is,
which
might
be
a
hazard
on
its
own.
So
this
is.
B
B
Right,
I
would,
and
this.
E
Yeah,
so
I
I
mean
if
you
want
to
go
on,
that's
fine,
but
I
would
like
I
mean
if
you
consider
this
to
be
a
big
problem.
I
would
like
to
understand
more
about
why.
B
I
I'm
just
pointing
it
out
right
now,
I'm
like
currently
for
something
that
is
type
of
objects,
the
triple
equal
and
objectives,
I
believe,
will
always
be
the
same.
Where
here
we're
saying
that
now
these
special
objects
would
have
a
different
behavior
here.
B
So,
let's
get
to
the
gist
of
it
and
which
is
the
interactions
of
recurring
temples
with
realm.
What
happens
when
you
pass
a
record
couple
through
the
callable
boundary,
as
currently
proposed
for
realm?
B
Well,
first,
on
the
second
line
here,
we're
assuming
here
there
they
would
be
passable
because,
or
else
I
mean
they
would
be
completely
useless
and
and
not
any
different
than
they
wouldn't
be
any
different
than
regular
objects
which
which
is
an
option,
but
that
has
all
their
applications
as
I'll
show
later
so
here
this
is
like
both
valid
for
either.
B
If
we
decide
to
go
for
a
primitive
for
an
identity,
yes
object,
I
think
we
want
these
properties
from
from
records
and
tuples
being
passable
through
the
callable
boundary,
which
means
the
prototype
of
a
recorder.
Tuple
is
the
observable.
Prototype
is
the
one
from
the
the
realm
observing
and
we
decided
that
this
wasn't
really
a
concern
either
for
primitive
or
identity-less
subjects.
B
I
this
was
my
assumption.
I
I
I'm
not
sure
if
anyone
has
any
concern
with
those
assumptions.
D
B
Okay,
so
now
we
get
to
the
fun
of
adding
boxes
to
do
this,
if
you
try
to
send
a
tuple
that
has
a
box
in
it
that
contains
an
object.
Well,
I
think
we
all
agree.
That
should
be
a
type
error,
where
it's
a
little
less
clear
is.
If
you
try
to
send
a
box
that
has
something
that
is
not
an
object.
If
it's
a
primitiveness
or
recursively
only
primitive
should
you
be
able
to
send
that
to
the
collarbone
boundary
or
not.
B
E
Yeah,
this
is
something
that
jordan
asked
for
I'm
personally
a
little
undecided
on
whether
there
is
much
utility
here.
I
think,
if
we
make
this
predicate,
I
mean
one
big
thing
that
we've
been
talking
about
with
boxes,
having
a
predicate
to
see
if
something
recursively
contains
a
box.
E
E
F
Just
to
be
clear,
I
think
boxing
primitives
complicates
things
fatal,
but
it
would
be
good
to
understand
the
use
case
because,
to
my
knowledge,
there's
no
actual
use
case
for
boxing
a
primitive.
F
E
E
F
In
strict
code,
I
can
attach
data
to
objects,
essentially
through
a
side
channel
via
map
or
weak
map
for
a
map.
It's
okay
for
primitives
with
weak
map.
That's
not
true!
So
you
get
into
a
case
where,
whenever
you
box
something
partially
because
you
may
want
to
send
it
somewhere
or
do
something
like
that,
I'd
presume
you
would
want
to
use
a
weak
map
generally.
B
I'm
getting
to
the
I
have
the
question
of
weak
map,
a
weak
collection,
interaction
with
boxes
a
little
bit
later,.
E
D
By
the
way,
the
reason
that
we
currently
allow
the
primitives
to
be
put
inside
of
boxes
is
so
that
you
can,
and
at
least
different
people
ask
to
be
able
to
write
general
purpose
code
where
you
do
not
need
to
like
branch
and
check.
If
you
have
a
primitive
or
an
object
and
you
can
just
box
whatever
you
get
and
then
you
can
unbox
it
and
return
that
box
and
then
unbox
thing
to
the
user.
F
B
Yeah
and
and
more
specifically,
a
identity
bearing
object
if
we
have
realms
or
tuples
as
identity-less
objects.
B
Yeah,
so
just
to
keep
in
mind
box
can
currently
contain
anything,
including
other
boxes,
so
you
can
have
box
of
your
records
with
boxes
in
it
with
box
box
box.
You
can
do
whatever
you
want
all
right,
so
here's
a
little
bit
of
what
would
happen
if
you
need
to
send
a
record
or
tuple
to
another
realm.
Well,
first,
does
it
contain
a
box
at
all?
Hopefully
you
can
just
send
it,
as
is.
B
Is
there
any
box
that
recursively
contain
any
identity
bearing
objects,
which
is
the
check
you
were
talking
about,
then
in
that
case,
if
the
callable
band
array
allows
it,
we
would
just
be
able
to
send
it,
as
is
the
the
same
way.
B
If
not,
then
you
can
send
your
recorded
tuple
through
the
callable
battery,
so
you
need
to
start
deconstructing
deconstructing
it
and
and
replace
all
the
places
where
you
have
an
identity,
bearing
object
and
and
create
a
proxy
for
those.
So
you
go
and
you
need
to
create
a
proxy
for
all
those
identity,
bearing
objects.
B
You
need
to
remove
them
and
or
put
a
placeholder
or
null,
let
them
out
or
something
like
that,
so
create
a
new
record
tuple,
potentially
going
through
all
the
boxes
in
them
doing
that
recursively
and
and
then
send
all
that
placeholder
simplified
record
tuple
over
the
realm
boundary
that
can
now
be
transferred
and
with
the
location
of
where
all
those
proxies
that
were
created
actually
belong
to,
and
then
the
other
realm.
B
You
get
all
that
information
and
you
recreate
a
different
record
tuple
that
has
boxes
containing
the
proxies
for
the
object
instead
of
the
objects
wherever
those
were
before.
So
this
is
actually
pretty
complex.
You
alternative
is
just
not
do
any
of
it.
If
you
get
a
recorded
tuple
and
it
is
behaving
like
an
object,
just
put
a
membrane
in
front
of
it
and
then
we've
lost
the
advantage
of
recording
tuple
as
a
complex
data
structure
that
can
be
shared
across
the
realm
binary.
B
Does
that
make
sense
for
people
that
might
not
be
fully
familiar
with
how
membranes
work
and
how
passing
things
to
between
realms
work.
D
I
think
that
even
like
just
putting
a
membrane
over
the
wall,
thing
means
that
you
have
to
like
easily
iterate
the
t
record
because
it's
like,
if
you
will
into
a
frozen
object.
So
so
you
I
mean
I
don't
know
much
about
membranes.
But
I
remember
that
when
you
have
a
frozen
object,
you
must
create
like
you,
cannot
use
an
empty
shadow
target
and
you
must
create
a
whole
thing
like
eagerly.
B
Because
of
the
prototype,
yes,
I
think
one
of
the
hopes
was
that
records
and
tuples
could
be
used
as
to
represent
data
structures
without
having
to
worry
about
like
leaking
the
intrinsics
from
another
realm.
E
I
sorry
I'm
really
confused
by
this
conversation.
The
the
slide
here
does
correspond
to
what
I
expected
the
behavior
for
for
records
and
tuples
to
be
we,
you
know
when
we
talked
about
this.
I
can't
remember
it
was
some
months
ago
or
maybe
a
year
ago
about
membranes
and
records
and
tuples
the
the
thought
was.
I
think
I
mean
this
was
even
before
box
was
being
added.
E
E
So
if
someone
was
hoping
that
records
and
tuples
would
kind
of
solve
this
problem,
then
I
don't
I'm
not
sure
exactly
what
the
problem
is,
and
I
don't
know
how
it
would
solve
it.
I
do
think
that
it's
okay,
if
records
and
tuples,
are
only
improving
passing
things
across
a
membrane
in
the
case
that
you're
not
using
a
box
to
to
hold
an
identity,
look
an
identity,
bearing
object,
that's
a
it's
a
restriction,
but
I'm
not
sure
if
it
negates
the
benefit
of
of
having
box
and
and
identity
bearing
objects.
B
I
just
want
to
make
observation
that
this
this
was
a
constraint
either
you
have
to
eagerly
traverse
and
and
and
mutate
your
and
create
another
record
tuple
that
has
the
same
structure
without
the
the
objects
in
it
or
you
have
to
just
consider
it
treated
it
as
a
regular
objective
pass
through
and
put
a
membrane,
and
so
that
you
avoid
the
eagerness
of
going
through
the
the
whole
record
level.
E
E
G
Yeah,
so,
first
of
all,
I'm
sorry
everyone,
I'm
not
in
a
good
mood
to
extend
all
of
this,
but
I
think
most
of
what
being
discussed
here
involves
like
creating
a
mechanism
to
what
I've
seen
called
as
like
structural
cloning
in
for
for
transferred
object
likes
or
anything.
We
call
like
that
in
in
realms.
I
I
thought
I
fully
understand
the
problem
and
the
desire
to
to
solve
that.
G
G
B
So
the
reason
I
wanted
to
bring
this
up
like
is
is
just
I
I
just
want
to
show
like
different
approaches.
You
could
take
if
you
on
how
to
handle
realms
and
records
and
tuples
when
going
when
sending
them
through
the
color
ball
bendery,
so
that
either
you
put
a
full
membrane
or
or
you
try
to
to
process
and
and
just
so
people
have
a
better
idea
of
the
what
would
need
to
happen.
B
B
All
right,
so,
how
would
record
and
tuples
work
with
a
proxy?
Can
it
be
the
target
of
a
a
and
especially
what
happens
if
you
actually
have
a
the
target?
That's
actually
really
in
a
different
realm.
What
you
usually
do
is
that
you
create
a
placeholder
target
for
for
that
in
in
in
your
realm
and
and
and
you
replicate
the
operations
through
the
the
realm
binary.
So
I
guess
that
means
like
identity
subjects.
We
need
to
be
able.
B
If
we
go
for
identity,
subjects
like
they
would
need
to
be
able
to
be
the
target
of
a
of
epoxy,
that's
pretty
much
a
given,
or
do
we
allow
putting
a
regular
identity
bearing
object
in
in
its
place,
and
the
other
thing
is
that
like
how?
How
similar
does
the
id
identity
subject
need
to
be
to
the
real
target
when
you
make
a
when
you
have
an
operation?
So,
for
example
like
what
happens
to
boxes,
they
probably
can't
be
there.
B
B
I
think
danny
mentioned,
that,
like
a
membrane,
eagerly
needs
to
traverse
the
object.
I
I
don't
think
that's
true
like
when
you,
when
you
have
a
a
membrane,
usually
you
create
a
proxy
for
the
object
you
pass
and
then
it's
only
when
you
reach
into
one
of
the
properties
that
you
actually
create
a
new
proxy
for
whatever
property
you
access,
so
that
this
is
one
difference
with
the
records
and
tuples
like
you
might
need
to
yearly
traverse
and
stop.
When
you
reach
a
box
or
something
like
that,.
F
E
So
I
wanted
to
speak
to
that.
I
looked
into
making
it
so
that
records
and
tuples
could
be
a
proxy
target,
and
karadi
explained
to
me
that
this
just
doesn't
work
at
all,
because
the
way
that
proxies
are
often
used
is
with
a
shadow
target
where
the
handler
closes
over
some
stuff,
and
you
know
I
could
kind
of
imagine
proxies
of
records
and
tuples
with
equality
based
on
you
know.
E
If
the
handler
is
equal
and
the
target
is
equal,
but
this
just
doesn't
work
at
all
with
you
know
these
kinds
of
patterns
with
with
shadow
targets.
Overall,
I
think
we
just
shouldn't
have
proxies
of
records
with
records
and
tuples
as
their
targets.
That's
what
even.
B
If
they're,
even
if
their
identity,
less
yep.
B
So
going
back
to
the
previous
slide,
you
can't
put
a
membrane
over
a
record
tuple.
You
have
to
eagerly
go
in,
including
digging
into
all
the
boxes
until
you
reach
a
a
box
until
you
reach
an
identity
bearing
object
and
eagerly
create
all
the
proxies
for
those.
D
B
E
Then
that's
that's
what
I
mean,
and
so
this
was
where
the
discussion
got
to
last
time,
where
I
guess
I
came
away
with
the
misunderstanding
that
this
ended
up
having
to
happen
for
proxies
over
frozen
objects.
B
The
other
very
related
implications
actually
with
the
the
weak
collections,
so
this
transformation
of
a
couple
containing
a
with
a
nested
identity.
Bearing
object,
it's
expensive,
you
need
to
traverse
it
go
in,
pluck
out
all
those
replace
it
with
a
placeholder
or
holding
them
out,
and
you
need
to
do
that.
Actually
in
both
directions
or
maybe
not-
you
actually
can
do
that
at
least
in
one
direction.
B
B
So
at
the
very
least,
it
means
that
some
of
those
record
tuples,
at
least
the
ones
containing
identity
bearing
objects,
need
to
be
usable
as
weak
map
keys,
or
else
you
just
end
up
having
to
to
do
this,
the
same
processing
over
and
over
when
you
need
to
transform
one
of
those
record
tuples
to
one
that
doesn't
that
can
be
transferred
over
the
the
callable
boundary.
E
E
Agree
about
this
part,
I
think
our
our
plan
is
that
records
and
tuples
can
be
weak
map
keys
as
long
as
they
contain
an
identity
bearing
object
and
the
liveness
would
be
defined
as
the
whole
thing
is
live
if
all
identity
bearing
objects
included
in
it
are
live
and
the
to
close
out
the
previous
topic,
nicolo
wrote
an
interesting
gist
of
it
that
really
looked
into
detail
on
this
kind
of
decision
space
about
membranes,
and
it
would
be
great
to
have
your
review
and
I
guess,
support
from
people
who
know
more
about
membranes
than
me
to
to
work
through
that
previous
proxy
issue.
E
I
think
there
it
that
that
issue
is
pretty
independent
of
whether
we
have
identities,
objects
or
primitives.
It's
just
about
this
being
a
nested
data
structure
that
might
have
objects
in
it
with
box.
Right
anyway,
does
does
this
suggestion
for
records
and
tuples
and
weak
collections
solve
the
issue
that
you
have
on
this
side.
B
I
think
I
I
don't
have
any
issues
per
se.
It's
just.
I
wanted
to
raise
all
the
the
complexities
that
the
the
this
breaks.
Basically
there
there
is.
So
if
you
allow
records
and
couples
that
contain
an
identity,
bearing
object,
what
happens
if
they
also
contain
symbols,
I
mean
we
are
currently
not
allowing
symbols
as
weak
mac
keys.
So
I
I
know
they
wouldn't
be
it's.
It
would
be
fine,
since
it's
not
the
only.
E
In
this
case,
I
think,
if
you
put
in
a
record
or
tuple
into
a
into
a
weak
map
which
had
an
object
in
it
and
also
had
a
symbol
well,
the
engine
would
be
free
to
collect
it
if
the
symbol
dies
and
it
would
also
be
free
to
force
the
symbol
to
stay
alive
forever.
I
mean
engines
are
always
free
to
not
ever
do
any
garbage
collection.
So
I'm
not
sure
if
that
adds
any
kind
of
complexity.
B
I
mean
all
those
those
are
all
the
things
I
basically
thought
about.
I
I
wasn't
aware
of
the
discussions
you
already
had
with
a
charity
and
on
and
basically
all
the
same
findings
you
you've
already
had
on
on
this.
E
B
How
can
you
cache
it
without
being
able
to
put
it
in
a
weak
collection.
F
So
you
can
do
this.
I
do
this
in
my
richard
keys,
polyfill,
you
basically
take
all
the
identities
and
you
make
weak
maps
of
all
the
weak
parts
and
then
you
try
to
traverse
down
it
and
then
all
the
strong
parts
are
nested
as
leafs
within
your
weak
map.
Try
and
then
you
have
a
strong
connection
there
and
you
can
use
back
graphs
all
the
way.
B
But
for
that
you
need
to,
I
mean,
I
think
my
my
concern
is
like
you
get
a
a
random
recorded
tuple
in
that
that
means
you
need
to
go
in
and
traverse
it
to
figure
out
all
the
identity,
and
that
can
be
pretty
expensive
as
we've
seen,
because
it
can
be
nested
deeply
or
I.
F
E
E
I
guess
a
lot
of
the
the
concern
has
to
do
with
linear
time
operations
here
and
in
in
membranes
in
general,
not
being
not
being
acceptable.
Alex
wrote
something
in
the
chat
about
that
as
well,
and
I
guess
I'd
be
curious
to
learn
more
about
that
yeah.
It
all
comes
back
to
what
the
what
the
requirements
are
in
general.
The
equality
operation
is
expected
to
be
linear
time
for
records
and
tefls.
E
E
Ways
that
it
could
be
kind
of
usually
faster
than
linear
time,
but
there's
going
there's
expected
to
be
a.
I
mean
this
usually
works
by
techniques
like
interning
or
or
hash
codes,
but
sometimes
things
are
equal,
but
they
don't
get
interned.
We
don't
expect
interning
to
happen
all
the
time
for
everything
or
even
maybe
initially
at
all,
and
so.
E
B
Seems
fine
to
me,
I
I
believe
it
would
be
a
problem
if
you
allow
any
record
and
tuple,
including
ones
that
can
be
forged,
because
that
can
that
means
you
would
be
able
to
leak
data
slight
concern.
E
B
Exactly
if
they
don't
contain
any
identity,
bearing
objects,
you
it's
it's.
Actually,
it's
a
very
similar
problem
to
registered
symbols
being
usable
in
in
in
weak
map,
keys,
you'll,
just
leak
data.
As
long
as
that
map
weak
map
is
around
and
for
a
weak
map
used
for
a
membrane.
That
means
roughly
forever.
E
B
Right,
no,
it's
not
basically
a
problem,
it's
just
a
decision
that
has
to
be
made
on
whether
to
allow
as
weak
collection
keys,
something
that
can
be
created
by
forgeable
data.
It's
it's.
B
E
Suggest
that
I'm
not
I'd
suggest
not
making
any
particular
restriction
with
respect
to
forged
objects,
because
I
can't
because
some
objects
are
pretty
likely
to
always
be
available
like
a
readout
prototype.
But
I
think
we
should
just
continue
to
allow
them
to
be
the
identity
bearing
element
in
the
weak
map.
Key
for
for
record
or
tuple.
E
I
do
you
have
an
example
of
something
that
you
think
should
be
omitted,
because
I.
B
Don't
know
why
you're
not
understanding
you,
no,
I'm
actually
of
the
opinion
that
we
should
allow
any
kind
of
object
in
them,
but
I
know
it
was
a
concern
that
was
raised,
so
I
just
wanted
to
raise.
That
is
the
exact
same
issue
as
registered
symbols,
allowing
them
as
weak
map
keys
or
not.
D
Just
to
be
sure
that
an
understanding
so
like
if,
for
example,
I
have
an
empty
record,
is
anyone
saying
that
we
should
be
able
to
put
an
empty
record
as
a
wikimaki?
Oh
we're
not
talking
about
that.
E
B
Oh
I'm
confused.
I
thought
you
were
saying
that
we
should
allow
it
that
any
object
should
be
allowed,
as
we
make
my
keys
in
including
ones
that
are
affordable.
E
I
understand
what
you
meant
right
now.
I
was
trying
to
ask
for
an
example
of
a
forgeable
object
and
you
were
saying,
for
example,
an
empty
record,
so
I
would
say:
no
you
have
to
contain
an
identity,
bearing
object
to
be
usable
as
a
weak
map.
Key.
Maybe
that's
how
we
were
talking
past
each
other
before.
B
Yeah,
so
now
what
I
mean
is
so
what
I
want
to
say
is
that
this
might
become
a
hazard
if
we
use
that
ntls
object,
because
type
off
is
objects
and
the
program
might
be
surprised
if
they
don't
know
about
records
that
they
are
not
allowed
to
put
these
kind
of
objects
in
in
a
weak
collection.
E
C
I'm
I'm
I
want
to
make
the
radical
suggestion
that
we
should
that,
with
the
with
the
registered
symbol
debate
as
kind
of
a
precedent,
the
radical
suggestion
is
that
we
should
just
completely
drop
the
current
restriction
on
where
weak
map
keys,
reject
things.
That
map
keys
accept
that
as
soon
as
we
allow
the
weak
map
keys
to
to
leak
and
to
just
be
garbage
collection
or
best
efforts
basis
that
you're
in
for
a
penny
in
for
a
pound,
once
we
say
well
weak
maps,
don't
necessarily
collect
everything
you
put
in
them.
C
F
So
so
this
is
the
fear
I
have
working
at
a
company
where
I
largely
spend
time
debugging,
cpu
profiles
and
memory
leaks.
I
don't
want
things
without
identity
or
garbage
collection
semantics
to
go
into
these
collections.
Normally.
C
Well,
I
mean
the
thing:
is
it's
it's
strange
to
allow
a
composite
that
happens
to
have
an
identity
bearing
object
as
a
key
and
reject
one
that
has
that
that
doesn't
have
one,
because
it
just
means
that
there's
this
I
mean
it
makes
sense
from
a
garbage
collection
perspective.
So
I
understand
that
that,
but
it's
from
a
it
has
the
same
programming
uniformity.
C
C
There
was
one
the
position
that
I
had
when
the
weak
map,
when
the
symbols
as
weak
map
keys
first
arose,
is
that
it
should
only
be
unregistered
symbols,
so
they
can
still
be
garbage
collected
and
the
registered
symbols
would
just
cause
forever
leakage
and
the
counter
argument,
which
I
eventually
accepted,
is
that
yeah,
but
but
when
you're
dealing
with
symbols,
generally,
you
don't
really
most
code
that
deals
with
symbols
doesn't
really
distinguish
whether
it's
registered
or
unregistered,
so
is
the
protecting.
C
Is
the
code
being
defensive
against
the
false
against
the
the
rejection,
a
bigger
or
smaller
software
engineering
cost
than
suffering
the
leakage?
C
And
so
I
think
that
the
same
thing's,
true
with
regard
to
records
and
tuples
that
either
view
or
do
not
contain
identity
bearing
objects,
if
the
ones
that
do
not
contain
identity
bearing
objects
are
rejected.
That
seems
to
me
very
similar
to
the
pain
of
rejecting
registered
symbols,
and
I.
E
E
Sorry
for
being
confused,
I
think
it's
kind
of
a
more
salient
difference
to
how
you
use
records
and
tuples
to
be
checking
whether
it
contains
an
identity
bearing
object.
I
think
it's
more
of
a
front
of
mind
thing
than
when
dealing
with
symbols.
Maybe
that's
a
weak
argument.
F
If
you
give
something
that
does
not
have
garbage
collection
semantics
that
is
able
to
be
forged
purely
through
some
kind
of
literal
computation,
you
encounter
cases
where
you
can't
discover
you
have
a
memory
leak
until
it's
a
problem.
F
When
you
throw
an
error
early,
I
can
see
that
I
am
leaking
memory
and
I
might
be
doing
it
intentionally.
There
are
cases
where
you
want
to
do
that.
C
F
F
Correct
yeah,
but
you
can't
this
the
key
here
is:
you
can
proactively
discover
this
semantic
that
you
are
going
to
forever
keep
something
in
memory,
rather
than
waiting
for
your
server
to
crash.
F
If
there
was
a
way
to
discover
more
readily
that
you
are
leaking
memory,
it
seems
reasonable
that
we
could
allow
values
without
garbage
collection
that
are
forgeable
in
these
weak
collections.
But
without
it
we
are
for
the
most
part,
in
my
experience,
debugging
other
team's
code,
just
inviting
memory
leaks
that
wait
until
production,
which
is
normally
when
I
get
called,
has
problems.
C
A
C
Okay,
so
so
so
it
does
argue
that
against
registered
symbols
being
weak
back
keys.
B
My
main
concern
here
is
somewhat
again
compatibility
with
the
existing
code.
Somebody
might
be
like
checking
type
of
object,
oh
cool.
I
can
just
stick
it
in
a
stick
it
in
a
weak
map,
and
now
that
would
start
throwing.
C
A
C
I
I
can
certainly
confirm
you
know
matthews
thing
about
existing
code.
That
says
oh,
if
it's
type
of
object,
then
I
can
use
it
as
a
weak
map.
Key
I've
certainly
written
that
code.
Many
times.
F
So
touching
on
a
another
kind
of
tangential
related
thing:
how
would
this
work
with
private
fields?
I'm
assuming
we
always
fail
to
install
private
fields
on
these.
B
Oh
with
the
return
this
thing
yeah.
E
E
E
E
So
I
would
probably
say
that
you
could,
if
we
do
that,
then
we
would
only
allow
private
fields
to
be
declared
in
records
and
temples
in
their
literal
in
their
record
literal.
E
C
In
general,
if
you're
in
the
lexical
scope,
where
the
name
is
defined
but
you're
using
it
on,
you
know,
you
know,
base
dot
pound.
F
E
That's
but
really
disagreements
about
the
particular
thing
that
mark
is
getting
at,
I
think,
is
what
is
holding
this
proposal
back,
that
we
just
can't
find
an
agreeable
way
that
this
could
kind
of
be
used
at
all.
I
think
it
would
be
good
to
include
this,
at
least
for
object
literals,
with
the
idea
that
an
object
literal
does
not
create
its
own
kind
of
fresh
private
scope
in
the
way
that
class
literal
does.
E
D
B
I
think
the
hazard
here
is
recurring
temples,
as
identities.
Objects
to
be
useful
through
membranes
would
require
being
at
least
a
subset
being
usable
through
weak
collections,
and
it
might
become
a
hazard
to
if
we
don't
allow
all
of
them
and
memory
leaks
to
memory
leaks.
So
we
have
to
pick
our
hazard
either
memory
leaks
or
existing
code,
throwing.
F
F
B
It's
it's
a
pretty
obvious
memory
leak.
If
you
put
something
in
a
collection
that
can
be
can
be
forged
and.
F
E
The
record
and
temple
champions
are
not
proposing
to
create
this
leak,
so
I
think
I
I
guess
I
wanna.
Maybe
this
was
a
really
good
presentation
and
I
think,
maybe
next
week
we
should
continue
to
to
talk
about
these
issues.
It's
really
good
to
have
these
on
the
table,
and
then
next
week
we
can
talk
about
what
we
want
to
do
with
them.
C
C
A
Y'all
right,
thank
you.
I'm
gonna
stop
the
recording.