►
From YouTube: SES-mtg: Records and Tuples, part 1
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
I'd
really
like
to
hear
about
register
registers,
records
and
tools.
C
I
I
I
like
to
know
a
little
bit
more
about
what
happened
last
week
on
the
meeting
about
security.
I
I
didn't
get
a
chance
to
look
at
the
notes.
I
don't
know
there
is
a
recording
of
that
just
just
to
know
what
the
outcome
of
that.
D
There
there
are
minutes
taken.
I
can
send
you
a
link
to
the
to
the
notes.
I
guess
they'll
be
posted
online
soon.
Let
me
find
it,
but
my
understanding
of
the
outcome
was
more
or
less
that
you
know
these.
Multiple
positions
were
articulated
with
browsers
articulating
this
position
that
it's
important
to
not
have
too
many
hooks
into
things,
because
it
can
make
it
hard
to
implement
things
correctly
and
without
sort
of
correctness
or
buffer
overflow
kind
of
that
class
of
security
problems
and
other
people
more
with
ideas
from
from
this
group
were
were
saying.
D
E
Yes,
it
is
about
possibly
creating
a
security
task
group
within
tc29,
because
there
are
probably
things
there
like
too
many
things
are
within
the
scope
of
scs,
and
there
are
things
that
might
be
not
only
in
the
scope
of
scs
so
and
there's
a
discussion
on
the
reflector
right
now
about
creating
a
task
group
to
discuss
security,
and
there
is
definitely
interest,
especially
from
mark
miller,
to
use
this
task
group
or
consider
this
task
group
to
discuss
scs
or
the
topics
that
we
usually
discuss
here.
D
I
think
it
would
be
best
to
maintain
this
poll
is
separate
from
the
security
call,
because
this
call
is
opinionated
towards
focusing
on
this
object
capability
approach
to
security,
and
I
you
know-
and
I
find
it
really
useful
to
have
discussions
in
that
frame
and
I
think
the
security
tg
will
start
with
more
basic
questions.
D
You
talked
about
priority,
you
know
explicitly
putting
pitting
the
implementation
correctness
against
the
these
feature.
Requests.
E
Yes,
and
and
for
that,
I
think
we
should
have
a
like
a
new
discussion
about
this
task
group
creation
etc.
When
we
also
have
mark
miller
present
here,
because
it's
important
that,
like
we
have
mark
miller
and
like
feedbacks
on
on
that,
like
what
he
wants
for
his
understanding
over
that,
like
that's
group,
even
if
we're
considering
a
test
group,
a
former
task
group
for
ses
as
well.
E
Unfortunately,
there
were
there
were
no
time
available
to
discuss
this
with
mark.
I
was
expecting
to
see
mark
today
here
my
bad,
but
we
we
probably
should
have
mark
on
board
of
this
discussion
too.
F
Yeah
mark
is
deep
in
some
crunch
mode
coding
right
now,
the
yeah,
the
the
impression
that
I
got
was
that
mark
was
open
to
dissolving
this
meeting
in
favor
of
creating
the
task
group
in
order
to
because
I
think
that
the
intention
is
that
everybody
who
is
here,
who
would
want
to
be
in
that
meeting
in
the
task
group
and
that
having
another
meeting
every
at
whatever
interval,
would
probably
be
onerous
for
the
participants.
F
D
F
F
All
right,
all
right
daniel,
would
you
like
to
take
it
away
with.
I
I
mean
chip.
I
believe
you
also
expressed
an
interest
in
records
and
tuples.
B
Yeah,
I
don't
have
any
particular
opinions
to
express
here,
other
than
kind
of
generally
in
favor
of
the
whole
idea
I,
but
I'm
curious
what
the
kind
of
state
of
thought
is,
and
you
know
it's
just
a
topic
of
interest
to.
F
D
D
The
current
proposal
is
that
they're,
primitives
and
primitives
have
wrappers,
so
rappers
have
identity,
they're
kind
of
you
kind
of
want
to
optimize
out
their
existence
in
as
many
cases
as
possible
and
strict
mode
helps
that,
but
only
some
of
the
time
I
was
wondering
if
we
should
make
records
and
doubles
objects,
but
say
that
they're
objects
without
identity,
that
they're
objects
that
compare
by
value
that
only
have
other
things
without
identity,
but
that
they're
still
considered
objects.
D
I'll
try
to
walk
through
this.
I
guess.
D
So
yeah
with
with
normal
objects,
they
have
their
triple
equals
or
objectives
compare
their
identity.
D
And
but
the
idea
is
that
with
records
and
tuples
they
would
be
objects,
so
they
wouldn't
have
wrappers,
they
would
be
objects
directly
and
the
comparison
would
be
by
their
by
their
contents
and
that
you
can't
observe
their
identity
they're
always
frozen.
You
can't
one
difference
between
frozen
objects,
is
you
can't
add
private
fields
to
them
and
they
also
won't
have
mutable
internal
slots
and
you
can't
use
them
in
weak
maps,
and
things
like
that.
D
C
Danielle
a
quick
question
about
these.
What
what
is
the
reason
for
this
to
to
to
to
have
them
as
objects,
rather
than
a
new,
primitive.
D
So
the
first
reason
is
the
rappers.
The
rapper
semantics
are
kind
of
unhelpful.
They,
you
know
you
want
to
avoid
creating
the
wrappers.
We
have
to
worry
about
what
are
the
semantics
when
you
have
a
rapper?
How
does
that
differ
from
the
underlying
record,
like
they'll
have
a
different
identity,
but
it.
D
Really
I
mean
I'll
explain
in
this
as
we
go
down
the
document,
so
equality,
I'm
imagining
that
we
would
define
equality
just
the
same
way
and
so
rappers
would
yeah
one
one
detail
is
the
objects
are
frozen
where
there
was
this
whole
question
about
whether
the
wrappers
are
frozen
or
not.
D
D
Overall,
it
seems
like
the
the
specification
and
implementation
will
be
simplified,
so
the
first
so
the
the
two
big
things
that
I
think
this
would
enable
is
record
proxies
and
and
box,
so
record
proxies.
It
would
be
like
a
proxy
that
has
a
target
and
a
handler,
except
they
would
be
compared
by
value.
D
You
would
compare.
You
would
say
that
they're
equal
if
the
target
and
the
handler
are
equal.
I
guess
this
should
be
object,
that
is
to
be
precise,
but
if
we
had
records
compared
by
value,
wouldn't
this
help
membrane
systems,
then
you
wouldn't
need
a
weak
map
to
cache
the
the
proxy
object.
You
just
make
a
new
record
proxy.
G
So,
just
to
clarify
about
proxy.record
this
would
be
similar
to
if
I'm
guessing
the
target
has
to
be
a
record
in
this.
E
D
C
Did
you
you're
you're,
you
I'm
getting
very
confused?
I
was.
I
wasn't
aware
of
this
change
last
time
that
I
look
at
it
was.
It
wasn't.
C
Okay,
okay,
I
was
like
okay
well,
this
is
all
new,
so
I
I
still
haven't
get
my
hair
around
the
fact
that
there
will
be
objects
or
they
could
be
objects
rather
than
primitive
values.
When
we
talk
about
primitive
values,
we're
saying
well
they're
pretty
much
the
same
as
symbols
and
anything
else,
so
the
identity
across
realms
and
across
membranes.
The
identity
on
both
sides
is
the
same.
So
we
don't
really
worry
about
being
proxified
or
any
of
that
yeah.
Now
you
make
10
objects,
then
it
makes
it
a
little
more
complicated.
C
D
D
You
know
the
reason
that
I
started
thinking
about
this
is
because
the
excess
people
we
have
an
email
thread
with
them
and
they
were
saying
hey
this
doesn't
this
doesn't
seem
so
great
for
our
users
because
it
doesn't
fit
in
so
well
with
the
read-only
collections
proposal
and
I
kind
of
realized
they're
right,
you
can't
point
to
a
read-only
collection
from
a
record
or
tuple,
except
with
symbols
as
weak
map
keys
and
it
sort
of
splits,
the
universe
or
another
example
of
this
is
temporal.
D
You
want
to
have
a
more
general
notion
of
what's
what
doesn't
have
identity,
so
you
kind
of
want
to
be
able
to
make
new
things
that
don't
have
identity,
and
I
think
it
would
be
a
lot
simpler
to
do
that
if
they're
objects
than
if
they're
only
primitive
types.
D
So
once
we
can
do
a
proxy
over
a
record
or
tuple,
we
can
have
box
and
it
can
be
totally
membrane
safe.
We
can
have
box
would
be
this
built-in
class
that
makes
objects
without
identity
that
allows
this
draft
method,
and
it
wouldn't
be
that
it
it's
based
on
the
realm.
It
would
really
be
that
the
draft
method
is
based
on
the
getting
the
thing
out
of
the
out
of
the
box.
It
could
be
a
crossroam
internal
slot.
D
The
the
the
reason
it's
okay
is
because
we
can
have
these
proxy
records,
these
record
proxies
and
so
records
and
tuples
could
point
to
mutable
objects
could
point
to
objects
with
identity.
You
know
the
only
thing
is.
We
would
still
ask
people
to
put
things
in
a
box
before
putting
in
a
record
in
tuple,
so
that
by
default
you
have
deep
immutability.
You
have
to
call
out
tune
a
specific
escape
hatch
to
violate
that.
D
And
then
I
had
some
ideas
about
classes,
so
in
particular,
once
we
have
box
we
could
let
people
set
the
prototype
of
their
records.
D
D
It
was
everybody's
number
one
complaint
that
symbols
as
weak
map
keys
was
not
ergonomic
enough
that
you
really
want
to
be
able
to
have
read-only
collections
or
temporal
objects
directly
in
records
and
tuples,
and
so
now
we
would
have
two
ways:
both
they
could
be
on
one
hand
they
could
be
other
objects
without
identity
and
it's
easier
to
add
another
kind
of
object
to
that
identity
than
another
primitive
and
on
the
other
hand,
you
have
this
box.
General
purpose
escape
hatch
and
it's
safe
with
membranes,
because
we
have
record
proxies.
C
D
Yeah,
so
the
idea
is
that
record
and
tuple
literals
or
constructs
that
make
records
and
tuples
dereference
the
box
as
soon
as
they
get
it.
So
they
check
is
each
thing
that
is
being
given
to
me:
either
a
thing
without
identity,
or
if
it's
a.
If
it's
a
box,
then
I'll
de-reference
it
on
the
way
in
so
that
way,
you
don't
accidentally
point
to
mutable
things,
so
things
are
deeply
mutable
by
default,
but
you
have
this
escape
hatch.
So
after
it's
constructed
it
just
is
directly
pointing
to
that
other
object
and
the
quality
is
defined.
D
Like
equality
is
still
recursive,
so
you
can
have
objects
with
identity
that
are
directly
contained
in
records
and
tuples
and
equality
is
just
to
find
that
if
you
hit
something
with
identity,
then
that's
compared
internally
by
identity
and
but
if
you're
at
a
record,
then
you're
comparing
it
by
individual
value
by
individual
value.
D
H
Constructed
can
the
same
value
be
in
more
than
one
box.
I
I
presume
that's
the.
I
Sorry,
I
don't
understand
the
the
you
said
that
boxes
are
dereferenced
on
the
way
in
what
what
is
the
reason
to
have
the
box
at
all
and
not
just
pass
in
the
you
know,
no.
D
The
main
reason
is
to
have
this
default
deep
immutability,
you
know
by
default,
it
only
works
with
immutable
things.
You
have
to
specifically
opt
out
of
deep
immutability
to
to
put
an
object
in.
So
it's
like
an
opinion
rather
than
an
invariant
right.
H
So
I
think
one
of
the
things
we
should
probably
kind
of
come
loop
back
to
is
that
one
of
the
key
priorities
of
record
tuple
is
that,
like
the
default?
Is
that
deeply
immutable
is
like
what
happens
when
you
use
the
feature?
So
we're
really.
One
of
the
things
we
try
to
avoid
is
like
accidentally,
like
the
user
accidentally
slipping
a
mutable
reference
into
a
record
in
tuple,
like
that.
We
find
that
this
happens
really
commonly
with
like
user
land,
immutable
libraries.
H
So
there's
no
technical
reason
why
we
couldn't
just
if
we're
detecting
boxes,
just
detect
identity
like
objects
and
store
the
reference
like
that
seems
reasonable
from
specification
perspective,
but
that
just
means
that
you
can
create
records
with
mutable
objects
in
them
and
not
realize
it.
So
the
box
forces
you
to
make
the
choice
that
you
are
saying.
This
is
a
this
is
effectively
a
pointer
to
the
object
and
we
are
opting
out
of
immutability
for
this
part
of
the
tree
like
it's.
It's
purely
dan
mentioned
it
perfectly.
H
C
I
still
don't
understand
what
the
deal
will
be
for
the
proxies
when
these
are
objects
instead
of
primitive.
That's
one
question
that
I
have,
and
the
second
question
is
about
the
I'm
getting
very
confused
about
the
underscore
underscore
protocol
and
what
does
he
do
and
when
you
do
that
line
that
you
were
showing
before
what
is
happening
there,
because
new
box
returns
an
identity?
That
thing
is
sure,
is
it
thing
that
has
a
pointer,
but
but
how
do
we
use
that
like?
What?
What
exactly
is
this
giving
us.
D
Boxes,
the
whole
point
is
most
of
the
point
is
switching
to
objects,
but
anyway,
I
guess
we
should
cover
both
of
them,
so
record
proxies
the
the
idea
of
record
proxies.
Is
this
lets
you
proxy
a
record
in
tuple
while
making
equality
still
work,
so
you
want
it
to
be
that
if
you
proxy,
a
with
the
same
membrane
twice,
then
you're
still
getting
the
same
record
back,
but
you
can't
put
that
record
as
the
key
of
weak
map.
If
it
were,
I
mean
whether
it's
a
primitive
or
not.
D
So
instead
we
totally
go
around
that
by
just
saying
that
you
can
make
a
new
proxy,
a
new
record
proxy
and
it
will
have
the
behavior
you
want.
It
won't
have
any
state,
because
the
target
is
you
know
when
when
the
target
is
a
record
or
tuple
and
the
handler
is
shared
in
the
handle
that
you're
using
the
same
handler
again,
then
it
should.
C
Two
clarification
questions
about
that.
So
I
get
that
proxy
record.
You
pass
a
target
which
is
the
same
record.
You
call
it
twice.
C
Fine,
it
returns
a
thing
that
you
can
compare,
but
the
problem
is
that
in
most
cases
when
it
comes
to
membrane,
the
target
that
you
pass
is
not
really
the
target,
but
a
shadow
target,
and
the
reason
why
it
is
a
shadow
target
is
because
it
breaks
the
invariant
of
the
target
that
you
that
you
have
so
this
target
is
immutable.
C
So
if
you
ask
that
proxy
for
a
particular
value
out
of
that
proxy,
it
should
return
the
same.
That
is
in
the
target
because
the
target
is
frozen
and
you
can
not
change
that
for
something
else.
So,
in
order
to
keep
the
object
in
variance,
we
have
to
provide
a
shadow
tag,
another
target
and
then
the
handler
is
responsible
for
doing
the
the
the
connection
between
the
target
and
the
actual
shadow
target
and
and
do
the
proper
handling.
That's
one
question.
The
second
question
is
about
the
hunger
itself.
D
D
So
I
forgot
about
shadow
targets,
I'm
wondering
if
you
need
them
when
proxying
records,
given
that
you
never
mutate
records.
C
A
May
I
just
to
speak
further
on
this.
I
kind
of
see
the
point
that
carrie
is
making
about
distortions.
In
particular,
let's
say
we
had
a
shadow
record
which
was
hiding
one
of
the
fields
of
the
original
of
the
original
record
you're
introducing
a
whole
bunch
of
complications
there,
because
if
it's
I
mean
it's
a
it's
a
use
case
that
hasn't
been
explored.
I
think.
C
C
So
they
so
think
about
this
example.
You
have
a
two
records,
one
of
them
use
the
other
one
like
one
record,
that
has
a
property
that
points
to
another
record.
Something
like
that.
When
I
create
a
proxy
record,
I
get
a
proxy
out
of
the
arena
out
of
record
and
when
I
access
the
property
x,
which
contains
the
other
record,
what
does
he
return?
C
D
D
C
D
C
D
C
C
D
Yeah,
so
I
think
I
was
thinking
that
we
could
do
it
by
comparing
the
handler.
So
if
you
reuse
the
handler,
then
it's
the
same
identity
and
the
the
proxy
record
would
be
equal.
But
none
of
this
works
with
the
shadow
target
issue
that
you
mentioned
yep
with
the
proxy
invariants.
D
So
I
don't
know
it
doesn't.
D
I
don't
so
if
they're
only
considered
equal
if
the
handlers
are
equal.
So
if
you
and
I
think
that's
important,
if
you
have
the
same
target.
I
C
Because
if
you
don't
have
a
shadow
target,
then
you
cannot
really
implement
a
membrane
around
these
records.
Yeah.
E
I
If
I'm
not
mistaken,
I
mean
the
current
way
of
of
creating
these
shadow
targets
is
that
you
create
a
single
shadow
target
that
is
shared
between
all
objects
of
the
same
type.
If
I
can
say
so,
you
have
a
function,
shadow
target
on,
or
at
least
this.
C
If
the
target
has
a
non-configurable,
no
writeable
descriptor
on
it
and
you
access
it
through
the
handler,
you
have
to
install
that
into
the
shadow
target,
because
otherwise
you
will
break
the
invariant.
So
when
you
return
the
value
from
the
handler,
it
must
be
installed
on
the
shadow
target.
Otherwise.
D
You
don't
have
to
worry
about
that
for
this
case,
because
they're
not
you
know,
because
they're
sealed,
but
right.
D
A
C
I
Can
we
I
I
I'm
still
not
convinced
that
that
it
is
actually
a
problem?
I
think
it
may
just
require
a
different
pattern
on
the
on
the
membrane
implementation.
I
Is
that
is
that
statement
true
or
is
it?
Is
it
that
it
breaks
the
that
it
breaks
the
current
pattern
of
implementation,
or
is
that
that
we,
it
makes
something
impossible
that
is
previously
possible?
Are.
I
No,
I
I
think
shadow
targets
can
be
used,
but
I
don't
see
the
invariance
that
it
breaks,
but
I
don't
fully
understand
the
the
the
way
it's
being
used
in
your
in
your
situation.
Trudy.
I
My
the
membranes
that
I've
got
in
microbial
are
probably
a
little
bit
more
primitive
or
you
know
more
simple,
so
maybe
maybe
I'm
not
facing
the
same
problems
you
are,
but
it
would
be
possible
for
you
to
to
kind
of
write
up
the
the
requirements
more
specifically,
so
I
could
understand
yeah
no.
C
It
it's
the
the
example
that
I
was
saying
before
you
have
record
food
that
contains
the
property
x
that
contains
the
record
bar
yeah,
so
you
just
have
two
records
and
because
the
record
everything
is
sealed,
so
it's
everything
is
not
comfortable,
not
writable.
At
that
point,
you
try
to
put
a
proxy
around
foo,
which
is
a
record,
and
that
returns
a
a
a
a
pr,
a
proxy
of
it,
and
now
in
that
proxy
you
try
to
access
x
out
of
it
right.
C
So,
if
you
don't
use
a
shadow
target,
that
accessor
to
x
must
return
the
same
value
that
the
original
record
foo
has
for
the
accessor
x,
otherwise
you're
breaking
the
the
updating,
but
it
must
be
the
same.
The
only
way
that
you
can
return
a
proxy
around
that
second
record
is
by
putting
a
shadow
target
whose
value
for
x
is
a
new
proxy
for
the
second
record.
C
With
that
yeah
we
can
explore
that
for
sure,
then
the
second
set
of
problems
is
really
about
the
handler.
What
are
we
going
to
do
with
the
handler-
and
I
suspect
one
way
of
looking
at
this
is
saying
well
for
proxy
records.
The
handler
is
not
a
live.
Object
is
a
configuration
option.
D
C
But
remember
that
today
the
identity
of
the
traps
are
not
used
unless
that
you
hit
the
trap.
So
when
you
hit
the
trap,
it
gets
the
handler
for
the
trap.
D
So
I
think
I
didn't
explain
very
well,
but
this
box
concept
would
let
you
make
a
callable
record
proxy,
because
you'd
be
able
to
put
a
box
around
a
function
and
then
pass
that
in
as
the
target.
D
The
box
of
the
function
box,
so
I
think
I
can
give
you
the
full
generality
of
proxies.
We
could
make
it
a
configuration
object.
I
don't
see
any
problem
with
that
and
we
could
say
that
you
pass
in
a
separate
this
value
that
then
people
can
use
for
the
the
target,
and
you
know
solving
the
the
problem
of
having
to
close
over
the
the
thing
in
the
handler
and
then
I
think
we
would
just
have
all
the
traps
with
all
the
same
signatures.
D
B
D
Yeah,
so
this
is
very
helpful.
I
hadn't
thought
that
kind
of
stuff
through
at
all,
and
but
I
wanna,
I
wanna
come
back
to
sort
of
the
main
point
about
like.
Even
though
these
are
objects,
they
don't
have
an
identity
and
we
suddenly
have
box
working,
which
we
previously
concluded
in
an
earlier
meeting
with
this
group
was
a
total
non-starter.
D
D
I
was
initially
thinking
that
it
was
really
really
important
that
records
is
bradley
here.
Yes,
oh
great,
so
bradley
and
I
were
chatting
about
the
importance
of
you
know.
Records
are
addressed
by
keys
by
string
keys
and
you
wouldn't
really
want
weird
object
stuff
to
get
in
the
way
of
the
domain
of
string
keys.
D
But
if
this
is
gonna,
be
a
general
object
thing,
maybe
we
still
do
want
prototype
access,
because
then
it
would
be
really
cool.
You
could
use
it
for
classes.
I
don't
know,
that's
a
that's
a
vague
idea,
but
maybe
records
should
just
be
objects,
but
not
have
the
object
stuff
in
their
prototype
chain,
and
maybe
they
should
just
defer
for
string
things
and
allow
their
prototype
to
be
objects
or
or
records,
but
that
the
identity
it
if
it's
a
record
is
compared
by
comparing
the
entries.
C
D
D
D
Because
I've
been
thinking
for
so
long
that
records
and
tuples
have
to
be
primitives,
because
we
really
want
this
definition
of
equality,
but
now
I'm
thinking,
if
we
do
proxies
and
boxes
right,
then
we
can
just
have
these
be
objects
that
have
this
definition
of
equality
so
what's
distinguishing
is
that
they
don't
have
identity
and
that
equality
is
defined.
That
way,
not
that
they're
primitives.
E
So
daniel
there
was
something
that
I
really
appreciated
when
I
first
saw
records
in
tuples
that
for
me
I
was
just
seeing
it
as
a
way
to
get
like
two
deep
comparisons
as
something
like
that
would
lead
to
similarities
with
deep
equal
from
testing
frameworks,
and
that
was
one
of
the
things
that
got
me
really
excited.
E
I
am
not
sure
how
this
solution,
because
it's
hard
to
see
it
just
yet
how
transforming
into
objects
will
still
preserve
that,
and
that's
like
for
me
personally,
it's
something
I
really
value
like
the
the
same
value,
zero
or
being
able
to
go
through
records
and
tuples
in
a
nested
comparison.
D
Yep,
that's
the
idea
that
it
would
maintain
that
definition
for
equality.
I
agree
that
that's
sort
of
the
core
value
or
one
of
the
core
values,
but
yeah.
We
would
just
continue
to
define
equality
like
that.
B
B
B
H
This
slightly
more
concrete
and
like
described
a
way,
a
way
by
which
you
could
describe
this
in
a
spec
and
then
go
from
there
to
describe
how,
like
the
same
value
functions,
would
work,
because
the
way
this
works
in
my
head
is
just
like.
If
you'll
indulge
me
in
a
quick
like
brainstorm,
an
identity-less
object
would
just
have
like.
H
Let
imagine,
for
this
is
not
a
recommendation
for
how
this
would
be
done,
but
imagine,
for
example,
that
identity-less
objects
just
have
an
internal
slot
called
identity
list
set
to
true
or
something
and
the
same
value
non-numeric
would
just
check
if
that,
if
it's
an
object
of
that
type
or
with
that
internal
slot
and
then
do
a
recursive,
deep
equality
check
on
its
properties.
If
that
flag
exists,
that's
and
that's
what
we
already
do
for
records.
We
would
just
change
it
to
object
with
identity.
H
F
G
Yeah,
so
I'm
listening
to
this
changes,
there
is
a
lot
to
take
in.
It
seems
like
we
would
get
box
and
we
wouldn't
need
to
use
primitive
with
these
changes,
but
it
seems,
like
the
proposal,
alters
its
scope
to
be
much
less
in
some
ways:
you're
not
trying
to
guarantee
deep
immutability
you're,
not
trying
to
have
the
integrity,
be
consistent
for
string
keys
and
I'm
just
kind
of
wondering
we
had
an
old
proposal
that
got
scrapped
called
composite
key.
G
This
seems
to
me,
like
we
are
effectively
doing
a
api
proposal,
that's
similar
in
scope
to
what
composite
key
was
at
the
time,
and
I'm
just
kind
of
curious
about
all
this
complexity
that
we're
adding
versus
just
the
statement
that
we
want
an
equality
operator
that
is
not
based
upon
object,
identity.
G
G
People
did
not
like
that
composite
key
generated
a
new
value.
It
was
not
something
like
records
or
tuples.
It
didn't
try.
Well,
the
previous
records
are
tuple's
current.
Whatever
you
want
to
call
it,
it
did
not
try
to
do
more
than
produce
an
identity
given
a
set
of
component
parts,
and
people
thought
that
that
was
not
valuable,
but
that
it
seems
to
be
the
key
sale
on
this
altered
proposal
here.
D
So
I
mean,
I
think,
the
benefits
for
normal
programming
of
records
and
tuples
would
still
be
there.
The
I
want
to.
I
want
to
say
that
the
the
idea
of
weakening
the
string
prototype
invariants,
that's
totally
separable
from
the
rest
of
this.
We
could
still,
I
think,
that's
totally
separable
from
the
idea
of
box
and
proxies.
G
We
could
I'd
agree.
I
think
the
what
I'm
trying
to
state
is
there
is
so
much
that's
been
weakened.
I
think
the
only
thing
that's
still
preserved
against
the
original.
I
wouldn't
call
them
goals,
but
the
cell
of
records
and
tuples
is
that,
given
component
parts,
they
have
equality.
D
Well,
but
there's
also
the
deep
immutability
opinion,
even
if
it's
not
an
invariant
it
still
could
it
still
could
help
programming
in
practice
that
you
have
to
put
a
box.
The
other
thing
is
having
literal
syntax
for
for
frozen.
For
for
this
frozen
thing,
you
know.
G
So
just
going
on
about
the
deep
immutability
one
of
the
statements
was
it's
easy
for
you
for
your
users
to
inject
mutable
state
into
read-only
collections
and
things
like
that
in
existing
libraries.
What's
to
prevent
people
from
injecting
a
box
into
something
where
people
did
not
want
mutable
state
within
a.
D
I'm
not
I'm
also
not
clear
what
we're
protecting
against
it's
hard
for
me
to
picture
this
as
like
a
threat
model.
G
This
is
not,
I
think,
going
so
far
as
to
call
it
a
threat
model,
isn't
the
direction
here
we
aren't
saying
that
this
is
a
security
feature.
This
proposal,
the
complaint
that
we
heard
earlier
in
this
call
was
people
got
problems
from
mutable
references
being
placed
in
immutable
collections,
and
it
still
seems
possible
to
do
so.
H
The
isn't
people
putting
mutable
objects
in
records,
it's
the
problem
of
people,
putting
mutable
objects
and
records,
and
not
knowing
that
it's
happening.
Like
the
I
I
totally
understand
the
around
like
someone
else
giving
you
a
box.
I
think
that
makes
sense,
I
think
maybe
literal
syntax
will
help
there,
but
I
don't
think
the
invariant
that
we're
pushing
for
is
that
you
can
never
put
mutual
data
in
a
like
people.
Want
really
do
want
that.
Like
that's.
What
we
refer
to
the
committee
is
people
do
want
to
put
mutable
things
in
a
record.
G
F
So
I
don't
so
I
don't
fully
understand.
I
don't
fully
understand
any
version
of
the
proposal,
so
I'm
going
to
ask
a
dumb
question:
I
apologize
ahead
of
time
the.
How
does
how
does
this
alteration
of
the
record
and
tuple
proposal
interact
with
keys
in
maps
not
weak
maps
but
maps,
because
my
current
understanding
of
the
shape
of
the
language
is
that
there
are
the.
F
There
are
two
kinds
of
values
that
can
be
keys
and
maps
and
they're
value
types
and
and
object
types
and
and
the
treatment
for
them
is
but
the
the
proper
the
property
of
both
of
these
that's
in
there
that's
important
is
not
just
equality
but
hash
ability.
F
D
F
B
B
H
Like
for
comparison
on
the
quality
side,
if
you
create
two
records
and
they
each
have
a
property
with
a
box
and
that
box
both
points
the
same
record
when
you
do
the
recursive
comparison
on
the
record,
it
will,
they
will
both
reach
the
object
and
they're
the
same
object.
So
they
have
the
same
identity,
so
they're,
equal.
F
F
F
But
these
objects,
it's
it's
computed
right
and
is
it
cachable
or
does
it
get
invalidated
if
some
state
changes
somewhere
in
its
transitive
graph.
F
F
Oh
yeah,
and
to
to
restate
my
understanding:
it's
that
the
identity
that
they
remain
transitively
immutable,
because
you
cannot
replace
you
cannot.
You
cannot
replace
an
object
with
with
a
different
identity
in
the
graph.
D
People,
but
people
really
don't
have
any
any
more
questions
or
concerns.
I
feel
like
I
want
to
follow
up
and
understand
better
the
stuff
bradley
was
talking
about,
because
I
don't
think
I
don't
think
we
have
a
complete
answer
to
that.
G
G
So
if
for
any
given
property
in
your
record
literal,
if
you
use
a
variable
and
you
don't
check
that
it
is
deeply
immutable
for
whatever
definition
you
want
for
that,
you're
no
longer
guaranteed
to
have
deep
immutability
like
defaults,
you
have
to
actually
perform
that
check
to
state
that
you
are
deeply
immutable.
D
So
I'm
wondering,
when
are
the
cases
that
you
want
to
assert
deep
immutability,
so
we
could
figure
out
what
kind
of
solutions
would
work.
G
G
I
Something
that
might
help
that
just
came
to
mind,
and
I
don't
know
if
this
is
just
a
random
idea,
but
if
the
boxes
weren't
unwrapped
by
default,
then
when
you
access
a
when
you
access
a
property
on
a
record,
if
you,
if
the,
if
the
consumer
side
is
expecting
it
to
be
mute,
is
expecting
it
to
be
mutable.
You
can
expect
a
box
in
that
position
and
then
de-reference
the
box
explicitly
it
would.
I
It
would
mean
that
the
contract
between
the
producer
and
the
consumer
of
the
record,
the
the
the
boxing,
is
part
of
that
contract.
I
G
I
understand
that
they've
got
a
lot
of
that
going
on
in
rust,
with
dad
on
rap.
I
don't
think
we
actually
need
to
go
that
far.
We
just
need
a
way
to
either
test
if
something
is
deeply
immutable
or
have
a
way
when
you
insert
something
for
it
to
eagerly
fail
if
it
is
mutable.
D
So
what
if
we
called
all
deep
all
things
without
identity
objects
with
ident
without
identity
records,
we
said,
tuples
are
a
type
of
record
and
record
dot.
Is
record,
became
a
shallow
immutability
test
it?
Wouldn't
it
wouldn't
fail?
If
the
record
then
contains
a
box,
but
it
would
fail
if
you
know,
if
you
ask
it
about
an
object,
so
it
would
kind
of
correspond
to
composite
key.
How
composite
key
does
contain
these?
D
Maybe
this
is
the
wrong
default,
because
you
have
to
actually
call
this
function,
but
is
this
the
test
that
we
want
for
a
mute
keyword?
Do
we
want
to
be
testing
is
record
shallowly
or
do
we
want
to
really
be
doing
a
deep,
recursive
test?
That's
something
I
don't
understand.
G
B
So
it
strikes
me
that
if
the
box
is
explicit,
there's
nothing
preventing
you
from
having
a
a
completely
immutable
data
object
which
is
used
as
a
key
into
a
separate
table
of
mutable
objects,
and
this
is
basically
just
a
shortcut
for
that.
So
I
don't.
I
don't
know
that
adding
a
deep
immutability
add
on
to
this
by
send
me
additional
functionality.
G
D
D
H
C
H
C
But
then
that
does
not
introduce
so
much
of
a
problem
for
for
the
records
proposal,
because
if
everything
else
is
I
I
always
thought
that
if
you
have
something
in
a
record
that
is
a
box,
you
must
know
that
it's
a
box
and
you
must
de-reference
that,
but
it
has
no
implication
whatsoever
on
the
record
itself
yeah.
That
was
my
assumption
up
to
this
point,
but
now
because
of
these
underscore
underscore
products,
that's
why
I
wasn't
getting
better
computers.
D
So
let
why
don't
we
say
that
boxes
don't
get
automatically
dereferenced
when
you
put
them
into
a
record
in
tuple.
That
would
be
kind
of
too
cute
too
much
allowing
you
to
forget
that
there's
actually
a
mutable
thing.
It
would
create
this
hazard,
where
you
would
create
these
mutable
data
structures
by
requiring
the
explicit
dref
on
access.
D
C
C
D
Right
so
what
if
we
said
like?
Actually,
let's
not
do
this
proto
thing,
as
I
wrote
here,
this
section
is
not
very
well
thought
through
the
sections
that
I
the
the
reason
that
I
was
thinking
about
this
is,
I
was
thinking
about.
How
could
we
make
it
so
that
the
temporal
proposal
actually
consists
of
records,
but
you
point
out
real
problems,
so,
let's
just
focus
on
these
I
mean.
G
So,
to
be
clear,
I
do
think
you
can
do
automatic
unboxing.
It's
just
gonna.
Take
some
conversation
about
the
actual
things
needed
in
the
case
of
such
a
thing
being
allowed.
I
think
it
could
even
be
done
afterward
if
that
matters
daniel.
B
D
G
I
think
you
shouldn't
allow
underscore
underscore
proto
in
these.
The
special
form
for
under
under
proto
is
useful,
but
I
don't,
I
think
no,
that
is,
I.
C
If
I
think
it's
useful,
you
want
to
compose
use
the
same
capabilities
that
you
have
an
object
to
compose
records.
I
think
that's
useful
in
the
sense
that
you
can
have
a
record
that
extends
for
another
record
and
because
they
are
immutable
and
that
production
mutable
it's
something
nice.
So
you
have
to
imagine
that,
rather
than
creating
a
copy,
rather
than
creating
a
copy
of
the
sorry.
G
Maybe
I
should
clarify,
I
don't
think
a
proto
of
a
non-record
is
that
is
saying,
got.
B
D
G
D
D
Tuples
do
have
a
prototype
doubles
need
to
have
methods,
it
needs
to
be
possible
to
polyfill
other
methods
onto
double
prototype,
so
it's
not
a
frozen
class,
and
I
was
hoping
that
we
could
have
some
notion
of
classes
for
records
and
one
one
big
problem
for
classes
for
records
is
that
the
constructor
system
in
javascript
doesn't
make
any
sense
on
on
records,
because
you
have
to
incrementally
write
into
the
thing.
So
I
was
thinking
we
could
have
a
new
kind
of
constructor
syntax,
which
is
from
a
static
method.
D
You
could
do
this
new
dot
instance
thing.
It
would
create
a
new
instance
that
has
of
the
enclosing
class
that
would
have
the
fields
filled
in
with
an
object
literal,
and
maybe
this
would
make
sense
for
typed
objects
as
well,
because
you
can't
you
just
can't
incrementally
initialize
them,
and
then
this
thing
would
have
to
have.
This
really
would
have
to
have
a
dunder
proto
somewhere
to
be
able
to
reference
its
methods.
I
I
mean
the
methods
can
already
exist.
You
could
just
have
the
but
to
have
the
methods
shared
between
multiple
instances
of
a
particular
type
of
record.
D
D
D
D
Any
thoughts,
any
ideas
of
how
to
make
record
classes
work.
Maybe
it's
not
possible.
I
think
records
are
still
worth
it.
Even
if
we
don't
have
record
classes,
but.
H
H
G
Mind
so
I'm
okay
with
that.
Still,
I
just
want
to
be
sure
that
it,
whatever
one
level
deep,
is
non-identity.
G
I
think
you
know,
having
things
be
a
test
rather
than
an
enforced.
Invariant
is
fine
where
we
could
just
call
a
method
like
is
shallow
leave
non-identified.
I
don't
know
what
to
call
it.
It's
terrible
name
that
just
checks
all
the
current
key
value
pairs
on
the
object
to
make
sure
that
it
one
level
deep,
they
are
non-identity
and
they
could
have.
However
much
and
it
just
returns
a
boolean,
true
or
false
would
solve
my
checks
for
usages.
G
G
It
would
return
true
because
a
box
is
a
non-identity
according
to
what
has
been
stated.
Okay,
it
is
still
considered
immutable
for
that.
H
Level
right
so
then,
so,
then
checking
so.
If
you
make
the
invariant,
if
you,
if
you
assert
the
invariant,
that
a
record
can
only
contain
non-identifiable
things
so
primitives
and
non
objects
without
identity,
then
that
check
simply
becomes
a
check
that
it
that
it
is
a
record,
because
if
records
are
the
only
thing
that
have
that
invariant,
then
the
fact
that
it
is
a
record
means
that
that
is
true.
You
don't
have
to
check
the
values.
I
guess
it
might
point.
A
I'm
just
I'm
just
thinking
this
whole
concept
of
records
and
having
inherited
properties.
D
D
A
That's
not
what
I'm
getting
at.
What
I'm
getting
at
is
strictly
talking
about
records
and
the
equality
of
records.
Do
we
count
the
prototype
chain
as
part
of
that
equality
check
is
what
I'm
asking.
C
I
think
you
need
to
because,
in
order
for
you
to
create
a
record
because
the
the
the
protochain
is
immutable
by
comparing
the
object,
you
know
for
sure.
If
it
is
the
object
that
you
want
that
that
you
that
you
have
in
the
first
place.
D
Yeah,
it's
important
that
if
you
have
two
different
records
and
they're
the
same
except
for
their
prototype,
then
you
know
they're
gonna
behave
differently,
because
when
you
get
the
prototype,
you'll
get
a
different
thing,
so
they
shouldn't
be
equal
right.
C
But
I
told
daniel
that
there
was
another
property
of
the
records
that
was
like.
If
I
create
two
identical
records
and
I
compare
them,
are
they
going
to
be
in
the
previous
verbosa
was
then
supposed
to
be
equal
or
just
not
equal?.
C
C
But
in
this
case,
in
this
case
it's
not
possible
to
do
that
like
if
I
declared
two
two
records
they
point
to
the
different
object.
C
C
H
What
I
would
say,
maybe
instead
dan,
if
I'm
going
to
suggest
wording,
is
like
hidden
identity
in
that
every
operation
that
can
observe
the
identity
we
make
it
so
that
you
can't
observe
it
but
like
so
whether
or
not
they
have
an
identity
is
kind
of
a
moot
point,
because
you
couldn't
tell
anyway
so
like
the
goal
here
is
to
make
objects,
behave
observably,
like
the
perimeter
version
of
record
in
all
cases.
So
then
you
can't
tell
the
difference,
but
like
the
idea
is
that
we're
hiding
identity
in
all
cases.
D
I
D
B
H
F
F
Yeah
well
for
box
type
box,
type,
constructing
a
box
type
and
calling
value
of
returns.
The
intern,
the
contained
value.
F
Yeah,
I
think
that
those
two
properties
are
consistent.
If
it's
an
object,
it
returns
itself
and
if
it's
not,
if
it's
a,
if
it's
a
box
type,
it
returns
the
contained
value.
The
other
superficial
idea
is
that
if
you
were
so
for
one,
I
really
I
I
kind
of
find
compelling
the
idea
that
if
you
put
a
box
inside
of
a
record
or
a
tuple,
it
sort
of
escapes
the
zone
of
transitive,
immutability
and
sort
of
just
ends,
it
creates
a
boundary
between
the
portion.
F
That's
used
for
tracking
the
identity
of
the
resulting
object
graph
and
the
part,
that's
that
is
free
to
change
what
I
what
I
think
that
it's
it's
compelling,
because
that's
going
to
exist
in
for
the
prototype
reference,
at
least
regardless.
So
it's
it's
very
clever
in
that
way.
Superficially
I
instead
of
new.instance,
you
might
consider
hash
constructor
name
with
curly
braces
after
it.
F
H
D
D
B
D
I
Thanks
I've
used
the
immutable
js
library
extensively
in
some
of
my
projects,
and
I
find
that
there's
always
reason
or
often
in
every
scenario
I've
encountered.
There's
there's
reason
to
include
it
includes
some
kind
of
reference
to
a
mutable
object
somewhere
in
a
large
immutable
graph.
So
I'm
in
favor
of
of
this
kind
of
approach.
That
makes
it
a
little
bit
easier
to
do
that.
I
Then
you
can
sort
of
choose
whether
you
want
to
whether
you
want
to
have
the
comparison
on
the
object,
identity
or
the
value
identity
for
each
property
individually.
So
I
like
the
direction
this
is
going
if
it
can
work.
G
Out,
I
guess
I'm
up,
so
I
think
this
is
much
simpler
overall
for
my
brain
than
primitives.
I
think
it's
very
new
and
there's
gonna
be
more
discussion
if
you
go
down
this
route,
but
I
do
think
it
would
be
easier
to
deal
with
box.
G
If
that
is
the
goal
here,
I
think
establishing
that
boundary
of
what
is
or
how
to
test,
for
if
something
is
immutable,
will
need
to
be
reclaimed
somehow,
either
by
not
auto
unboxing
or
supplying
an
api
to
do
a
shallow
test,
but
I
don't
think
those
are
in
any
way
bad.
F
G
G
G
Assertions
there
are
host
restrictions
being
desired
by
people
at
tc39.
I
don't
know
if
anybody
here
had
the
explicit
opinion
that
a
import
assertion
should
not
be
allowed
to
be
part
of
a
cache
key
outside
of
web
browsers,
but
I
am
going
to
be
arguing
that
node
will
be
using
them
as
cache
keys,
since
it
seems
the
browsers
are
going
to
be
doing
so.
D
G
The
cache
key
can
still
point
to
the
same
resource.
That
is
not
true
on
the
web,
but
that
has
always
been
true
for
node.
G
We
work
off
the
response
url.
Otherwise
we
break
npm.
The
web
works
off
request
url.
So
a
variety
of
things
like
if
you
were
to
import
unpackaged
lowdash,
you
would
get
the
request,
not
the
response,
so
you
can
actually
get
like
different
contents
from
requesting
the
same
thing
on
the
web,
because
it's
based
off
request,
url,
not
response,
and
since
we
do
real
pathing
always
to
avoid
path
traversal,
we
just
don't
have
that.
G
But
leading
into
that,
we
will
be
adding
to
the
redirects,
probably
something
to
deal
with
negotiation
if
the
web
adds
it.
So
there's
a
comment
that
the
web
doesn't
want
to
add
content
negotiation
to
the
type
assertion,
but
that
doesn't
mean
it'll
be
true
for
everything
in
the
future.
But
if
it
is
supported,
we
have
to
figure
out
how
we're
going
to
integrate
it
and
that's
going
to
be
rough.
So.
D
G
D
Like
worked
out
in
practice
and
like
the
web,
has
things
worked
out
in
practice?
I
think
dominic
just
hasn't,
given
a
good
argument
for
why
it
should
be
part
of
the
cash
key.
You
know
we
presented
an
alternative
design
with
spectex
that
would
just
work
without
it
being
part
of
the
cash
key
and
yeah.
I
think
it's
just
weird.
G
D
Yep
seems
like
that,
but
it
also
seems
like
the
impact
in
real
life
in
both
cases
will
not
be
so
bad
right.
That's
sort
of
my
calculation
for
letting
this
slide.
D
G
Yeah,
I
think
you
might
miss
the
goal
of
next
meeting
asking
for
stage
three.
B
G
Feature
he's
stating
that
he
wants
various
guarantees.
G
D
D
G
Compromise
we
can
talk
about
it
sometime,
you
can
schedule
an
issue,
but
I
do
not
think
it
is
viable
to
not
match
the
web.
D
D
No,
I
I
just
mean
more
concretely
that
we're
only
including
it
as
part
of
the
cache
key
on
the
web,
because
there's
only
one
working
value,
because
you're
never
going
to
have
multiple
cash
entries
for
the
same
resource.
Unless
it's
this
that's
sort
of.
Why
I'm
okay
with
this,
because
the
same
the
same
rationale
should
apply
for
the
web
like
the
web.
Also
shouldn't
have
multiple
cache
entries
for
the
same
for
the
same
specifier,
just
with
different
just
with
different
assertions.
That
would
be.
That
would
be
broken
either
way.
D
You
know,
but
in
practice
it
shouldn't
have
that,
except
in
weird
edge
cases,
that's
sort
of
why
it's
okay,
I
thought.
G
G
D
F
Yeah
speaking
of
modules,
I
suppose
that
I
should
give
a
little
bit
of
an
update
on
the
work
on
cess.
So
I
have
pull
requests
out
that
add
support
for
third-party
modules
in
the
in
the
compartment
api
by
introducing
a
static
module
record
interface
and
that
interface
implements.