►
From YouTube: Annex B Reform, as presented to TC39 June 2019
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
Okay,
we've
got
this
section
in
the
spec
that
has
sort
of
been
functioning
as
a
dumping
ground
for
things
that
we
needed
to
codify,
that
we
don't
want
to
be
in
the
main
spec
and
there
isn't
really
one
rationale
that
has
governed
why
things
ended
up
there.
It's
kind
of
been
a
grab
bag
of
different
rationales.
A
What
it
actually
says
in
the
intro
to
nxb
is
that
everything
in
nxb
is
actually
required
when
the
host
is
a
web
browser,
except
for
with
the
exception
of
xs.
All
of
the
other
javascript
engines
are
be,
are
primarily
engineered
to
target
the
web
browser.
So
a
lot
of
nxb
remains
implemented
on
node,
even
though
node
is
not
a
web
browser,
it's
simply
because
it
uses
the
java,
the
v8
engine,
which
has
been
engineered
primarily
for
the
browser
outside
the
browser.
Everything
here
is
normative,
but
optional,
which
has
had
two
historic
interpretations.
A
What
I
always
took
normative
but
optional,
to
mean,
including,
I
believe,
in
the
negotiations
that
arrived
at
the
phrasing.
What
I
meant
by
it
during
those
negotiations
is
that
each
element
individually
is
normative
but
optional,
meaning
that
you
don't
need
to
implement
it
in
order
to
be
correct,
but
if
you
do
implement
it,
you
must
implement
it.
A
This
way,
alan
wurstbrock,
I
think
at
one
point
I'm
not
sure
if
still
took
the
normative
but
optional
to
mean
that
it
applies
to
nxb
as
a
whole,
that
you
either
don't
implement
everything
in
annex
b
or
if
you
implement
anything,
then
you
implement
everything
in
annex
b,
as
stated,
I
certainly
don't
subscribe
to
that
and
would
never
have.
A
I
think
this
is
one
of
those
one
of
these
cases
where
we
arrived
at
consensus
on
words,
because
we
didn't,
because
we
didn't
realize
that
we
had
not
arrived
at
consensus
on
meaning
everything.
When
I
talk
about
it
being
a
garbage
dump
in
the
absence
of
legacy
usage,
everything
in
nxp
would
be
removed
from
the
specification.
I
think
that's
that
is
accurate.
A
Web,
it's
acknowledging
the
reality
that
everything
here
the
reason
we
code
we
codify
them
in
nxp
is
because
web
browsers
must
support
them.
That's
accurate
and
notice
in
the
last
paragraph,
there's
a
not
normative
in
the
spec
sense
of
normative,
but
normative
in
the
natural
language
sense
of
normative
a
a
a
recommendation,
a
a.
A
It's
programmers
should
not
assume
the
existence
of
these
features
and
behaviors
when
writing
new
ecmascript
code.
Ecmascript
implementations
are
discouraged
from
implementing
these
features
unless
the
implementation
is
part
of
a
web
browser
or
required
to
run
the
same
legacy
ecmascript
code
that
web
browsers
encounter.
A
So
I
I
think
that
that
is
a
very
nice
set
of
distinctions
to
have
in
that
last
paragraph
that
we
actually
discourage
these
features
from
being
used
or
implemented
when
they're
realistically
something
we
can
consider
not
to
be
part
of
the
language,
but
now,
let's
go
through
the
actual
contents
of
nxb
and
make
some
distinctions.
A
A
I'm
dividing
it
up
into
two
portions
annex
be
safe
and
annex
be
unsafe,
unsafe
are
well
safe,
would
be
something
like
a
string.prototype.bold,
a
just
a
little
utility.
That's
up
on
string.prototype
to
make
html
text
out
of
data
an
example
of
something
unsafe
is
regexp.dollar1,
which
is
a
global
communications
channel.
It's
a
non-local
form
of
communication.
A
It's
it
simply
reflects
data
from
whatever
the
most
recent
match
is
of
a
regex
instance
in
that
realm,
against
some
strength.
A
So
this
is
an
inventory
of
the
elements
of
nxb.
Let's
start
with
the
upper
left
corner,
the
things
which
are
which
apply
both
to
strict
and
non-strict
anti-sloppy
code.
I
either
not
specific
to
sloppy
code
escape
and
unescape,
I
believe,
are
universally
implemented.
See
anybody
please
correct
me
if
I'm
wrong
and
the
xs
guys,
both
of
which
are
here,
I
see
a
nodding
head
for
all
of
these
I'm.
I
have
no
question
that
the
browsers
implement
all
of
them
and
in
fact,
annex
b
requires
them.
A
So
xs
is
actually
the
only
free
variable
here,
underbar
underbar
proto,
under
bar
underbar
or
dunder
proto.
As
we
like
to
call
it.
I
was
surprised
to
find
both
the
accessor
property
and
the
special
string
literal
syntax,
both
in
annex
b,
I
think,
having
variable
syntax,
where
systems
that
implement
nxb
parse
according
to
one
syntax
and
systems
that
don't
parse
according
to
another
syntax.
A
I
think
that
that
is
a
tolerable
situation
when,
when
the
difference
is
only
is
guaranteed
to
either
mean
the
same
thing
on
both
or
reliably
cause
a
failure
on
one
to
have.
It
succeed
at
parsing
on
both
but
mean
different
things
I
think,
is
a
disaster,
because
then
the
same
snippet
of
code
moved
from
one
to
the
other
will
silently
assume
a
different
meaning.
A
So
the
thunder
proto
object.
Literal
syntax
is
a
nice
simple
example
of
that
in
a
system
where
that
syntax
is
not
recognized,
it
would
actually
create.
It
would
actually
use
define
property
semantics
to
create
a
property
with
that
name
that
has
no
special
status
and
does
not
override
the
prototype,
and
that's
I'm
hoping
nobody
actually
does
that
thunder
proto.
A
We
moved
it
into.
We
put
it
into
annex
b
at
the
time
that
we
made
that
we
accepted
mutable
prototype
chains
into
the
dura
language,
and
the
hope
might
have
been
that
some
environments
might
not
provide
for
mutability
of
prototype
chain
by
omitting
dunder
proto,
but
we
did
not
make
reflect
dot
set
prototype
of
optional
so
without
making
set
reflect.set
prototype
of
optional
there's
no
fundamental,
ugly
semantics
that
a
system
gets
to
avoid
having
by
omitting
dunder
proto.
A
So
I
think
dunder
proto
is
effectively
universal.
Likewise,
with
define
getter
defined,
setter,
lookup
getter
lookup
setter.
All
of
those
things,
I
believe,
are
universal
and
they're
easily.
A
The
semantics
is
easily
defined
as
a
slight
convenience
over
defined
property
they're.
Actually,
some
buggy
implementations
of
the
define
getter
center
lookup
getter
center
things
on
some
browsers,
but
this
is
an
example
of
why
codifying
it
is
is
codifying
it
in
a
more
mandatory
fashion,
would
make
it
less
likely
for
these
bugs
to
have
gone
unnoticed
for
so
long
unnoticed
and
unfixed.
For
so
long,
the.
A
String
dot
prototype
additional
methods,
there
are
substring,
which
is
essentially
a
a
another.
A
There's
trim
left
and
trim
right
and
then
there's
a
whole
bunch
of
html
things,
including
if
I
recall
blink,
somebody
wants
to
keep
blinking
annex
b
while
promoting
the
rest
of
it.
I
wouldn't
mind.
A
A
Regex
prototype
compile
is
an
odd
beast.
Last.
A
It
seemed
like
it
actually
violated
the
semantics
of
object.freeze
in
terms
of
what
it
would
do
to
a
regex
if
you
did
it
after
the
request
was
frozen,
but
I
have
not
looked
at
that
for
a
long
time,
but
any
cases
it's
completely,
I'm
perfectly
happy
to
let
that
stay
in
annex
b,
the
unsafe
things
are
the
regex
statics.
As
I
mentioned,
and
then
in
the
upcoming
error
stack
proposal,
the
stack
accessor
property
on
error.prototype
should
be
codified.
It's
not
currently
codified.
It
should
be
codified.
A
It's
proposed
to
be
codified
as
part
of
that
proposal,
but
the
way
of
acts
and
there
and
that
proposal
proposes
two
different
ways
to
access
the
stacks.
A
The
one
that's
from
the
inside
is
not
able
to
be
made
safe
and
by
putting
in
nxb
you
and
you
enable
it
to
be
omitted,
you
also,
we
also
mandate
that
it
be
deletable.
This
is
another
important
idea,
which
is
everything
that
we're
putting
in
nxb
so
that
it
can
be
omitted.
We
should
also
mandate
that
if
it
is
present,
it
be
deletable
so
that
a
startup
script
in
a
given
environment,
where
they're
present
can
delete
them
and
then
have
the
resulting
state,
be
a
state
that
itself
conforms
to
a
pristine,
ecmascript
spec.
A
Document
all
is,
is
a
horror
that
exists
for
one
particular
purpose,
and
nxb
text
makes
it
very
clear:
it
should
never
be
reproduced
ever
anywhere
and
by
the
way
for
people
who
don't
know
what
some
of
these
oddball
cases
are
in
a
way.
A
That's
kind
of
the
point
of
of
the
things
that
remain
in
annex
b
is
these
are
oddball
cases
that
we
really
want
to
to
be
as
ignorable
as
possible,
but
we
still
want
to
codify
them,
so
we
all
agree
on
them
when
they're
present
and
then
the
four
var
x
equals
y
n.
I
a
four
initialize
four,
where
the
declaration
for
in
where
the
declaration
includes
an
initializer
is
completely
meaningless
and
useless,
but
it
is,
I
think,
it's
accepted
as
part
of
the
normal
syntax.
A
Happier
and
also
the
the
I
did
not,
I
read
the
text
and
I
could
not
understand
what
the
text
was
saying
about.
Var
declarations
inside
catch
blocks.
A
B
A
B
A
Is
that
is
that
one
sloppy
outlet?
I
don't
think
that
one
okay,
so
okay,
so
the
so
the
var
thing,
I'm
very
happy
that
that's
sloppy
only.
I
would
then
move
that
into
the
lower
mandate
section,
which
is
the
things
that
are
that
are
already
sloppy
only
and
since
its
syntax,
my
bias
on
syntax
is
to
mandate
syntax
because
synth,
because,
however
horrible
the
syntax
is
having
the
syntax.
A
A
Annex
b
also
has
mandated
several
pieces
of
syntax
that
are
already
specific
to
sloppy
mode,
and
the
question
is,
to
my
mind,
quarantining
them
in
sloppy
mode
is
adequate.
They
don't
need
to
be
doubly
quarantined
by
being
both
in
sloppy
and
in
annex
b
that
any
code,
that's
that's,
that's
avoiding
sloppy
mode
in
any
environment
that
enforces
their
avoidance
of
sloppy
mode
is
already
not
subject
to
those
things.
A
There's
these
things
that
we've
never
codified,
that
are
part
of
de
facto
standard
javascript,
which
is
sloppy
collar
quality
and
arguments
for
a
while.
We
had
codified
the
strict
poisoning
of
them
to
in
order
to
flush
them
out
of
the
ecosystem.
They
got
flushed
out
of
the
ecosystem,
to
the
point
that
we've
been
relaxing
the
poisoning,
but
the
as
far
as
I
know,
everybody
who
implements
sloppy
mode
continues
to
implement
those.
A
A
A
So
html
like
comments:
they
are
not
specific
to
sloppy
they.
Why,
at
a
different
distinction,
which
is
the
distinction
between
program
code
and
modular
module
code,
does
not
recognize
them
and.
B
A
That
by
this.
A
Bang
hyphen
hyphen
that
can
be
part
of
valid
javascript
text.
You
know
operand
less
than
the
not
of
the
predecrement
of
something,
likewise
the
post-decrement
of
something
being
greater
than
something.
So
the
fact
that
this
parses,
as
html
like
comments
somewhere
and
is
not
recognized
by
parsers
elsewhere,
means
that
you
can
write
code.
That
purposely
means
two
different
things
depending
on
what
the
rules
are
of
your
person
and
it's
not
just
your
platform
parser.
It's
also
all
of
your
tool,
parsers
that
do
pre-processing
and
transpiling
the.
At
one
point.
A
A
It's
you
know
it's
crazy
making
or
I
suppose
it's
actually
not
a
combinatorial
explosion,
because
it
either
recognizes
them
everywhere
or
nowhere.
Although
that's
not
necessarily.
A
With
that
xp,
so
my
recommendation
is
that
html,
like
comments
be
promoted
to
the
main
spec,
because
even
though
they
are
horrible
and
I
would
love
to
kill
them,
there's
like
there's
a
few
things
in
javascript.
I
hate
more
than
the
complexity
that
comes
from
recognizing
these
things.