►
From YouTube: SES Meeting: Import Assertions and Realms
Description
Dan Clark visits to talk about import assertions and enforcing a limited set of module types. Jordan Harband visits to discuss Realms progress.
A
B
Okay,
and
hopefully
folks,
are
seeing
those
slides,
let
me
know,
if
not
cool,
so
I'm
assuming
that,
like
most
participants
in
this
meeting,
have
some
context
about
import
assertions.
What
those
are
I
can
happy
to
give
more
background,
if
not
just
let
me
know,
but
just
kind
of
diving
straight
into
the
problem
that
I
wanted
to
talk
about
today.
B
B
The
web
html
will
always
fail
the
module
graph.
If
some
module
type
assertion
is
present.
That's
not
recognized
basically
for
security
reasons.
I
don't
think
that's
I
don't
think
that's
too
controversial,
but
the
thing
we're
trying
to
sort
through
is
like.
Should
we
try
to
standardize
that
behavior
to
where
all
hosts,
if
some
module
type
assertion
exists,
should
all
hosts
like
fail
in
that
similar
way
to
kind
of
match
the
web?
B
Javascript
is
assumed,
but
maybe
I
support
json
modules
like
css
modules,
whatever
it
just
be
a
static
list
that
the
host
gives
to
ecmascript
and
then
based
on
that
list,
when
ecmascript
looks
at
like
what
module
type
when
ecmascript
looks
at
a
module
type
assertion
in
an
import
statement,
if
some
unrecognized
one
that's
not
in
the
list
is
seen,
then
the
import
will
be
rejected
and
that's
that's
pretty
much
pretty
much
all
there
is
to
it.
Yes,.
C
B
D
E
B
I
I
I
think
I
should
clarify,
because
I
think
I
think
I
like
misspoke
there,
it's
like
it's,
not
that
it's
called
once
it's.
I
think
when
I
wrote
it
in
my
little
draft
pr,
it's
like
the
language
was
that
every
time
it's
called
it
should
return
the
same
value.
So
it's
not
it's
not
cached
but
like
it
can't
change.
So
I
think
that's
how
I
currently
have
it
written
so.
C
B
Should
we
have
more
of
a
limitation
on
what
the
hosts
for
what
they're
allowed
to
do
there
for
like
assertions?
They
don't
support
where
like
to
to
kind
of
wrap
up
with
where
we
concluded
that
we
concluded
or
didn't
conclude
at
the
dc39
meeting,
like
the
the
problems
here
are
like
around
virtualizability
of
this
like
for
the
web.
B
It's
like
this
is
kind
of
straightforward
because,
like
the
supported
assertions
like
are
not
really
not
really
going
to
change
but
like
with
other
hosts
and
with
with
knowing
with
bundling
tools,
there
might
be
user
specified
module
types
types
that
are
polyfilled
in
javascript,
there
might
be
like
a
javascript
implemented
loader,
they
could
even
do
transforms
between
different
types.
Like
an
example
that
came
up
during
the
meeting
was
like.
Maybe
I
have
like,
like
yaml
coming
off
the
wire
like
as
the
apparent
module
type,
but
then
there's
some
transform.
B
B
And
so
this
is
like
in
terms
of
like
solving
this,
I'm
kind
of
left
with
more
questions
than
answers
like
this
is
a
little
bit
out
of
my
area.
So
this
is
kind
of
where
I'd
be
interested
in
some
guidance
on
the
group
from
the
group
in
terms
of
like
first
like
where,
where
to
kind
of
start
in
solving
this
problem
or
like,
does
this
even
sound
like
something
that
like
is
solvable
or
that
we
want
to
solve?
You
like.
B
So
the
problem
would
be
what
we'd
like
to
what
we'd
like
to
solve
would
be
we'd
like
to
make
that
behavior
uniform
between
all
hosts
like
we
would
like
to
have
some
like
we'd
like
to
make
the
behavior
of
import
assertions
as
portable
as
possible,
so
like,
ideally,
the
unknown
type
assertions
would
fail.
The
module
load
like
across
all
hosts
an
outcome
may
be
that
this
is
not
a
problem
that
needs
to
be
solved
like.
B
Maybe
this
is
maybe
this
current
behavior
is
fine,
and
it's
just
okay,
not
having
this
be
uniform
against,
among
all
hosts,
so,
like
kind
of
a
a
like
first
question
to
answer
is
like:
is
this
something
we
even
want,
and
maybe
it's
not
because
like
it
sounds
like
this
could
be
hard
to
do
so?
It's
like
there's
kind
of
a
this
kind
of
two
two
questions
that
I
have
like
one
is
this
something
that
we
want
to
make
uniform
among
all
hosts
like?
B
E
B
Yup,
that
makes
sense
yeah.
That's
that's
kind
of
that
was
kind
of
the
surprise.
For
me
last
the
thing
I
hadn't
thought
about
when
this
came
up
during
the
last
tc-39
meeting,
if
the
so
like
that
that
would
be
one
like
good
outcome
like
if
there's
just
if
it's
like,
there's
no
way
to
make
this
make
sense
with
with
node
then
like.
I
think
that
that
would
be
a
clear
answer
just
like
this
is
not
something
that
makes
sense
to
do.
If
there's.
A
B
Yeah,
so
in
in
in
the
web,
it's
like
a
handshake
between
the
the
mime
type
of
the
resource
off
the
wire,
and
the
import
assertion
must
agree
so
like
today.
No
browsers
supports
a
css
modules
by
default,
so
like
there's
no
way
like,
if
I,
if
I
support
a
type,
that's
not
asserted,
or
if
I
get
like
a
mime
type,
that's
not
a
it's
like
supported
module
type.
Then
it's
always
going
to
fail.
B
A
B
Yeah
like
to
bradley's
earlier
question
like
about
like,
is
this
something
that
we
would
like
is
this
virtualizability,
something
that
we
would
want
to
not
allow
for
environments
like
safe
and
node
like
that
seems
like
that?
That's
not
something
I
would
want
to
do
not
like
kind
of
naively
like
I.
That
seems
like
not
like
something
I
would
want
to
limit
without
a
really
good
reason.
E
E
E
D
C
I'm
sorry
is
this
better?
Yes,
okay,
so
the
assumption
we're
making
in
this
group
is
that
the
compartment
api
is
the
means
by
which
javascript
code
acts
as
host
to
other
javascript
code
and
the
means
by
which
we
achieve
host
virtualizability
and
in
answer
to
what
bradley
just
said.
Also
the
means
by
which
user
customized
customizable
loading
behavior
enters
into
javascript
and
therefore
on
all
javascript
platforms,
including
the
browser.
A
C
A
Yeah,
okay,
but
it
but
it
it
is
on
the
root
realm,
but
it
is.
It
is
arranged
by
the
command
line
in
vacation,
okay,
which
is
spiritually
similar
to
the
virtualized
case,
all
right,
where
it
it's
it's
effectively
like
you
could.
You
could
arrange
the
same
by
having
from
your
root
realm,
creating
a
child
realm
and
configuring
its
root
compartment
with
a
with
an
alternate
module,
loader,
and
that
would
be
spiritually
the
same.
It's
not
like
it's
not
like
monkey
patching
your
module
loader
from
within
a
module
and
that's
sharing
the
same
module
system.
A
Yeah
and
the
web
it
sounds
like
the
web
is,
is
disinclined
to
do
so,
regardless.
I
think
that
it
is
that
the
the
virtualization
mechanism,
either
a
self-mutation
or
the
construction
of
a
child
realm
or
compartment,
is
orthogonal
to
the
question
of
whether
the
specification
should
provide
this
limitation
that
dan's
proposing,
and
I
think
that
the.
A
To
create
an
ecosystem
of
portable
modules
to
maximize
the
amount
of
portability
that
exists
between
browsers,
node
and
other
environments,
and
by
creating
a
limitation
on
what
modules
can
be,
can
participate
in
that
ecosystem
that
it
increases
the
possible
probability
that
a
program
written
for
one
system
will
run
on
another.
Is
that
right?
That's
exactly
right
yep.
F
To
mean
sounds
like
a
an
extension
of
an
existing
problem
that
applications
already
cannot
expect.
The
host
environment,
in
which
they're
running
to
be
consistent,
for
example,
set
immediate,
might
not
exist
in
one
environment
with
mexican
another.
This
is
an
extension
of
that
and
if
you
want
to
have
a
more
consistent
environment
for
those
programs,
this
has
to
be
a
separate
effort
of
these
hosts
having
a
baseline
agreement
on
on
what
the
features
they
support
and.
F
A
Bradley
you
mentioned
transforms,
I
am
a
huge
proponent
of
transforms.
I've
done
module
systems
with
transforms
extensively
in
the
past,
the
what
you're
saying
about
transforms
and
how
they
interact
with
assertions
is
that
a
more
general
problem
that
challenges
the
validity
of
the
concept
of
import
assertions
at
large.
E
So
this
is
really
important
for
things
like
if
you
are
loading,
a
mixed
mode
type,
so
something
with
higher
capabilities
than
javascript,
for
whatever
reason,
maybe
it
loads
things
automatically,
does
some
kind
of
side
effect
when
you
load
it,
you
want
to
assert
based
upon
that
type.
So,
let's
just
say
we
had
a
type
which
was
bundle
and
it
does
a
bunch
of
stuff
like
it
preloads
caches
and
things
like
that
things
that
javascript
can't
do
you're,
actually
asserting
the
type
based
upon
the
bundle
type.
A
E
C
Let
me
let
me
give
an
example
that
that
certainly
stresses
the
constraints.
I
think
it
supports
what
bradley's
saying,
but
let
me
I'll
just
explain
it.
First
in
discussing
the
question
in
tc39
about
importing
json
modules,
the
the
big
controversy
that
we
eventually
resolved
was
whether
the
imported
data
should
be
to
arrive
as
transitively
frozen
or
all
mutable
and
in
resolving
that
it
was
okay
for
it
to
arrive
as
all
mutable.
E
Yeah,
that's
that's
pretty
much
the
case
of
what's
going
on
here.
We
actually
do
this.
Also
for
things
like
policies
where
you
you
could
try
to
load
a
coffee
script
file
or
something
you
assert
the
integrity
of
the
source
text
of
the
coffee
script,
not
of
the
transformed
javascript,
and
so
you
need
to
do
the
assertions
prior
to
the
transforms.
C
E
A
I
think
that
we
should
continue
so
for
one.
I
think
that
dan,
I
think
that
we've
answered
the
questions
that
you
came
to
have
answers
for,
but
if
not
and
if
there's
and
and
if
there's
plenty
to
discuss
on
this
topic,
we'd
invite
you
to
to
book
us
book
us
at
a
future
meeting
to
have
to
continue
this
conversation
there's,
especially
if
you're
interested
in
having
a
conversation
about
how
to
virtualize
how
to
how
to
implement
an
api
that
virtualized
board
assertions
and
in
user
space.
A
H
Yeah,
I
mean
so
I
guess
in
in
general.
What
I'd
say
is
I'm
I'm
always
on
board,
for,
let's
add
a
little
bit
now
and
a
little
more
later
right
like
things
that
can
be
if
they
can
evolve
over
time
right,
that's
fine,
it
certainly
doesn't
ever
have
to
be
all
or
nothing.
And,
however,
I
think
that
we
have
to
be
careful
as
a
committee
c39
does
when
we
advance
something
that
sort
of
boxes
out
other
possibilities
or
when
we
advance
something.
Knowing
that
other
possibilities
aren't
going,
you
know
just
aren't
viable.
H
H
That's
either
the
original
one
or
a
polyfilled
one
doesn't
matter
and
then
just
dot
call
that
safely
on.
You
know
my
arrays.
That's
that's
the
way
I
program.
All
of
my
like
npm
modules
is,
I
call
bind
everything
at
module
level,
so
as
long
as
the
environment
is
clean
at
the
time
the
module's
required
it
theor.
H
H
Problem
of
it
has
there's
something
has
to
be
first
run
code,
but
it
sort
of
concentrates
like
I
just
have
to
create
a
good
realm
at
the
beginning
and
then
all
later
code,
no
matter
how
much
the
environment
has
been
screwed
with
like
in
between,
can
use
that
realm
to
get
to
it.
So
that's
sort
of
my
primary
use
case.
It's
not
my
only
one
and
the
general,
if
I
see
there's
a
hand
raised
if
someone
wants
to
interrupt.
H
H
Interpersonal
dynamics
that
have
led
to
the
current
compromise
and
I
heavily
empathize
with
them.
The
concern
I
have
is
that
is,
is
a
few
things
number
one
it
does
not
appear,
it
does
not
like
it.
It
basically
does
it
does.
I
have
no
confidence
that
a
full
object
like
passing
objects
back
and
forth
version
of
realms
will
ever
be
allowed
to
be
added,
just
the
the
the
form
of
the
arguments
being
presented
against.
That
is
such
that
they
don't
seem.
H
I
I
don't
believe
that
those
people
will
ever
be
convinced
that
it's
a
good
idea
and
thus
they
will
block
it
so
to
me
landing
some
something.
That's
good
enough
here
means
that
there's
not
enough
value
gained
from
to
override
those
objections
in
the
future.
So
I
believe,
if
we
ship
this
current
thing,
that's
all
we'll
ever
will
ever
have
more
or
less
in,
at
least
in
the
respect
that
I'm
talking
about.
C
However,
it
will
be
safer
in
the
sense
that
there's
a
low
level
mechanism,
the
built
the
the
callable
mechanism
itself
that
enforces
the
non-entangling
of
the
object
graph.
Obviously
one
very
well
constructed
membrane
library
can
be
carefully
audited
and
verified
that
it
does
so
as
well,
but
separating
it
out
into
layers
is
a
nice
way
to
gain
to
gain
confidence.
D
To
be
to
be
a
specific
there
on
on
that
comment,
the
errors
is
the
the
big
one,
the
errors,
if
you
have
a
you're,
calling
a
function,
whether
you're
calling
through
the
the
for
another
realm
and
something
throws
there,
you
might
be
able
to
capture
that
error.
So,
in
order
for
us
to
create
a
membrane
with
an
iframe,
we
have
to
be
very,
very,
very
careful
to
not
leak.
Those
are
from
the
other
side
and
that
hasn't
been
multiple
times.
D
It's
very
complex
in
terms
of
what
what
mark
says,
the
the
callable
is
a
little
bit
more
complex,
that's
dvd
for
me,
because
the
one
that
I
implemented
seems
like
it's
not
a
lot
more
complex.
I
would
say
about
the
same,
but
we
haven't
add
a
bunch
of
other
features
that
we
have
in
our
membrane.
So
we
have
to
see
how
that
pan
out.
H
C
Right
this
enforces
safety
just
to
to
make
one
more
elaboration
on
the
user-written
membrane
is
if
the
layering
is
the
better,
the
better
way
to
get
to
safety.
It's
also
still
the
case
that
a
user-written
membrane
library,
with
no
platform
support,
can
still
be
built
according
to
this
layering
and
then
and
then
you
can
still
audit
the
smaller
layer
in
order
to
be
confident
that
the
that
the
larger
layer
built
on
top
cannot
violate
the
constraints
of
the
smaller
layer.
G
H
It's
sort
of
wood
and
with
the
function
sense
like
and
I'll,
I'm
gonna
admit
that
right
like
that,
because
the
reason
I'm
getting
those
functions
primarily
is
to
call
them.
So
as
long
as
I
can
call
them
like
it
would,
but
I'm
not
sure
how
the
internal
spot
stuff
would
work,
and
you
know
so,
that's
it,
but
it's
possible.
It
could
work.
D
Running
running
at
any
given
time,
creating
a
brand
new
realm
that
gives
you
access
to
those
primordials.
Is
it
nice
to
have
with
the
callable
boundary?
What
you
can
get
is
just
functions
that
you
export
from
primordials
that
you
export
from
inside
the
realm.
At
that
point
I
mean
you
cannot
export
the
primordia
itself.
You
have
to
do
some
wrapping
in
case
that
they
need
arguments
or
or
they
return
something.
D
So
it
might
be
some
sort
of
wrapping
if
there
is
only
returning,
primitive
values,
accepting
primitive
values,
yeah
you'll
be
able
to
do
that.
Operations
on
arrays
and
such
would
not
be
useful
because,
okay,
you
have
to
implement
the
membrane
or
something
so
I
would
say
that's
going
to
be
slower
than
just
using
the
one
that
you
have
at
hand
on
the
current
run
time.
D
So
I'll
say
that
if
you
accessing
primordial,
which
is
something
that
we
have
talked
in
the
past,
maybe
we
can
introduce
a
different
proposal
just
to
access
the
primordials,
because
we
know
that
their
language
holds
to
them.
We
can
access
them
at
any
given
time
if
we
have
some
sort
of
identifier
like
dollar,
whatever
similar
to
what
we're
using
the
spec.
Maybe
some
of
that
might
be
something,
and
by
the
way
we
do
exactly
the
same
that
you
do
in
all
the
platform
code
and
software.
We
do
the
same
thing.
D
G
So
let
me
just
try
to
get
back
a
little
a
little
bit
from
from
online
off
talk.
Yes,
the
the
raise
the
the
bar
is
raised
up
as
in
order
to
achieve
your
goals,
jordan,
on
on
the
terms
of
clean
primordials,
you
still
need
to
get
like
you're.
Probably
gonna
need
to
get
like
main
brains
on
top
of
it
and
to
to
get
something
better
like
yes,
because
the
way
that
you're
gonna
be
communicating
through
functions,
etc.
G
To
get
what
you
want,
you
might
still
need
like
get
membranes
on
top.
That
goes
to
the
second
part
that
you
mentioned
you're
concerned
about
like
future
for
shipping
transferring
objects,
that's
something
that
we
discussed
at
the
sas
meeting
last
week
here
that
I
try
to
to
make
it
clear
for
for
for
everyone
here
in
the
meeting
I'm
gonna
make
it
again.
G
That's
what
I
can
tell
like
from
not
breaking
the
confidentiality,
but
it
it
affects
salesforce
like
heavily
and
saying
that
I'm
satisfied
with
just
what,
with
this
just
the
combo
boundaries
would
be
naive,
because
we
we
need
more,
we
we
definitely
want
to
expand.
I
told
this
to
jack
works.
Jack
works
wants
a
better
ground
for
configuration
of
the
realms.
Yes,
we
also
want
that.
It's
just
like
we
we're
trying
to
get
like
to
get
the
whole
war.
We
need
to
pick
the
battles
and
get
this
one
started.
B
G
G
We
have
so
many
other
things
to
explore
here.
I
was
just
talking
this
week
to
my
team,
about,
like
configuration
of
proxies,
that
we
use
mostly
on
main
brains
and
like
how
heavy
is
the
usage
of
proxy
and
how
much
we
can
explore.
Config
configuring
the
proxies,
because
that
also
like,
would
bring
a
lot
of
impact
for
the
usage
of
membranes.
G
But
we
cannot
have
that
with
a
proper
realms
and
the,
and
just
for
one
of
the
other
points
that
I
mentioned
like
that,
the
main
brains
are
as
their
complexity
of
membranes.
Yes,
as
a
caribbean
mark
has
said,
they
are
complex
in
the
the
different
of
com.
Difference
of
complexity
doesn't
change
much,
but
that
doesn't
mean
man.
Grains
are
easy.
Today
are
gonna
remain
easy.
They
are
complex
today,
they're
very
high
bar
for
everyone
to
get
used
to.
G
We
still
get
like
to
stop
and
have
sessions
with
people
who
are
starting
working
with
membranes.
It
takes
them
like
a
some
time
to
get
an
understanding
of
how
membranes
work
and
what
we
need
to
do
membranes
like
people
actually
ask
like
how
main
brains
work.
This
is
a
very
often
question
and
this
is
a
very
high
bar
and
we
recognize
that
that's
one
of
the
things
that
I'm
saying
like
yes,
we
definitely
need
to
work
in
a
like
how
we
actually
actually
expand
that.
G
Today,
you
can
still
like
inject
things
through
import.
I
think
that's
like
one
of
the
most
powerful
things
of
the
callable
boundaries,
because
you
can
still
execute
code
there
in
an
isolated
form
that
you
can
still
extract
the
values
but-
and
you
can
extract
the
values
from
there
through
callbacks
in
in
a
synchronous
manner,
but
you
you
definitely
there's
there's
more
there's
more.
G
Of
course,
I
just
need
to
get
this
step
in,
because
the
pushback
from
some
implementers
are
really
is
strong
for
this,
because
this
is
not
like
their
use.
Cases
like
they
actually
have
this
use
case
in
another
nature
form
I
see
realms
today
like,
as
for
as
we
use
as
a
salesforce
as
a
platform,
we
have
too
many
plugins.
We
have
like
clients
plugins
and
you
we
have
a
marketplace
that
you
can
import
these
plugins.
This
is
one
of
the
examples.
G
It's
not
it's
not
like,
even
like
half
of
the
usage
of
what
we
we
have
for
realms
and
for
browsers.
You
have
the
browser
as
a
platform
and
the
extensions
and
the
extensions
they
operate
in
some
synchronous
communication
as
well,
but
in
some
sort
of
like
isolated
way.
The
browser's
already
solved
their
use
case
for
this.
We
need
to
solve
our
use
case
as
like
having
our
applications
as
a
platform
for
many
users
to,
and
yes,
there
is
much
more
to
explore
from
here.
G
A
F
F
Regarding
the
your
use
case
of
access
to
the
primordials,
I
guess,
if
you
don't
need
access
to
the
objects,
but
just
the
functions
themselves
as
kerry
mentioned.
Maybe
we
should
look
into
a
new
api
to
get
access
to
the
original
primordials
like
that.
It
seems.
We've
had
a
similar,
but
different
need
for
this
for
being
able
to
discover
all
the
object,
primordials
that
might
be
hidden
so
that
they
can
be
frozen
and
passionate
in
scs
shim.
A
Yeah,
just
pile
on
an
agreement.
I
think
that
all
of
everyone
in
here
would
be
satisfied
with
the
original
realm
proposal,
which
gives
direct
access
to
objects,
of
course,
and
for
most,
but
and
also
for
most
use
cases.
I
think
we're
also
satisfied
by
this
incremental
callable
boundary,
though
I'm
obviously
sympathetic
to.
H
So
I
think
how
I
would
respond
to
that.
Is
that
effectively
like
not
forever,
but
let's
say
for
10
years,
which
is
close
enough
for
this
these
purposes,
without
some
change
in
position
this.
I
think
this
is
effectively
all
we'll
get
in
towards
direct
object
access.
I
am
not
convinced
that
this
is
better
than
nothing
in
that
case,
meaning.
I
think
that
this
adds
complexity
to
the
language
that
is
not
warranted
at
all.
Unless
we
can
move
towards
direct
object,
access.
A
H
Because
I
mean,
like
we've,
seen
a
lot
of
things
that
are
hot,
like
low
level
capabilities
added
to
javascript.
I
think
that
I
understand
why
they're
important
like
proxy
or
cimd,
if
it
had
progressed
or
typed,
arrays
and
so
on,
but
like
their
existence,
creates
confusion
and
like
causes
problems
in
the
language,
and
sometimes
it
is
not
like
retroactively.
H
Some
of
these
things
aren't
always
worth
it,
and
I,
this
callable
stuff
is
sufficiently
weird
and
complex
to
me
that
it
feels
like
it
will
be
in
that
bucket
very
soon
and
given
that,
like
all
the
folks
in
this
room,
are
the
ones
who
are
like
interested
in
realms
advancing
and
my
understanding
is
it's
primarily
for
membrane
use
cases.
It's
like
it's
not
actually
like
adding
a
capability.
It
is
increasing
some
safety
like
from
what
mark
said,
but,
like
maybe
there's
other
ways
to
do
that.
H
I
don't
know
I
haven't
put
the
time
in
to
think
about
it,
but
like
the
I
and
I
and
the
other
thing
is
I'm
particularly
baffled.
I
guess
that
the
argument
that
something
is
a
foot
gun
is
being
successfully
used
to
eliminate
it
entirely,
whereas
for
me
it
seems
like
that
is
only
and
ever
an
argument
for
it
not
being
the
default
behavior.
C
Yeah
just
to
make
my
position
clear.
As
I
said,
I
think
this
layering
is
a
very
clever
way
to
get
confidence
that
the
separation
is
preserved,
but
it
doesn't
need
to
be
in
the
platform.
I
think
the
insight
of
the
layering
can
be
embodied
in
how
you
structure
a
membrane
library
that
would
achieve
the
same
safety
goal.
C
The
difference
is
whether
the
safety
is
enforced
by
the
platform,
or
is
something
that
is
chosen
by
choosing
a
library,
and
I
think
that
the
I
think
that
the
football
argument
is
addressed
by
having
there
be
safe
library
choices
in
order
for
the
platform
to
be
a
motivated
safety
measure,
it
has
to
be.
You
have
to
do
that
in
terms
of
who
is
being
protected
by
whom-
and
I
don't
think,
there's
a
who
is
being
protected
by
whom's
story
here
that
justifies
forcing
the
safety
to
be
provided
by
the
platform.
C
E
D
I
like
to
add
few
things:
we
have
only
a
few
minutes,
but
so
I
I
would
not
characterize
this
proposal
as
a
primary
use
case.
Being
the
membrane
for
software,
obviously
membrane
is
important.
Virtualization
is
an
important
bit,
but
I
will
not
characterize
that
the
proposal
as
such
the
proposal
is
about
how
many
different
global
options
you
want
to
have
a
different
global
option
with
the
capability
of
the
language
there.
D
This
is
a
fine
solution,
whatever
you're
doing
there,
if
you
just
spin
it
up
a
plug
in
there
that
receive
numbers
and
produce
numbers
on
the
other
end,
that
works
just
fine,
it's
similar
to
any
other
primitive
values,
and
even
when
we
have
records
on
tuple,
it
will
be
a
lot
more
useful.
I
would
say,
but,
as
a
very
low
level
thing
is,
is
going
to
be
very
interesting
to
see
what
people
would
do
with
that.
D
Similarly,
to
what
happened
with
proxies
yeah
proxies,
add
a
lot
of
complexity
to
the
language,
but
they
open
so
many
doors
that
we
haven't
even
explored.
Yet
that
would
say
that
it
is
a
net
positive
value
that
that
was
added
to
the
language,
not
a
and
not
not
a
negative
value,
and
I
will,
I
will
argue
that
the
realms,
even
with
the
colorful
boundaries,
will
be
very
similar
to
that.
I'm
here
to
see
what
people
will
come
up
with
once
they
start
using
this
and
exploring
what
kind
of
things
they
can
do.
D
I
imagine
that
people
would
be
writing
libraries.
That
would
be
just
a
facade
that
runs
in
the
in
the
in
the
incubator,
realm
that
allows
interaction
via
primitive
values
or
some
sort,
and
then
it
delegates
all
the
operations
to
the
other
rom,
which
is
the
same
process
accessible,
really
quickly.
There's
no
delayed
on
using
any
of
these
performance
penalties
on
using
any
of
these.
D
If
what
you're
dealing
is
with
with
numeric
values
or
some
sort
like
demanding
like
any
any
game
engine,
or
something
that
just
interacting
with
very
primitive
values
that
can
run
in
a
rom
just
fine,
so
you
create
a
facet
with
the
public
api.
You
you
create
interaction
with
the
code
that
runs
inside
inside
the
rom
and
so
on
so
I'll
say.
Yeah
membranes
is
a
a
thing
that
we
want
to
explore.
Virtualization.
D
D
A
I
think
that
well
for
one
we're
at
time.
Thank
you
very
much
for
coming
jordan.
I
think
that
everyone
here
feels
more
heard
than
they
were
a
half
an
hour
ago
and
yeah,
and
if
we,
if,
if
there's
some
benefit
for
follow-up
conversation,
please
do
not
hesitate
to
to
reach
out
to
us
put
some
more
time
for
this.
H
A
All
right,
I'll
I'll
keep
I'll
keep
an
ear
open
for
for
a
time
slot
if
needed
and
again.
Thank
you
also,
dan
and
and
compatriots
on
on
behalf
of
type
assertion
party
import
assertions
looking
forward
to
having
more
conversations
about
that
in
the
future
as
well,
yeah
and
that's
time,
I'm
gonna
stop
the
recording.
Thank
you.