►
Description
Updates with Caridy.
A
B
Yeah,
the
on
the
records
and
tuples,
mostly
on
on
their
single
as
weak
map
keys.
I
believe
the
the
the
latest
update
on
that
is
that
we
are
going
to
allow
well
done
symbols
as
with
map
keys,
but
we
are
not
going
to
allow
symbols
created
via
symbol.
Therefore,
those
are
the
ones
that
will
not
be
suitable
as
a
key
in
a
weak
map,
so
that
seems
seems
like
we
have
a.
B
Yesterday
was
about
the
predicate
and
then
whether
or
not
the
predicate
should
be
about
the
nature
of
the
symbol
or
the
predicate
should
be
about
whether
or
not
something
can
be
a
key
and
a
weak
map.
It
seems
that
for
an
implementer's
feedback,
the
the
the
simple
solution
would
be
to
have
a
predicate
for
the
nature
of
the
symbol.
So
whether
the
symbol
is
a
register
symbol
or
is
it
well-known
symbol
or
any
other
characteristics
of
the
symbol
seems
that
implementers
are
fine
with
that
and
then
in
user
land.
B
B
B
We
don't
know
yet
what
else
we're
going
to
add
to
to
the
weak
maps
as
keys
and
so
on,
and
because
the
moving
target
in
the
future,
it
might
be
a
breaking
changes
or
a
compatibility
problem,
and
we
will
not
be
able
to
really
make
changes
in
the
future
to
the
weak
markets
which
I'm
I'm
okay
with.
So
those
are
the
two
main
points.
B
I
think
there
were
some
more
things
about
records
and
tuples
on
the
on
type
of
script
specifically,
but
I
didn't
follow
up
on
on
the
details
there,
so
I
don't
know
the
details
of
it,
but
obviously
typescript
has
already
toppled
on
and
so
there's
a
terminology
there
and
some
backlog,
part
of
it
and
so
on.
But
I
didn't
really
follow
up
all
the
details
in
that
that
topic.
So
those
are
the
the
two
things
about
symbols
as
we
map
keys.
So
you
have
any
comments
or
anything,
let
me
know,
but
I
guess.
A
B
B
A
B
B
A
C
Yeah,
the
thing
is
only
a
registered
symbol
can
be
a
faithful
emulation
of
a
well-known
symbol.
So
if
you're
trying
to
shim
a
well
a
new,
well-known
symbol-
and
you
can
only
if
you
do
it
with
an
unregistered
symbol-
there's
no
way
to
do
it
with
an
unregistered
symbol.
Without
coordination
such
that
multiple
rem
realms
that
are
then
put
into
contact,
have
the
same
identity
for
the
shim,
well-known
symbol.
A
A
C
To
do
that,
you
would
have
to
wrap
the
genuine
weak
map
and
the
genuine
map
use
the
predicate
to
see
what
kind
of
symbol
it
is
and
if
it's
a
registered
symbol
put
it
in
the
internal
map
rather
than
the
internal
weak
map.
So
it's
a
mess,
but
it's
okay,
because
shims
are
often
a
mess.
So
so
no
objection.
D
C
A
B
A
D
C
C
Yeah
the
fact
that
they're
yeah
being
able
to
to
have
a
predicate
for
well-known
symbols
so
so
right
now,
we've
got
some
symbols
that
are
not
static
properties
on
the
simple
constructor
that
are
treated
as
well
known
by
some
implementations
or
what
is
the
status
of
that?
What
was
I
remember,
being
very
confused.
A
C
We
have
one
of
these
almost
invariants
in
the
language
that
could
be
a
genuine
invariant
if
we
clean
things
up,
which
is
that
the
symbols
that
are
named
by
string
named
properties
on
the
symbol,
constructor
are
exactly
the
well-known
symbols
and
the
I
think
it's
very
unfortunate
that
there
seems
to
be
a
well-known
symbol.
That's
not
that's
not
a
static
property
of
the
symbol,
constructor,
just
because
it's
a
almost
regularity
that
could
as
well
be
irregularity
at
this
point.
B
D
A
A
A
A
A
A
C
A
B
A
C
C
A
A
A
C
C
B
B
B
B
But
specifically,
the
is
the
global
object,
the
rom
and
what
they,
what
they
call
the
context
of
the
setting
objects,
which
is
basically
the
update
object
that
contains
all
the
information
about
the
environment
like
this
is
really
the
the
window.
The
details
of
the
window,
so
that
one
to
one
to
one
relationship
is
now
brought
is
now
no
longer
true
because
you
might
have
multiple
global
objects
than
wrong
that
are
under
the
same
setting
objects.
So
it's
no
longer
one
two
one
one,
but.
A
B
A
B
So
as
a
result
of
that
now,
in
the
places
where
we
you
reference,
the
current
rom
or
the
current
global
object,
and
so
on,
which
is
referencing
to
this
one
to
one
to
one
relationship
no
longer
holds
water.
So
you
now
have
to
do
an
inventory
of
all
that
and
either
say
the
current
rom
or
the
current
global
object,
or
you
have
to
say
the
current:
the
root,
the
current
root
rom
or
the
current
root
global
object
or
the
current
or
the
current
settings
or
objects.
B
Yeah
yeah,
so
there
was
a
pushback
there.
So
dominic
proposed
a
couple
of
options:
option
one
is
to
take
the
bullet
and
do
it
in
html
option.
Oh
that's
option
two
option.
One
for
him
was
to
make
changes
in
262
to
somehow
introduce
the
concept
of
the
current
rom
on
the
realm
which
in
262
we
don't
have
that
so
how
to
make
significant
changes
to
define
that
new
concept,
because
we
just
don't
have
like
this-
is
on
the
host,
not
on
the
on
the
language
itself.
B
B
B
A
Is
for
rom
yeah,
the
module
graph
assumes
for
a
real,
but
it's
still
going
to
be
a
single
module
map
for
the
whole
settings
object,
except
that
there
will
yeah.
There
will
be
different,
multiple
module
graphs
in
it
and
with
compartments.
There
will
also
be
multiple
so
for
compartments.
I
guess
it
will
be
switching
that
module
map
to
be
key
per
compartment
instead
of
being
keep
per
realm.
A
B
I
think
I
think
we're
gonna
do
it.
I
think
we're
gonna,
do
it
it's
just
a
matter
of
someone
has
to
do
the
work.
Someone
has
to
take
that
bullet
and
it's
kind
of
the
hot
potato,
but
maybe
we
can
we
can
figure.
Who
can
do
that
and
it's
just
like
different
different
aspects,
so
we
have
to
do
it
in
multiple
places.
A
But
so
that
matches
my
understanding,
like
262,
doesn't
have
a
notion
of
current
realm
or
anything
like
that.
I
mean
it
has
a
notion
of
current
realm
in
this,
in
the
sense
that
it's
the
one
executing
right
now.
The
fact
that
the
the
incubator
realm
is
nothing
special
in
the
sense
of
of
262.
Technically
it
could
stop
executing
completely
and
never
have
anything
back
on
the
stack
anymore
on
its
stack
anymore.