►
Description
This week we discuss two topics of ShadowRealm, how to represent wrapped functions, particularly their name and length, and opine on a future proposal to allow SharedArrayBuffers to transit between shadow realms.
A
C
Yeah
I
can
give
an
introduction
of
what's
going
on.
I
just
two
two
topics
that
have
been
raised
and
they
are
definitely
topics
that
would
need
consensus
and
we
intend
to
go
to
the
tc39
meeting
after.
We
have
an
informed
decision
at
this
meeting
here
or
if
we
need
more
meetings,
but
we
definitely
need
like
an
informed
decision.
C
Yeah,
sorry,
I
don't
yeah,
I
don't
have
a
camera,
should
I
try
it
into
it
to
use
the
camera
here
thanks.
I
just
saw
like
people
freezing
and
turning
off
their
cameras,
so
it
was
not
specified
what
to
do
with
the
name
and
length
of
the
wrapped
functions
when
the
import
value
or
the
evaluation
of
the
the
evaluation
result
from
the
shadow
realm
evaluate
ends
in
a
callable,
so
we
receive
the
wrapped
function,
but
what
is
their
name
and
lymph?
So
the
question
here
is
more
on
what
it
should
be.
C
I
currently
have
a
pull
request
with
some
pre-work
done,
leading
to
one
direction,
but
also
like
it's
not
exactly
the
direction
that
I
there
is
my
favorite.
The
current
per
request
is
saying
is
getting
the
same.
Steps
is
cloning,
the
steps
from
function
bind
function,
prototype
bind
and
it's
currently
sending
the
name
of
the
wrap
function
with
a
prefix
wrapped
space
and
the
name
of
the
function
from
the
other
realm.
C
Remember
that,
like
the
name
property
is
not
writable,
but
it's,
it
is
configurable,
so
kind
of
like
it's
user,
it's
able
to
like
user
customization
is
possible
in
both
ways
in
both
realms
somehow
like.
If
you
don't
have
any
control
and
the
current
option,
it
follows
the
same
steps
from
function:
prototype
pine.
It
actually
creates
an
abstraction
that
should
be
reused
by
function.
Prototype
bind
adding
the
prefix
wrapped
space
to
the
name,
and
it
does
not
account,
although
it's
not
try
to
observe,
what's
the
current
name
of
the
function.
C
C
Unless
you
treat
that
name
for
what
I
discussed
internally
at
salesforce
with
karidi
and
rick,
we
have
no
need
for
this
prefix
and
we
kind
of
like
we
don't
love
the
idea
of
using
rapt
as
a
public
to
to
become
a
like
out
of
the
specs
user
level.
Name
feature
like
we
see.
No
reason
to
to
set
that
into
stone
like
rapt
is
just
like
spec
language.
C
C
D
A
A
A
D
C
So
mark
currently
in
chrome,
just
to
reproduce
like
if
I
have
a
function,
fn,
which
name
which
name
is
fn
and
if
I
create
a
bound
function
of
it
called
b,
any
name
like
I'm
calling
it
b.
If
I
do
the
function
prototype
to
string
dot
call
on
b,
I
only
get
an
anonymous
function
like
a
function
with
no
name
and
the
native
code
inside
this
is
the
current
behavior
in
chrome,.
D
Okay,
and
by
native
code,
we
mean
the
open,
curly,
open
square
bracket
native
space
function
or
whatever;
yes,
yes,
okay,
okay!
So
what
it?
What?
What
do
we?
Currently?
According
to
the
current
spec
current
draft
spec
for
shadow
realms?
What
does
function
prototype
to
string.call
on
a
wrapped
function?
D
C
C
C
C
C
A
D
D
I
think
that
the
the
bound
bound
bound
behavior
is
very
unfortunate,
and
in
retrospect
I
think
that
if,
if
I
had
been
aware
of
that
at
the
time
I
probably
would
have
argued
for
some
some
logic
to
prevent
it
from
nesting
like
that
for
bound
functions.
It
doesn't
matter
that
much
because
typical
use
case
doesn't
keep
rebinding
it
for
wrapped
functions.
D
The
typical
use
case
will
keep
wrapping
it
and,
in
fact,
not
actually
wrap
it
when
it
wraps
it,
because
if
you
know
a
wrap,
a
a
wrapping
of
a
wrapping
of
function,
foo
is
behaviorally
identical
to
the
the
final
wrapping
of
the
function.
Food.
The
fact
that
it's
going
through
an
intermediate
wrapper
is
actually
not
observably
part
of
the
semantics
in
any
way
it
sounds
like,
except
for
this
wrapping
of
the
name.
B
D
Oh
god,
this
the
the
observability
of
lifetime
is
just
always
coming
back
to
bite
me
other
than
observability
of
lifetime
observability
of
lifetime.
There's
there's
you
know
we're
trying
to
do
this
very,
very
delicate,
dance,
around
implementation,
freedom
versus
strong
enough
constraints
that
you
can
write
meaningful
programs
yeah.
So
so
let
me
so
let
me
say,
aside
from
aside
from
observability
of
garbage
collection
lifetime
through
weak
references.
B
D
Okay,
so
yeah,
I
remember
the
revocate
revocability
thing
and-
and
I
think
I
might
I
might
certainly
participated
in
that
discussion
and
yeah.
We
don't
have
that
now
and
if
we
had,
if
we
had
it
it
would
be,
it
would
be
via
something
new
being
introduced
that
that
beyond
what's
in
there
now,
so
I
think
the
answer
is
yes,
they
are
equivalent.
D
C
I'm
not
complaining,
and
please
help
me
until
I
finish
this.
I
think
this
is
a
special
treatment,
but
I
think
it's
fine,
because
the
next
topic
will
be
a
list
about
a
special
treatment
and
like
observing
that
the
object
is
a
special
object.
So
the
this
object
is
a
wrapped
function.
So
let's
give
it
a
special
treatment:
let's
get
the
target
and
create
a
new
wrapped
function.
C
So
in
this
sense
I
think
it's
going
to
be
fine,
although
I
have
just
another
comment
about
the
the
wrapped
functions,
one
of
the
things
that
we
observe
like
we.
We
try
to
observe
like
to
just
like
rough
analyses,
and
I
believe
we
are
not
going
to
be
like
we
don't
have
use
case
for
transferring
the
same
rap
functions
back
and
forth.
C
It's
more
on
the
execution,
as
matthew
has
mentioned,
it's
more
like
grabbing
one
function
to
execute
it
many
times,
but
not
like
sending
the
function
back
and
forth
many
times,
and
still
this
name
is
user
configurable.
Whenever
I
have
this
wrapped
function,
the
name
is
user
configurable.
So
I
can
delete
and
set
another
name,
remove
prefix
or
create
many
wrapped
prefixes.
B
I
think
this
points
to
a
problem
with
the
unwrapping
there's
two
problems
with
it.
This
configuration
problem
and
also,
if
you,
if
you
take
the
name
of
the
original
function
and
the
length
when
you
re-wrap
it,
you
would
have
to
cache
those
original
ones
when
the
function
was
originally
wrapped
and
copied
those
from
the
wrapper
or
else
you
would
be
able
to
observe
when
you
re-wrap.
C
Yeah,
in
the
same
in
the
same
line
when
you
have
like,
if
you
just
re,
wrap
the
the
target
function,
the
original
function,
one
of
the
things
here-
it
makes
more
sense
for
me
to
just
reuse
the
name
or
of
the
target.
So
you
don't
have
special
treatment
like
if
you're,
let's
say,
if
you're
wrapping
it
for
the
first
time,
you
give
it
perfect.
But
then,
if
you
wrapped
it
again,
you
get
the
target.
But
now
it's
like
you
remove
this
consider
the
wrapped,
because
you
cannot
account
for
that.
C
C
D
C
I
can
try
to
give
an
example
like
let's
say
in
realm:
a
you
have
a
function
named,
do
something
and
you
receive
it
in
realm
b
as
wrapped.
Do
something
when
you
send
it
back
to
realm
a
you.
Can
just
call
it
again,
wrapped
do
something,
but
everything
would
be
like
okayish,
but
this
is
user
configurable.
So,
let's
go
again
like
on
realm
a
you
have
a
function
that
is
called.
C
C
B
I
there's
actually
a
bigger
problem
with
the
renaming
which
is
again
observability,
so
if
in
realm,
eights
do
something
you
send
it
to
written
b,
it's
wrapped
do
something
realm
b
overrides
that
name
to
set
it
to
well,
do
something
else
and
removes
rap
when
you.
If
we
go
by
mark's
suggestion
of
looking
at
the
original
name,
it
shouldn't
be
the
case
to
be
able
to
observe
the
original
name.
Again,
you
should
do
get
the
overall
name.
A
I
guess
I
guess
it
wasn't
exactly
the
same
as
what
I
was
going
to
bring
up,
which
is
never
prefixing,
so
just
copy
the
name
copy
the
length
it's
an
it's
an
own
property
on
the
wrapper.
If
you
wrap
it
again,
then
you're
going
to
get
the
same
data
unless
it's
been
modified,
but
there's
no
special
trickery.
You
just
read
the
property
and
make
a
copy
of
it
on
the
new
value.
D
D
I
think
the
lifetime
issue
should
allow
the
implementation
to
shorten
regardless
in
terms
of
not
keeping
the
intermediate
wrapping
around
because
after
creation,
even
if
we're
taking
the
name
from
the
intermediate
wrapping
once
we've
created
it,
there's
no
reason
for
the
for
the
second
wrapper
to
keep
the
first
wrapper
around.
So
implementations
will,
in
fact
at
least
sometimes
drop.
The
first
wrapper,
if
only
the
second
wrapper,
is
being
retained
and
we'd
like
the
spec
to
reflect
the
shorter
lifetime.
That
implementations
will
actually
want
to
implement.
A
B
A
B
D
D
D
A
C
C
C
C
C
Yeah,
I
remember
you
as
one
of
the
people
who
I
early
advocated
for
for
that,
at
least
for
this
topic
to
be
discussed
and
caridian
wreck.
They
took
some
time
to
to
develop
about
ideas
and
we
discuss
internally.
We
we
have
some
similarities
as
well
in
the
web
with
like
web
workers,
you
can
actually
send
share
the
right
buffer.
You
you
get
a
new
shared
array
buffer
created
in
the
other,
in
the
worker
containing
the
same
target
internal,
the
same
the
same
buffer.
C
D
Yeah
on
structured
cloning,
let
me
just
say
that
I
I
there's
I
made
a
lot
of
comments
on
the.
I
think
it
was
on
a
github
thread
on
that.
In
any
case,
it
was
at
a
public
place,
I'm
pretty
sure
it
was
on
the
github
thread.
Structured
clone
as
it's
currently
specced
is
incompatible
with
javascript
and
cannot
and
can
never
enter
the
javascript
language
without
major
observable
changes
to
the
spec.
C
C
You,
instead
of
doing
the
structure
cloning,
you
create
a
new
shared
array
buffer
in
the
other
realm
containing
the
same,
the
equivalent
or
the
respective
internals
of
the
shared
array
buffer.
That
way,
you
have
a
special
treatment,
but
for
some
native
javascript
functionality
you
could
not
do
otherwise
and
the
main
difference
from
workers
is
that
you
don't
have
structural
cloning,
so
you
don't
have
any
copy
of
the
the
actual
properties
of
the
object.
Instance,
you
just
have
a
new
shared
array
buffer.
You
don't
even
consider
subclassing
or
anything.
C
C
B
Up
the
guest
I
wrote
on
on
this:
it's
it's
in
the
agenda,
I'll
post
it
here
again.
My
concern
with
your
approach
is
that
it
introduced
a
precedent
for
implicitly
allowing
some
non-primitive
and
non-callable
through
the
callable
bandari,
and
it's
also
a
precedent.
It's
also
a
solution
that
doesn't
solve
for
every
type
of
more
complex
object.
B
That
may
want
to
be
shared
array
buffer
being
an
explicit
an
explicit
example
where
array
buffer
has,
if
you
want
to
transfer
from
one
realm
to
another,
you
have
to
explicitly
express
your
intents
to
detach
it
and
and
no
longer
want
to
use
it.
So
this
simply
passing
as
an
argument
to
a
callball.
It
doesn't
leave
any
place
to
to
express
that
intent
and
that's
why
I
believe
an
implicit
which
is
basically
a
simple
clone
is
not
the
right
approach.
B
B
So
we
would
have
to
also
virtualize
the
shadow
role,
of
instance,
the
schedule
and
constructor
at
the
same
time,
to
make
sure
it
creates
a
shadow
realm
that
has
the
same
type
of
cloners.
That
can
be
recognized
on
the
other
side,
so
I
mean
this
is
not
unlike
what
a
membrane
on
top
of
a
callable
battery
would
do
in
any
way.
In
the
first
place,.
C
Yeah
okay,
so
we
discussed
that
I
I
brought
that
to
to
breaking
career's
attention.
I
think
they
had
a
conclusion
and-
and
they
observed
that
and
to
discuss
that
I
can
tell
you
that,
unfortunately,
I
cannot
bring
you
like
the
actual
conclusion
about
it,
because
I
I'm
sorry
I
don't
remember,
and
they
should
be
more
on
the
technical
details
of
that,
but
it's
unfortunate.
We
also
have
this
company-wide
event.
C
One
of
the
things
for
this
president
for
introducing
this
precedent.
It's
actually,
I
think
this
president
would
be
similar
to
what
mark
say
like
if
those
guys
have
a
special
treatment
for
for
any
kind
of
object.
You
do
the
same
treatment
for
rapt
like
if
you
just
reuse
the
target
of
a
wrapped
function.
Yeah
you
observe
the
internal
like.
Is
this
a
wrap?
Is
this
a
wrapped
function?
C
C
Funny
enough,
you
bring
I'm
starting
to
think
about
one
thing.
I
believe
this
per
request
is
actually
creating
a
newer
rate
buffer
in
the
other
realm,
and
this
new
array
buffer
is
actually
getting
the
intrinsic
shared
array
buffering
creating
a
new
instance.
So,
even
if
you
virtualize
everything,
you
get
an
instance
of
an
actual
shared
rebuffer.
So
if
you
don't
treat
that
you
could
probably
have
access,
so
you
already
have
that
with
wrap
functions
anyway,
so
the
main
brains
would
need
to
handle
those
too.
C
C
C
It's
kind
of
like
right:
you
already
have
this
with
wrap
function,
so
we're
having
a
shared
array
buffer
if
you
create
a
new
shared
array
buffer
using
the
36
which
you're
going
to
have
access
to
to
the
intrinsics
of
2036
in
the
other
realm.
The
other
realm
also
needs
to
to
give
some
treatment
to
that
received
shared
array
buffer
so
that
that's
not
I'm
sorry.
It
was
just
like
lovely
thinking
here.
D
C
C
C
D
C
Well,
the
wrap
function
yeah,
if
you
like,
still,
if
you're,
exposing
the
wrap
function
to
an
user,
you
cannot
expose
it
directly
because
they
they
still
have
access
to
to
function
prototype.
That's
the
thing
like
shared
array.
Buffer
is
not
creating
a
new
precedent
on
this
part,
only
actually
exposing
the
primordials,
because
wrapped
functions
already
has
access
to
the
promo
right.
B
But,
as
I
said,
wrapped
functions
are
like
the
function.
Prototype
is
undeniable.
You
can
always
get
at
it
through
syntax,
where
you
cannot
get
at
the
shared
array
buffer
prototype
through
syntax.
You
can
deny
the
the
global
constructor
and
then
that
problem
would
never
have
access
to
it,
and
now
you
you've,
you've
introduced
a
way
of
just
bypassing
that
object
as
an
argument
from
another
realm
intrusive
way.
B
C
D
So
technically
it's
not
undeniable,
but
practically
you
know
whether
you
know
is
it
undeniable
enough
for
matthew's
point
to
be
a
practical
reason
to
avoid
doing
this,
and
I
don't
have
an
opinion
on
that.
Yet
the
I
will
also
say
by
the
way,
with
regard
to
matthew's
extensible,
cloner
matthew,
and
I
had
a
long,
long
discussion
on
this
last
night.
D
What
I
have
in
mind
specifically
is
a
static
module
record
and
that
the
built-in
cloner
copy
clone
and
probably
re-rename
it
to
something
else,
but
if
not
clone
anything
else,
including
simple
objects
and
simple
arrays,
and
in
that
sense
the
built-in
mechanism
to
become
something
like
a
cloner
needs
to
be
extended
by
user
code.
So
everything
that
can
be
done
by
user
code
must
be
done
by
user
code
to
have
something
that
seems
to
be
a
cloner.
D
And
this
is
consistent
with
the
philosophy
we've
already
taken
in
shadow
realms,
that
the
coral
boundary
is
providing
almost
nothing
from
membrane
functionality,
but
it
provides
the
minimal
primitive
functionality
that
you
need
so
that
all
of
the
rest
of
the
membrane
can
be
built
in
user
code.
I
think
I
think
that
it's
at
least
plausible
that
we
should
follow
that
philosophy
with
regard
to
cloning
as
well.
C
Please
take
it
with
a
grain
of
salt.
I
of
course,
like
I
have
some
preference
for
the
simplicity.
I
also
understand,
like
the
reasons
as
you're
putting
down
here
some.
Some
of
the
reasons,
although
my
personal
note
is,
doesn't
mean
anything
I
need
karidy
and
rick,
and
I'm
gonna
send
you
to
them
like
a
notice
like
I'm
gonna,
ask
them
to
reveal
again
and
try
to
to
capture
all
of
these
and
consider
like
how
is
that
option
also
like
workable
for
us?
What
what
we
want?
C
D
So
let
me
say
for
shared
array:
buffers
leo's
perspective,
I
think,
is
plausible.
If
you
take
shared
array
buffers
by
themselves
as
the
as
the
problem
case.
Likewise
for
shared
array,
buffers
plus
static
module
records,
the
the
one
that
creates
the
show
stopping
problem.
For
me,
that's
along
the
lines
of
matthew's
objection
is
array
buffer
and
the
reason
why
array
buffer
is
the
problem
case
is
that,
because
it's
an
ownership
transfer,
the
original
loses
its
functionality.
D
The
original
becomes
a
what
what's
what's
the
name
for
it,
a
not
truncated,
detached
thank
you.
The
original
becomes
detached,
whereas
for
shared
array,
buffers
or
anything
else,
just
going
through
the
call.
You
know
for
shared
array
buffers
and
all
the
things
that
currently
go
over
shared
array
buffers.
D
Let
me
sorry
to
go
over
the
column,
boundary
like
functions,
and
if
we
added
static
module
records
that
all
of
those
things
the
original
has
no
loss
of
functionality
so
having
it
simply
encounter
a
membrane
and
having
it
get
shared
on
the
other
side
does
not
cause
a
local
surprise.
Detaching
is
a
local
surprise
and
that's
where
matthew's
objection
that
there
has
to
be
some
expression
of
intent.
C
And
just
as
a
also
as
another
note,
shu
himself
asked
for
for
this
topic
to
be
a
follow-up
proposal
and
not
a
stage
three,
I
think
for
what
we
are
discussing
here
and
like
not
having
a
final
conclusion.
It's
like
we
continue
to
investigate.
I
think
it's
reasonable
to
have
this
as
a
follow-up
and
not
block
stage.
Four.