►
From YouTube: SES-mtg: tc39 proposal review
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
No,
what
they
are
are
a
list
of
proposals
that
I
went
through.
I
went
through
the
list
of
tc39
proposals
in
all
stages,
primarily
trying
to
match
names
of
various
sponsors
to
our
group
here
and.
A
Cool,
I
think,
maybe
a
good
way
to
start.
This
exercise
would
be
to
ask
somebody
more
familiar
to
to
go
through
this
list.
C
C
Okay,
we
only
want
to
to
cover
those
that
are
on
the
tce
39
agenda.
Anything
that's
not
being
brought
up
at
this
meeting.
We
don't
need
to
talk
about
it.
B
I
hope
that
we
could.
I.
C
Okay,
and
and
among
them
prioritizing
the
things
at
later
stages
also
does
make
sense,
because
they're
the
ones
that
are
that
we're
in
more
danger
of
if
there's
something
that
needs
to
be
fixed.
Okay,
so.
A
All
right:
well,
let's
mark,
do
you
know
where
to
look
to
find
out
what's
on
the
agenda
for
the
next
meeting,
and
so
we
can
prioritize
accordingly.
C
Okay
and
you're
gonna
put
it
in
the
link
in.
C
C
C
Okay,
so
I'm
just
going
to
starting
at
section
12,
I'm
going
to
read
the
names
and
for
mo
for
many
of
these,
I
think
I'll
claim
that
they're
not
relevant,
and
if
anybody
else
has
information
to
stop
me
so
string.prototype.replaceall,
I
believe,
is
not
relevant
named
evaluation.
C
I
actually
don't
know
what
that
is,
but
certainly
sounds.
I
can't
not
know
what
it
is.
If
it's
stage
three
somebody
know
what
that.
B
D
The
name
inference
for
functions.
C
Oh,
oh,
okay.
Okay,
I
don't
think,
there's
anything
scary.
There
promise
dot.
Any
and
aggregate
error
is
there's
this.
This
was
driven
by
the
attempt
to
be
sort
of
complete
around
the
duels
of
various
things.
So.
C
C
Rejects
if
any
of
the
components
rejects,
I'm
sorry
reject
the
other
way
around
reject
if
all
of
the
components
rejects
and
accepts
if
any
of
the
components
except-
and
I
I
don't
find
this
a
tremendously
well
motivated
operation,
but
you
know
it's
there
for
symmetry,
and
but
the
new
issue
that
it
raises
is
in
the
case
where
everything
rejects.
C
What
do
you
report
in
the
case
of
promise.all
when
everything
accepts?
I'm
sorry
when
everything
fulfills?
The
thing
you
report
is
an
array
of
the
fulfillments
in
the
case
where
everything
rejects,
you
still
have
to
report
a
rejection.
A
rejection
is
a
single
error,
but
you've
got
multiple
errors
to
report.
So
this
aggregate
error
was
this
new
concept.
That's
introduced
to
jointly
report
all
the
component
errors
as
components
of
the
aggregate
error
and
that
led
to
a
very
long
discussion
about
whether
that
new
aggregation
is
in
a
own
property
or
an
internal.
C
A
new
internal
slot.
I
objected
on
security
grounds
to
a
new
exotic.
Internal
slot,
carries
an
object
reference.
All
the
existing
262
exotic
internal
slots
carry
only
data
like
date
and
therefore
they're
confidentiality
holes,
but
they're,
not
they
they're,
not
capability
leaks,
so
that
was
successful,
but
it
is
now
going
forward
by
proposing
that's
an
own
property.
I
think
that's
all
there
is
to
say
about
that.
B
E
Actually
have
a
follow-up
question
on
that.
It's
true
that
there
are
no
object
bearing
internal
slots
that
I
could
find
in
262,
but
there's
at
least
one
in
402
and
maybe
more
I'm
not
I'm
not
done
looking.
How
do
we.
C
C
Tell
me:
what's
the
one
and
40
tip
I
the
the,
I
find
it
very
scary.
E
Yeah,
well
I
mean
so
I
I'm
part
way
through
through
the
search.
The
one
that
I
found
so
far
is
the
compare
method
of
intel
collater
instances
it's.
E
It's
truly
bizarre
from
my
perspective,
but
but
is
published.
E
Right
so
when,
when
you
create
a
collater
instance,
and
then
you
try
to
access
the
compare
method
of
it,
that
runs
a
getter
which
which
will
return
you
a
function
bound
to
the
receiver
and
it
stores
that,
and
it
will
return
the
same
one
on
subsequent
calls,
which
it
accomplishes
by
storing
it
in
an
internal
slot.
E
D
E
I
yeah
actually,
so
let
me
let
me
put
the
link
in
the
in
the
chat
here
as
well.
B
E
So
it
captures
captures
the
receiver,
binds
a
function
to
it
and
then
stores
it
as
a
slot
on
the
receiver.
E
But
it
is
an
instance-
and
I
and
I
confirmed
that
the
that
the
implementations
conform
to
it-
okay,
so
so
you
could
yeah.
You
could
obviously
use
this
as
a
communications
channel.
If
you
had
intel
on
both.
E
E
Okay,
all
right,
so
that's
that's
the
relevant
information
that
that
I
wanted
from
it
is
basically
like
yes,
402
is
in
play.
Yes,
it's
a
concern
there
as
well
and
and
that
actually
affects
one
of
the
changes
that
I'm
making
now
to
a
current
proposal
for
segmentation.
E
Presumably
so
that
the
so
it
compares
equal
on
subsequent
gets.
So
if.
E
D
E
The
the
thread
from
the
promise
any
discussion,
and
it
seems
like
there
is
at
least
at
least
one
person,
probably
more
on
the
tc39
committee,
that
that
has
this
affinity
for
prototype,
hosted,
accessors
and
and
that
to
me,
feels
like
the
real
source
of
this
kind
of
bug.
C
Yeah
jordan
harban
has
a
very,
very
strong
affinity
for
that
right.
B
E
Is
an
observable
change,
but
it's
in
a
very
minor
space.
E
Unfortunately,
but
again
I
suspect
there
are.
There
are
probably
one
or
two
other
instances.
I
will
send
them
all
in
a
bulk
email,
any
any
others
that
come
up
are
going
to
be
similar
to
this
or
it'll,
be
an
accessor
on
the
prototype
and
and
one
way
or
another
interacts
with
a
slot.
On
the
instance.
C
E
A
B
E
No,
but
what
what
I
so,
I
I
missed,
I
missed
the
normal
time
window,
but
what
is
going
to
be
on
the
agenda?
What
I
am
going
to
bring
up
is
intel
dot
segmenter,
where
there
is
an
instance
that
should
have
a
link
back
to
the
thing
that
created
it,
and
I
want
to
avoid
this
pattern.
I
want
to
use
just
regular
data
properties
rather
than
prototype,
hosted
accessors.
E
Thank
you
I'll
put
that
change
in
now.
I'm
actually
I'm
working
on
it
simultaneously.
With
this
meeting.
E
E
Should
should
I
try
to
put
that
on
the
agenda?
E
A
A
D
E
C
C
D
They're
still
doing
weekly
calls
there's
nothing
really
to
report,
as
they
kind
of
are
discussing,
use
cases
again,
they're
trying
to
strip
it
down
a
lot.
It
got
stripped
down
far
enough
at
one
point.
They
were
only
gonna
talk
about
having
three
decorators
and
not
custom
decorators.
D
The
participants
on
the
call
been
following
wanted
to
do
more,
but
for
now
there's
just
it's
nothing.
To
talk
about.
C
C
Okay,
right
with
a
five-minute
time
box,
they're
not
expecting
to
get
into
anything
controversial.
C
All
right
so
yuyo
is
going
to
be
speaking
about
iteration
helpers,
which
I
know
I
think
I
know
what
iteration
helpers
are,
or
at
least
used
to
be,
but
then
in
her
title
she
says
what
to
do
about
generator
steps.
So
I
don't
know
what
that
is
about.
D
So
iterator
helpers
were
looking
to
reuse
the
generator
infrastructure
within
ecma
262..
The
generator
infrastructure
in
ecma-262,
however,
has
things
like
dot,
throw
or
dot
return
on
generator
results.
So
this
is
just
a
discussion
on
what
to
do
about
it
because
for
iterator
helpers,
some
stuff
doesn't
make
sense.
C
D
C
A
May
I
ask
if
I
I
I
saw
that
observers
are
on
the
list
of
proposals
that
that
alex
brought
up
is,
did
observers
emerge
as
the
duel
of
iterator
and
that
the
generators
are
both.
C
So
observables
were
quite
lively
for
a
long
time
and
then
they
languished.
It
was
when
I
saw
observables
on
the
previous
list
that
triggered.
That
was
what
triggered
the
question
are
these
on
the
agenda,
because
if
somebody
was
picking
up
observables
and
trying
to
advance
them
again,
that
would
be
very,
very
interesting.
C
Were
very
well
designed,
very
well
thought
out
and
most
of
the
most
of
the
the
wind
behind
observables
was
taken
out
by
asynchronous
iterators,
even
though
they're
not
quite
the
same
thing,
there
just
was
no
longer
energy
to
try
to
advance
observables.
Once
we
had
this
asynchronous
iterators.
B
Well,
I
think
another
thing
about
observables
is
the
the
main
person
who
was
the
the
the
jaffar
yeah
jafar
has
kind
of
dropped
off
of
the
tc39
radar.
I'm
not
quite
sure
what
the
story
is
there,
whether
he
was
discouraged
by
not
making
progress
or
whether
his
work
responsibilities
took
him
elsewhere
or
I
don't
know
the
story,
but
in
any
case
he
was
the
main
force
behind
that
and
and
since
he
stopped
participating,
it
stopped
moving.
A
C
A
C
Okay,
temporal
update
so
the
the
relevant
issue
here,
the
I'm
hoping
that
the
only
relevant
issue
here
is
the
one
that's
sort
of
already
been
negotiated,
which
is
that
almost
all
of
the
temper
temporal
is
just
computational.
C
It
does
not
involve
any
io,
does
not
involve
knowledge
of
the
current
of
the
current
time
to
avoid
the
date
mistake,
but
it's
obviously
still
useful
to
have
a
privileged
api
for
finding
out
what
the
current
date
is
and
it's
useful
to
have
one.
Given
the
the
nature
of
temporal.
It
was
apparently
useful
to
have
one
other
than
date.now
so
that
it
could
compose
more
easily
with
rest
of
temporal.
C
So
if
I
recall
correctly,
there's
one
property
on
to
that
temporal
itself
is
a
namespace
object,
there's
one
property
of
it.
That
represents
the
privilege
to
know
the
current
time
and
that
all
of
the
rest
of
it
leads
to
things
that
are
only
purely
computational
and,
and
that
means
that
assess
still
needs
to
tame
it,
like
it
tame's
date.
E
There
are,
there
are
two
others
that
I
can
think
of
so
there's
the
temporal
dot
now,
which
exposes
the
local
information,
including
what
time
is
it
and
there
are
date
time
and
calendar
lookups,
which
also
reach
out
into
the
host.
Although
for
information
that
changes
far
less
frequently
than
the
date
and
time.
E
It
reaches
the
easier
one
to
understand.
Is
time
zone
which
reaches
into
the
t
local
tz
database
to
to
determine
whether
whether
whether
it
is
known
at
all
and
if
so,
what
the
particular
transitions
are
of
a
time
zone
and
then,
similarly
for
calendar,
what
what
calendar
is
the
system
aware
of?
And
you
know
what
awareness
does
it
have
of
the
particular
details
of
that
calendar.
E
A
So
the
so.
E
That's
the
thing
to
watch
out
for,
especially
when
it
comes
to
de-serializing
strings,
which
runs
the
risk
of
privileged
access
to
those
lookups
in
the
in
the
current
representation.
I
believe
there
is
no
such
privileged
access
that
that
the
spec,
when
even
when
deserializing
a
string
or
doing
arithmetic
or
anything
will
cut,
will
invoke
the
from
method
on
the
constructor
of
the
calendar
or
the
time
zone
or
whatever.
E
So
that
makes
it.
I
believe
that
makes
it
tameable.
Certainly
you
can
monkey
patch
the
from
method
and
have
those
effects
realized.
C
So
the
the
question,
the
the
the
taming
issue,
is
not
just
whether
we
can
replace
it
with
something
tame,
but
whether
the
thing
that
needs
to
be
tamed
because
it
represents
some
kind
of
of
privilege
or
iio
is-
is
well
separated
from
the
stuff.
That's
shared.
C
What
I
mean
by
that
is
that,
let's
say
you've
got
multiple
compartments
in
a
realm,
and
you
want
to
give
each
of
the
compartments,
let's
say
a
different
time
zone
as
far
as
temporal
was
concerned,
but
share
all
of
the
prototypes
and
methods
that
are
all
of
the
computational
aspects
of
temporal.
You,
you,
don't
you
that's.
What
you
would
like
to
have
is
that
the
only
things
that
have
to
be
separated
per
compartment
are
these
special
privilege
things
and
everything.
That's
just
about
computing
with
those
things
is
in
shared
objects,
right.
A
C
Oh
okay,
temporal
okay,
so
the
problem
is:
if,
in
order
to
have
a
temporal
dot
time
zone
is
times
on
a
constructor
or
is
timezone
a
namespace.
C
C
I
I
want
to
be
able
to
share
the
constructor
if
the
constructor
doesn't
have
privilege
and
have
only
the
privilege,
be
the
things
that
have
to
be
separately
populated
on
a
per
compartment
basis
to
have
each
compartment
have
to
have
its
own
time
zone
constructor
when
the
time
zone
constructor
mostly
leads
only
to
powerless
computational
things
is
weird,
and
it's
especially
weird
because
there's
if
everyone's
sharing
the
same
time
zone
prototype
that
time
zone
prototype,
has
a
dot
constructor
property
that
points
at
some
time
zone
constructor
that
one
has
to
be
shared
and
therefore
that
one
can't
have
this
from.
C
These
security
concerns
is
to
make
them
separable,
okay,
and
I
think
that,
as
it
went
forward,
they
must
not
have
realized
that
privileged
access
to
current
time
zone.
E
So
from
my
understanding
and
having
the
separation
concerns,
it
seems
like
this
could
be
addressed
by
remo
by
taking
off
the
from
static
methods
from
the
constructor
and
instead
having
siblings,
which
you
know
something
like
instead
of
temporal.timezone.from,
it
would
be
like
temporal
dot,
resolve
time
zone.
C
E
It
is
definitely
worth
bringing
that
up
in
the
meeting
and
given
the
simplicity
of
the
change,
probably
there's
not
a
big
issue
with
it:
either:
okay,.
C
C
Good
okay
function,
implementation,
hiding
I'm
one
of
the
reviewers
on
that,
and
that
was
proposing
two
different
knobs
that
were
not
orthogonal
and
it
was
proposing
the
second
knob
called
sensor.
The
two
knobs
were
called
hide
source
and
sensitive
and
sensitive
was
being
proposed
to
address
security
concerns
and
the
security
concerns
it's
addressing
are
not,
I
you
know,
are
genuine
security
concerns.
They're,
not
my
security
concerns,
so
it
was
hard
for
me
to
reason
about
the
rationale
for
it.
C
If
the
function's
source
is
hidden,
then
a
function.prototype.2string
on
it
gives
you
the
same
kind
of
string
that
gives
for
a
native
function
the
built-in
function,
which
is
a
a
something
that
sort
of
looks
like
a
function,
except
that
it
has
this
funny
syntax
inside
the
body
that
does
not
parse
it's
this
square
bracket
native,
something
the.
C
C
There's
the
orthogonal
form
that
alan
worst
brock-
and
I
prefer,
which
is
there's
there's
a
similar
directive,
called
hide
stack
and
if
it's
present
then
stack
frames
of
this
function
do
not
appear
in
the
error
stack
proposal.
That
is
yet
to
be.
You
know
yet
to
be
moved.
I
think
it's
still
in
stage
one
so
so
that
proposal
has
been
languishing,
but
the
idea
is
that,
whatever
way
there
is
of
accessing
stacks,
those
stack
frames
will
be
hidden.
C
This
function
just
wants
to
disappear
with
regard
to
reflective
examination,
because
it's
sensitive
and
trying
to
pin
down
what
the
security
concern
is
that
sensitive
addresses
is
not
one
that
I've
clearly
understood.
I'm
not
saying
it's,
it's
not
a
good
concern.
I'm
just
saying
that
I
didn't
understand
it.
A
This
feels
like
something
that
people
are.
This
feels
like
more
of
a
developer.
Experience
related
feature
than
a
security
feature,
so
I
I
know
that
we
were
motivated
to
do
something
similar
in
queue
to
hide
cue
stack
frames
in
long
stack,
traces
but
yeah,
just
just
to
make
them
less
confusing.
C
Right
and
likewise
with
membranes
alex-
and
I
have
talked
about
and
alex
talked
to
the
committee
about-
it
would
be
nice
to
be
able
to
have
the
membrane
part
membrane
crossing
part
of
computation
to
be
able
to
have
that
disappear
from
stack
frames,
and
neither
of
these
uses
imply
a
desire
to
hide
sources
of
those
same
functions
so
that
so
the
developer
experience
argues
for
the
orthogonal
hide
source
and
height
stack
in
any
case,
since
only
height
source
is
being
proposed
in
this
proposal,
and
any
concern
with
stack
is
to
be
postponed
to
a
later
proposal.
C
The
chain
which
I
do
hope
I
to
see
advancement
as
I
proceed
to
shim
it
as
part
of
the
session.
C
Okay,
realms,
I
think
we
all
know
what's
up
what's
up
there
number
format,
I
have
no
idea.
D
It's
just
a
way
of
joining
numbers.
There
are
different
separators
in
different
locales.
This
is
really
the
key
point.
There's
a
few
things
about
having
long
or
short
forms
similar
to
how
days
of
the
week
can
be
abbreviated.
A
If
there
were
anything
it
would
be,
it
would
pertain
similarly
to
temporal
in
order
to
find
out
what
the
the
host
locale
is
right.
D
E
It
it
has
the
same
problem
as
as
every
other
formatter
in
intel.
There's
nothing
specific
to
this
one.
C
Right
the
the
intel
with
regard
to
time
with
regard
to
time
zone
and
such
things
intel
is
hopeless,
we've
kind
of
given
up
with
regard
to
intel,
but
just
hoping
to
avoid
those
mistakes
with
temporal.
C
C
Okay,
ergonomic
brand
checks
for
private
fields.
I
really
like
this.
I
don't
think
there's
any
security
significance
here.
C
Basically,
if
you
do
food
in
the
the
private
fields
proposal,
if
you
do
foo
doc,
sharp
bar
to
access
the
bar
private
field
on
food
and
food
doesn't
have
a
bar
private
field,
it
throws
so
this
one
is
basically
saying
that,
since
you
can
already
detect
it
to
ask
the
question,
and
since
private
fields
are
syntactically,
sort
of
cleaned
of
following
some
kind
of
analogy,
with
properties
provide
a
syntax
involving
in
for
being
able
to
ask
the
bullying
question
about
whether
this
object
has
this
private
field,
which
enables
you
to
just
do
an
if,
rather
than
a
try
catch.
B
D
Yes,
so
in
records
and
tuples
calls
they've
clarified
their
reasoning
for
wanting
to
reuse
it
they're
trying
to
mark
things
which
are
syntactic
features
attempting
to
have
some
model
of
integrity
with
the
hashes.
They
view
private
fields
as
having
a
model
for
integrity
about
them.
They
want
to
preserve
that
for
records
and
tuples,
particularly
for
tuples.
They
want
to
have
integrity
around
index
access,
numeric
index
access
and
for
records.
They
want
it
around
string
based
keys.
B
Okay,
I
apologize.
I
just
realized
records
start
with
curly,
brace
and
tuples
with
square
brackets,
so
there's
there's
no
conflict
there.
I
apologize.
C
Right,
no,
no,
it
was
still
a
good
question
because
there's
no
syntactic
conflict,
but
it's
still
occupying
similar
mind
space.
So
the
fact
that
there's
one
story
that
covers
both
was
really
important
because
otherwise
it's
just
two
unrelated
uses
of
the
same
glyph,
which
would
be
unpleasant,
not
fatal,
but
unpleasant.
C
Okay,
so
let's
see
okay,
that
was
a
duration
format.
I
assume
that
that
is.
Does
that
have
any
any
intel
issue
that
we
didn't
already.
That's
not
like
what
we
already
talked
about.
C
Okay,
good
records
and
tuples
there's
there's
a
controversy
that
has
really
blown
up
on
the
issue
thread
and
it
well.
It
doesn't
look
like
there's
any
signs
that
it
will
settle
soon,
so
I'm
sure
it'll
still
be
a
live
controversy
at
the
meeting.
C
Okay,
nevertheless,
I'm
sure
we
will
take
as
much
time
as
it
takes
to
fill
a
time
box
with
this
controversy,
because
everybody's
gonna
be
passionate
about
it,
including
me.
D
So
we've
had
two
phone
calls
for,
I
think
a
total
of
two
and
a
half
hours
over
the
last
two
weeks
on
it.
So
far,
the
the
real
crux
of
the
matter
comes
down
to
the
ability
to
do
a
brand
check
on
records.
I
don't
think
tuples
actually
have
much
controversy
on
them.
Oh.
D
Okay,
so
the
origin
of
the
controversy
comes
down
to
for
a
record.
Record.Prototype
needs
to
have
a
value
should
that
value
be
an
object
null
or
something.
D
D
So
if
we
box
a
record,
there
are
various
ways
to
do
this.
It's
a
primitive!
You
can
do
this
with
any
other
kind
of
primitive.
Every
single
other
kind
of
primitive
has
a
way
of
detecting
that
it
is
a
boxed
primitive
without
the
ability
to
do
a
brand
check
on
it,
because,
let's
say
the
box
itself
has
a
null
prototype.
D
You
get
into
awkward
situations
that
you
don't
know
how
to
do
so.
One
of
the
things
on
the
calls
was
potentially
introducing
a
record
dot
is
static
method
to
determine
if
something
is
a
boxed
record.
B
C
C
The
the
other
controversy
is
what
the
equality
semantics
are
on
records
and
tuples.
The
problem
is,
the
javascript
has
so
many
different,
even
among
the
well-behaved
equalities,
I.e,
everything
other
than
double
equals.
C
They
take
different
stances
with
regard
to
minus
zero
and
that
so
the
question
is:
when
you
compare
records
and
tuples
that
somewhere
deep
within
them
might
be
a
minus
zero
or
a
nand.
How
should
the
record
of
the
tuples
compare
and
this
one's
all
over
the
place.
D
I'd
agree
that
is
probably
the
bigger
controversy
the
ability
to
detect
if
something
is
box,
tuple
is
more
something
that
we
just
need
to
be
mindful
of.
If
we're
caring
about
membranes,
I
know
a
rave
was
in
a
semi-semi,
similar
situation,
but
I
I
don't
think
this
is
new
territory,
at
least
for
the
brand
check.
C
Okay,
definitely
something
for
this
group
to
pay
attention
to
do
expressions
is
this
there.
There
was
a
very
old
proposal.
A
Well,
it
was,
it
was
the
equality,
it
was.
A
brand
check
and
equality
were
the
two
controversies.
C
Yeah,
the
the
the
problems
with
minus
zero
and
then
and
the
need
to
to
repeatedly
argue
about
them
will
survive
humanity.
A
C
Yeah,
so,
okay
so
do
expressions.
There
was
an
old
do
expression
proposal
that
seemed
clean,
except
for
one
thing
which
I'm,
which
at
the
time
I
didn't
think
to
argue
about,
but
if
they're
reviving
it,
I
want
to
argue
about
it.
The
idea
with
do
expressions
is
that,
right
now,
it's
very
awkward
to
say,
statementy
things
like
a
switch
statement
in
an
expression
context.
C
C
The
problem
that
I'm
now
going
to
flag
that
I
did
not
flag
at
the
time
was,
if
what's
going
on
in
a
do
expression
is
just
a
statement.
Body
is
where
all
the
code
is.
Where
does
the
value
of
the
due
expression
come
from
and
the
answer
last
time
was
use
the
completion
value
rules
and
the
completion
value
rules
right
now
are
operational
only
for
eval
and
they
they
and,
in
my
experience,
there's
two
uses
of
the
vowel
in
practice.
C
Then
there's
evaluating
statements
for
effect
or
there's
evaluating
one
expressions
statement
for
value
where,
realistically,
you
think
of
it
as
evaluating
an
expression,
the
result
is
that
people
do
not
often
encounter
the
bizarre
rules
for
completion
value.
The
rules
are
bizarre.
They
will
surprise
people.
I
do
not
want
to
put
those
rules
in
a
place
where
a
normal
programmer
will
encounter.
D
D
There
is
somewhat
general
agreement
that
there
are
a
variety
of
ways
you
can
produce
a
completion
value
which
is,
for
the
most
part
surprising,
but
the
syntax
that
produces
surprising
values
is
actually
somewhat
limited,
and
so
the
idea
is
you
explicitly
error
if
a
if
the
last
statement
of
a
do
expression
is
a
essentially
surprising
syntax,
so
things
like
variable
declaration
loops,
and
that
would
be
an
error
to
have
in
the
tail
position
of
a
do
expression.
C
Obviously,
we
need
to
look
at
what
the
specific
rules
are,
but
but
certainly
something
something
that
followed:
those
rules
to
the
point
that
there
was
no
longer
a
nasty
surprise.
I
would
find
fine.
D
D
One
thing
that
was
surprising
was
there
is
a
need
to
do
a
what
looks
like
web
compatible
change
to
the
spec
in
2015.
There
was
a
accidental
change
during
a
refactoring
to
the
specification
about
completion
values
and
the
break
keyword,
and
also
to,
if
else,
expressions
and
that
just
needs
to
be
cleared
up
because
right
now
that
is
surprising
and
I
think
everybody
who's
seen.
The
code
is
surprised
by
it.
C
Okay,
well
very
good.
I'm
expecting
that
I
will
end
up
happy
on
that.
One
module
attributes.
We've
talked
about
that
in
a
previous
one
of
these
sessions.
That's
going
to
be
a
pain
and
annoyance,
but
only
I
think
I
think,
only
a
pain
and
an
annoyance.
I
don't
think
there's
a
fundamental
problem
here.
They
just
yet
more
bookkeeping.
That
has
to
be
threaded
through
all
of
the
module,
specifier
handling
logic,
and
it's
not
a
place
where
it's
pleasant
to
thread
a
whole
bunch
of
new
information
through
chris
is
that
about
your
assessment.
A
It's
dubious.
It's
dubious,
in
my
opinion,
whether
it's
useful.
I
think
that
the
I
think
that
the
security
concerns
that
were
cited
that
motivated
the
change
motivated
this
proposal
could
be
addressed.
Other
ways.
C
Yeah
the
the
the
idea
that
it's
the
consumer,
the
consuming
code
that
gets
to
determine
the
type
of
the
data
being
consumed,
seems
exactly
backward
from
the
security
point
of
view.
B
I
gotta
raise
a
small
point
here
that
I
just
noticed
I'm
looking
at
the
module
attributes
proposal
under
the
import
statement
section
they
have
the
line
import
json
from
food.json
with
type
json.
C
Yeah
so,
and
I
think
alex,
would
you
agree
that
that
there
is
a
width
that
appears
in
the
import
expression
in
this
proposal?
But
it's
not
one.
That's
subject
to
the
confusion,
because
that's
just
you
know
normal
expression,
syntax.
A
Yeah
bradley,
what's
your
take
on
module
attributes?
Is
this
something
that
you'd
like
to
see
land
in
its
current
form
or
make
progress,
basically
from
its
current
form,.
D
I
have
no
personal
desire
to
ever
use
this
thing,
but
I
don't
see
it
harming
me
in
any
particularly
strong
fashion.
C
D
That
was
a
very
argumentative
fight,
but
yes,
there
are
two
categories
of
module,
attributes
being
discussed,
one
are
going
to
be
temporarily
called
the
evaluators
and
one
is
the
assertions
they
are
only
interested
in
the
assertions
right
now.
D
D
An
integrity
check
that
does
a
shaw
check
against
the
body,
or
things
like
that:
okay,
they
are
only
proposing
type
and
only
type,
with
a
value
of
json
to
the
spec.
A
Being
purple
okay,
so
the
same
type
json
is
to
say
that
that
the
module
loader,
presumably
the
compartment,
will
need
to
be
able
to
compare
what
the
module
advertises
its
type
to
be
to
the
type
that
they
intend
it
to
be.
C
D
A
So
the
oh,
I
see
that's
fascinating,
yeah,
yeah
yeah,
because
yeah
okay.
So
what
what
this
implies
for
the
compartment
api
if
it
were
to
go
forward,
is
that
for
the
purposes
of
assertions,
the
import
hook
would
need
to
see
what
those
assertions
are
and
it
would
need
to.
A
It
might
not
need
to
do
anything
special.
Actually,
I
my
initial
thought
was
that
the
module
static
record
might
need
to
carry
an
arbitrary
bag
of
things.
But
it
sounds
to
me
like
the
import
hook
would
need
to
to
receive
the
the
bag
of
asserted
things,
and
then
it
would
be
up
to
the
import
hook
to
implement
the
assertion
and
map
the
type,
for
example,
to
the
corresponding
mime
type,
possibly
possibly
translate
that
to
an
accept
header
and
then
possibly
also
verify
that
the
the
response
content
type
matches
the
assertion.
D
A
Okay,
that
is
not
what
I
understood
it
to
be,
and
that
is
that
is
less
problematic
than
what
I
assume
I
I
still
kind
of
think
that
it's
gross,
because
I
think
people
are
going
to
leap
to
the
same
assumption
I
did
and
that
this
will
lead
to
a
proliferation
of
possibly
compliance.
B
D
D
Sure
so,
apparently,
module
records
in
the
javascript
spec
don't
actually
have
a
limit
on
the
exported
names.
D
They
can
be
any
string,
they
can
be
invalid,
javascript,
strings
fun,
but
wasm
modules
in
particular,
and
some
of
the
things
in
wazom
modules
are
exporting
non-identifier
name
bindings,
which
are
visible
in
javascript.
They
are
visible
via
export
star
from
or
if
you
import,
a
wasm
module,
namespace
object.
D
C
D
D
That
foo
must
be
an
identifier
name.
This
is
adding
a
syntax
where
you
basically
can
put
a
string
literal
in
the
place
of
the
identifier
name
being
imported
and
import
under
that.
This
also
uncovered
something.
C
Does
does
it
follow
the
general
rules
elsewhere
in
the
language
for
quoted
versus
unquoted
property
names
like
in
object,
literals.
D
C
Obviously,
the
the
these
these
funny
strings
cannot
also
name
variables,
so
you
can't
import,
you
know
blah
blah
blah
from,
but
you
can
import
blah
blah
blah,
as
variable
name.
Is
that
correct.
E
E
In
in
javascript,
the
export
names
must
match
the
identifier
name,
production
right.
E
C
Okay:
okay,
well
good
next
is
intel
enumeration.
Is
that
just
another
intel
same
story.
C
C
Security,
significant
intel
number
format
from
dot
dot,
dot,
import,
bradley.
D
That's
just
a
secondary
grammar,
so,
instead
of
import
being
the
first
word
from
would
be
the
first
word
and
I
import.
This
has
to
deal
with
a
variety
of
basically
user
experience
issues.
It's
no
new
semantics.
D
D
So
it
actually
stabilizes
the
location
of
tokens.
It
gives
you
better
editor
completion,
it
matches
many
more
languages,
but
there
there
are
preliminary
like
shots
fired
and
that's
probably
never
gonna
go
through.
D
That
is
lost
to
time.
I
have
found
out
in
2009.
That
was
the
ordering
that
was
being
looked
at
and
then
at
some
point
around
2011.
It
started
with
import
as
the
first
keyword
and
it
was
never
looked
at
again.
We
have
some
guesswork
feedback
of
people
participating
at
the
time.
It
was
to
simplify
the
grammar
to
not
use
a
no
line
terminator
here.
C
All
right,
okay,
yeah!
I
can
see
how
that
would
have
been
how
we
got
there.
Okay,
generic
comparison.
D
The
spaceship
operator
and
other
languages
exists.
It
is
essentially.
D
A
Now
that
one
yeah
it's
it's
literally,
the
comparison
is
the
compare
operator
from
perl
which
which,
as
as
a
concept,
exists
in
javascript
already,
since
that's
the
that's
the
it
is
the
type
it
is.
The
operator
that
corresponds
to
the
the
the
type
of
a
compare
function
that
you
would
pass
to
sort.
A
D
It's
always
false
because
yeah
no
for
negative,
zero.
D
Oh
yes,
so
because
nan
compared
to
anything
is
false.
It's
always
going
to
take
a
path
in
which
oh
that's
interesting.
We
should
ask
that.
C
B
B
C
Oh
yeah,
this
next
one
subclassing
support
for
built-in
methods,
delendast
that
one
is
fascinating
and
I
I
am
very
very
much
in
favor
of
it.
Glenda
nest
is
some
yeah.
This
is
some
ancient
phrase,
meaning
must
be
destroyed.
B
Yeah
there
was,
there
was,
I
forget,
which
was
one
of
the
famous
roman
orators,
would
always
end
every
single
speech
with
that.
C
There's
there's
three
levels
of
subclassing
weirdness
that
the
current
spec
commits
the
language
to
all
three
of
which
make
the
language
incredibly
harder
to
implement
correctly,
and
the
history
of
bugs
against
v8
also
show
that
being
hard
to
implement
correctly
often
people
don't
so.
C
C
Yeah
so,
and
the
the
weird
subclassing
semantics,
that's
so
hard
to
implement,
is
also
approximately
useless
and
more
than
that
is,
as
far
as
we
can
tell
approximately
unused.
C
So
this
is
one
of
those
rare
things
where,
even
though
it's
been
shipping
compatibly
on
all
of
the
engines
for
years
now,
conforming
to
the
spec,
we
actually
think
we
can
remove
it
without
breaking
anything
which
would
be
a
stone.
C
Oh
yeah,
oh
yeah,
yeah,
that
was
that
was
one
where
allen
works,
brock
coming
for
you,
elmer's
brock
and
I
both
come
from
a
small
talk
background,
but
he
was
very,
very
much
enamored
of
the
subclassing
mechanics
of
being
able
to
override
portions
of
operations
and
having
operations
delegate
to
self
so
that
those
portions
could
be
overwritten.
C
And
you
know
it's
an
elegant
theory.
I
was
skeptical
at
the
time,
but
I
wasn't
skeptical
enough.
It
turned
out
much
much
worse
than
I
expected.
C
C
And
then
you
do
a
map
over
the
foo
array
that
the
result
of
the
map
will
be
an
array
that
instantiates
whatever
the
name
species
is
and
then
there's
things
like
in
regex,
where
the
the
normal
normally
named
operations
for
portions
of
them,
delegate
to
symbol
named
operations
so
that
subclasses
of
regex
could
override
the
symbol
named
operation
in
order
to
change
the
normally
name,
the
behavior
of
the
normally
named
operation
on
that
subclass.
C
So
you
could
change
it
into
more
modular
internal
fat
manner,
rather
than
changing
the
publicly
named
thing
as
a
whole,
and
that's
about
it
that
I
remember-
and
I
completely
support
that
we
should
you
know,
get
rid
of
this
stuff.
D
So
we
have
around
400
000
sites
or
domains
that
are
using
species
in
some
way
via
feature
tracking
all
sites.
We
have
crawled
with
a
automated
browser
to
get
a
real
javascript
evaluation,
exactly
none
of
them
do
any
usage
of
species
except
for
feature
detection
to
polyfill,
which
is
astounding
yeah.
D
Unfortunately,
while
we
expected
people
to
use
that
species
for
a
specific
way
of
subclassing,
all
of
them
implement
subclassing
in
different
ways
in
particular,
angular
uses
at
species,
but
it
completely
replaces
all
asynchronous
things
within
the
context
it
lives
in,
and
so
it
cannot
use
the
built-in
promises
at
species.
It
must
recreate
it
in
its
own
zone,
aware
promise
class
so.
D
Nobody
is
actually
using
it.
The
people
using
the
style
of
extending
are
doing
it
entirely
on
their
own
and
they
never
call
the
built-ins.
C
Yeah,
so
this
this
not
only
is
great
in
itself
in
that
we
can
be
removing
unneeded,
problematic
crap
from
the
spec
is
it
sets
a
precedent
that
there
might
be
other
completely
unused,
problematic
crap
that
happen
to
be
in
the
language
that
we
might
be
able
to
remove
it.
It
makes
the
possibility
of
that
much
more
realistic.
C
Yeah
and
and
and
then
it
becomes
a
case-by-case
basis,
kind
of
thing.
We've
had
some
cases
before
in
other
transitions,
where
the
thing
that
broke,
we
could
just
call
somebody
up
and
have
them
fix
it,
and
it
was
done
and
then
other
things
that
broke
were
in
libraries
in
old
versions
of
libraries
that
have
already
been
fixed
in
the
present
version,
but
the
old
version
was
distributed
by
copy
and
those
we
just
gave
up
on,
there's
no
way
to
fix
it.
Even
though.
D
We
have
identified
some
of
those.
There
is
a
blog
hosting
platform
that
is
two
percent
of
all
usage,
for
example,
and
so,
if
we
can
get
them
to
update
a
specific
library
which
is
only
using
it
for
feature
detection,
they
never
actually
use
species,
it
would
drop
it
from
the
usage
counter.
C
D
So
the
blog
hosting
platform
is
hosting
the
javascript
file
that
we
want
changed.
It's
a
japanese
blog
hosting
platform.
You
cannot
put
arbitrary
code
in
it.
Okay,.
D
D
Overall,
this
looks
semi-reasonable.
We
have
a
scraper,
a
godaddy
which
I've
been
trying
to
get
through
fiddles
that
we
have
been
trying
to
do
this
feature
detection
with
higher
confidence.
It
is
very
unhappy
doing
more
than
scraping
network
traffic,
but
we
might
have
that
done
after
the
meeting.
I
was
hoping
to
have
it
done
before
the
meeting,
but
for
now
we've
just
got
you
know:
3
000
sites
crawled.
E
A
I
I
want
to
believe
in
this
feature.
A
D
That's
the
interaction
everybody
who
tries
to
abuse
it
accidentally
destroys
its
behavior
in
a
way
that,
for
the
most
part,
this
change
is
actually
a
no-op.
D
D
D
A
Doing
that
yeah,
because
this
reminds
me
of
something
I
tried
to
do
in
c
plus
plus
when
I
was
in
junior
college,
I
was
trying
to
take
the
standard
I
o
from
the
standard
template
library
and
extend
it
such
that
you
could
put
ansi
escape
sequences
in
line
with
with
your
stream,
and
the
problem
I
ran
into
is
that
I
needed
to
override
the
extract
operator
to
accept
additional
flag
types
and
because
it
wasn't
polymorphic
and
because
it
was
it
was
all
you
know,
template
generics.
A
If,
if
I,
if
anywhere
in
the
sequence
of
operations
I
did
on
the
stream
by
extract
extract
extract,
I
ended
using
something
like
endl.
It
would
have
been.
It
would
return
the
the
original
I
o
stream
type,
and
I
wouldn't
from
that
point
on,
be
able
to
do
any
of
the
fancy
things
that
I
had
added
to
my
subclass.
A
So
you
know
wise
people
would
just
give
up,
but
then
I
decided
to
write
my
own
template
library
until
I
found
out.
I
just
couldn't
make
that
work.
D
This
is
this
is
the
the
canonical
example
of
something
that
works
they
removed
it,
though
this
is
a
breaking
change
for
the
map,
filter
and
slice,
or
no
and
subarray
operators
for
this
polyfill,
but
since
those
are
not
actually
things,
people
use
and
we
have
searched
for
it,
because
why
would
you
map
you
into
eight
array.
D
Actually
encountered
a
usage
that
we
found,
we
are
still
trying
to
find.
I'm.
E
The
thing
that
really
gets
me
about
this
is
that
I
value
strongly
the
the
capability,
but
species
never
seemed
like
a
good
way
to
deliver.
It.
C
Yeah
speech
this
history
of
species
is
the
small
tall
collection,
small
talk,
collection
classes
did
have
a
species
convention
and
did
use
it
and
all
together
with
the
menagerie
of
collection
classes
and
how
they
related
to
each
other.
They
actually
did.
I
mean
it
really
was
useful
in
that
context,
but
that
was
also,
I
would
say,
where
brock
might
disagree
with
this,
but
I
would
say
the
small
talk.
C
Collection
classes
was
the
first
time
anybody
really
tried
to
do
a
deeply
object,
oriented
collection
library
and
therefore
it
was
before
we
knew
how
to
do
it.
Well,.
D
So
this
does
leak
into
other
proposals.
I
know
upsert
collection,
normalization
and
a
few
others
have
talked
about
subclass
ability.
This
would
greatly
simplify
getting
a
variety
of
those
proposals
together
because
we
don't
have
to
cater
to
at
species.
C
E
Yeah,
the
the
position
of
the
of
the
specification
with
respect
to
subclass
ability
has
never
been
sufficiently
strong
for
my
taste
anyway,
like
it'll.
It
has
throwaway
lines
about
intended
to
be
subclassed
that
then
the
the
actual
algorithms
and
the
text
don't
seem
to
fall
in
line
with.
D
So
this
partially
solves
that,
because
the
new
story,
the
new
recommendation
from
the
spec,
is
to
override
any
methods
you
want
replaced,
which
matches
a
variety
of
behaviors
already
in
the
spec
that
do
not
delegate
to
ad
species.
C
So
this
was
actually
discussed
last
time
when
these
guys
were
here
from
the
records
and
tuples
proposal.
C
The
records
and
total
proposal
has
a
use
case
that
becomes
much
easier
if
we
simply
allow
symbols
as
weak
map
keys
and
there's
a
controversy
that
I
started
about,
whether
it's
symbols
as
a
whole
or
just
unregistered
symbols-
and
I
don't
know
where
that's
going
to
land
but
unregistered
symbol
having
at
least
unregistered
symbols,
not
keys,
is
something
that
I
had
resisted
previously,
because.
C
C
The
compelling
use
case
is
that
the
symbol
can
be
used
as
a
a
unforgeable
token
to
be
looked
up
in
the
weak
map
to
designate
other
mutable
things
if
you
have
access
to
that
weak
map.
So
there's
a
bunch
of
patterns
that
follow
from
that,
where
you're
effectively
storing
mutable
data
within
a
within
sort
of
within
a
pure
value
structure
by
actually
storing
these
symbols
that
point
through
the
weak
map
to
the
non-pure
values
and
from
a
capability
perspective.
C
D
So,
yes,
I
want
to
make
a
quick
case
that
allowing
these
global
symbols
that
are
available
with
forge
ability
are
not
problematic,
if
that's
okay,
sure.
So
we
have
two
points
of
contention
that
I
see
on
these.
There
may
be
more,
please
add
them.
As
I
talk
about
this,
one
is
memory
leakage.
D
The
ability
to
forge
a
symbol
means
that
anything
we
store
in
a
side
table
must
be
kept
alive
essentially
indefinitely
until
the
context
in
which
the
forge
ability
is
garbage
collected
somehow
for
some
of
those
such
as
symbol.iterator
that
are
shared,
that's
not
possible
at
all.
So
we
have
kind
of
three
categories
of
symbols.
We
have
the.
D
Correct,
yes,
sorry!
So
we
between
this,
we
can
already
create
this
kind
of
memory,
leak,
boundary
or
inability
to
ever
remove
something
from
the
side
table
by
using
the
side
table
as
a
key
to
itself.
D
So
that's
kind
of
awkward
or
using
any
of
the
undeniables
as
keys
and
then
producing
a
side
table
within
that.
C
No,
the
the
the
the
side
table
itself
is
a
valid
point,
and
I
hadn't
heard
that
one
before
the
undeniables
is
not
a
valid
point
because
realms
can
be
garbage
collected.
D
Fair
enough,
but
we
do
do
the
side
table
trick
actually
within
the
polyfill
for
the
old
composite
key
proposal,
so
I
mean
it
is
out
there
also.
I
don't
think
the
memory
leakage
is
really
the
concern
here.
I
think
that's
kind
of
an
anti-pattern
and
we
don't
need
to
defend
against
that
specific
anti-pattern.
D
Well,
no
hold
on.
You
could
have
a
record
which
uses
a
side
table
for
the
non-registered
symbols
and
then
has
a
strong
mapping,
not
a
side
table
for
other
things
that
needs
to
be
passed
contextually
around.
That
is
a
pattern
around
it.
It
can
allow
you
to
use
registered
symbols
within
records
and
tuples.
Without
this
concern,
it
is
more
difficult
to
do
in
general.
I
think
using
registered
symbols
within
these
is
just
an
anti-pattern
that
nobody
nobody's
really
seeking
to
encourage.
D
People
will
see
that
it
leaks.
They
will
stop
doing
it
if
they
don't
no
extra
object.
Capabilities
are
granted
by
doing
so.
To
my
knowledge.
C
Allowing
allowing
registered
symbols
to
be
weak,
math
keys
and
just
to
go
extreme
here,
allowing
numbers
and
strings
to
be
weak
map
keys.
You
know,
creates
a
permanent
leak.
It
doesn't
violate
any
object
capability
principles.
D
So
I
would
argue
that
the
expectation
is
based
upon
the
lifetime
of
whatever
the
key
in
the
map
is
not
based
upon
any
sort
of
guarantee
that,
during
a
garbage
collection,
it
could
be
collected.
So
when
you
put
something
into
a
weak
map,
it
is
drastically
different
from
arbitrarily
adding
a
private
field.
You
are
correct.
Private
fields
are
unable
to
be
removed
from
references
ever
even
if
the
private
field,
identifier
completely,
is
destroyed
currently
in
the
specification.
D
So
if
there
is
no
way
to
reference
a
private
field
anymore,
it
will
stay
alive
still
and
that
I
think,
is
a
similar
concern
where
you
have
a
way
to
introduce
a
permanent
leak.
D
It's
not
exactly
great
that
you
can
create
a
permanent
leak,
but
I
don't
think
it's
something
we
need
to
prevent
people
from
doing.
I
think
limiting
it
to
symbols
is
nicer
than
saying
arbitrary
strings
or
numbers.
Symbols
in
general
are
not
things
that
you
produce
via
an
operator
like
plus
or
concatenation.
D
They
don't
you
don't
coerce
to
symbols
generally,
so
they
are
much
less
a
threat
of
accidental
leakage.
They
are
a
threat
of
misusage,
causing
leakage,
though.
C
This
point
you
make
about
private
fields
the
real,
the
real
problem
there
was
when
we
added
return
override
to
the
class
mechanism.
This
thing
about
removing
crap
that
nobody
needs
but
gets
everyone
in
trouble.
I
don't
think
we
could
remove
return
override,
but
maybe
we
could
restrict
it
in
important
ways.
E
E
No,
no,
so
what
I'm
saying
is
like
when
the
when
the
source
of
the
private
field
goes
out
of
scope,
the
private
field
on
the
non-instance
is
itself
no
longer
observable.
C
E
C
D
Do
you
mean
by
finalizers,
so
if
I
put
some
object,
so
it's
now
strongly
held
in
a
private
field
and
it
has
a
weak
ref
collection
finalizer
on
it.
C
So
the
whole,
the
the
the
weak,
the
the
weak
ref
semantics-
was
a
really
interesting,
subtle
piece
of
design
to
figure
out
how
to
have
the
specification
be
weak
enough
that
it
did
not
overly
constrain
implementers
allowed
implementers
to
do
things
like
dead
code
and
dead,
variable
elimination,
structure,
sharing
for
closures
because
of
shared
lexical
context,
there's
a
whole
bunch
of
things
that
cause
the
actual
reachability
to
differ
from
any
semantic
account
of
reachability
in
a
large
number
of
ways,
in
both
directions,
both
more
and
less
reachability,
and
this
would
be.
C
This
would
be
an
example
of
that.
So
we
ended
up
with
a
the
kind
of
subtle
spec
that
people
use
when
they
try
to
specify
memory
models,
and
I
think
that's
actually
the
right
analogy,
and
it
has
to
do
with
comparing
sort
of
all
the
hypothetical
executions
under
cases
where
something
was
or
was
not
retained
or
something
it
got.
It
got
it's
well
thought
out,
but
it's
not
something
I
can
retain
in
my
head
and
certainly
reason
from
unless
it's
fresh.
C
But
that's
that's
where
I
would
look
to
see
if
the
private
fields
could
be
garbage
collected,
even
if
weak
references
make
them
make
the
garbage
collection
observable.
D
D
B
Okay,
gentlemen,
we
are
now
well
past
3
p.m.
A
I
was
about
to
point
out,
thank
you
alex.
I
propose
that
we
stop.