►
From YouTube: 2022-01-28-Node.js Node-API Team meeting
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
So
welcome
to
the
node.js
node
api
team
meeting
for
january
28th,
just
because
not
not
everybody
shows
on
the
screen.
I'll
just
mention
that
today
we
have
with
us
myself,
nicola
chenzong,
gabriel,
kevin
and
vladimir.
B
A
A
This
one
this
one,
I
think,
vladimir,
you
did
add
some
more
comments
on
one
of
the
related
discussions
or
pr's
right
yeah
on
this
one.
A
A
C
No
it's
because
adding
cons
is
just
it's
restrictions,
additional
restrictions,
so
thankfully
it
doesn't
loosen
anything.
D
I
I
I
just
checked
the
pr
and
it
doesn't
change
any
of
the
tests,
so
presumably
the
tests
and
their
usage
of
the
api
continues
to
compile
with
this
change
and
that's
actually
a
good
exercise.
You
must
not
change
the
tests
and
it
they
should
still
work,
because
if
the
tests
work
chances
are
focus,
code
will
also
work
still
unmodified.
A
Right
since
it
can
enforce
the
const,
I
I'm
just
sort
of
wondering
aloud
like
since
it
can
actually
enforce
the
like.
It
gives
us
an
error
if
it's
not
const
and
we
do
something-
that's
not
const,
I
guess
what
we're
saying
when
we
market
cons.
Okay,
so
here
here's
the
down,
started,
marking
cons
this
like
what
we're
saying
when
we
mark
cost
is,
we
will
never
make
it
non-const,
because
that
would
like
to
go
from
cost
to
non-cost
is
a
breaking
change.
A
D
A
D
Yes,
I
don't
know,
will
we,
though,.
A
Like
so
well,
if
you
had
a
lambda
that
was
using
it
that
couldn't
use
it
without
the
cons,
and
we
remove
it
later
that
code's
broken
like.
D
But
I
mean
non-const
is
more
permissive
than
const
right,
so
the
the
analog
I'm
thinking
about
is
we
had
this
in
in
in
core
and
threat
say
function
at
some
point
where,
where
we
made
like
a
change
like
this
and
and
it
didn't
break
the
code,
I
just.
A
D
Okay,
that's
the
okay,
I
think
that's
the
key
here
does
does
adding
const
to
the
function?
Change
like
the
the
the
mangled
name
of
the
function
right,
and
actually
that
doesn't
even
matter
right,
because
the
the
user's
code
is
never
dynamically
linked
against
these
functions.
It's
always
statically
linked
right
when
they
recompile
their
code,
it
will
no
longer
compile.
A
Right
and
so
so,
if
we
add
the
const,
it
will
let
it
be
called
in
more
places,
which
is
the
benefit,
but
if
we
later
want
to
remove
the
const,
we
can't
do
that
because
that
will
now
actually
break
people's
code.
We
would
have
to
like
come
up
with
a
new
version
of
the
method.
That's
non-const
or
something
like
that.
D
Yeah,
okay,
all
right
yeah!
I
don't
quite
follow,
but
I
can't
accept
that
and
well
I
mean
that
what
is
to
prevent
us
later
from
doing
that,
like
that,
that's
okay!
I.
E
Think
there
it
is
worthwhile
to
think
about
the
opposite
way
of
having
cons
and
then
removing
it
or
rather
like
putting
it
there
and
expecting
things
to
work.
Just
for
example,
we
do
have
that
open
issue
of
the
async
progress
worker
having
const
signal
and
that's
causing
some
compilation
errors
on
that.
So
we
have
to
go
through
the
process
of
removing
it
and
I
think
there's
an
open
pr
for
that.
E
A
Yeah,
I
think
that's
the
I
was
I
was
like
wondering
in
my
head.
Why
don't
we
just
say
yeah
everything's
const,
but
that's
the
one
consideration
is
that,
like
once
we
make
it
a
const.
We
can't
go
back
so
for
a
method.
We
want
to
be
confident
that
you
know.
If
we
make
a
const,
we
don't
think
we
ever
need
to
actually
modify
internal
state
right
like
if
we
look
at
these
concrete
examples
like
object.
Reference
get.
A
D
Actually,
both
ref
and
unref
actually.
D
Because
right
now,
the
only
reason
these
can
be
const
is
because
the
actual
referencing
of
things
doesn't
happen
in
the
wrapper.
It
happens
in
core
right
right
right,
so
we
have
the
pointer
and
we've
established
that
passing
a
pointer
from
a
const
function
to
a
non-const
works,
because
it's
we're
not
modifying
the
object,
we're
modifying
the
object
behind
the
pointer,
and
so
that's
fine,
but
I
mean
if
we
ever
change
the
implementation
to
handle
the
ref
counting
ourselves
and
that's
a
big.
D
If,
because
the
idea
is
that
core
handles
this,
because
it
has
to
be
done
on
the
v8
side,
then
we
would
have
a
problem
because
we
wouldn't
be
able
to
refinance
if
we
stored
the
referendum
inside
the
class.
D
So
exactly
yeah
yeah
there's
a
chance
of
that,
but
I
mean
you
know.
I
think
it
also
matters
what
we're
trying
to
express
with
these
semantics
right
and
that's.
You
know
the
semantics
reinforce
the
fact
that
we
are
a
rapper,
not
a
provider
of
value,
right,
right
and-
and
I
think
in
that
sense,
if,
if,
if
we
were
to
design
these
apis
today,
knowing
that
these
should
be
cons,
would
we
mark
them
as
cons?
A
D
We
should
ideally,
we
wouldn't
have
in
any
internal
state
right
right
and-
and
I
don't
think
we
do
right,
because,
ideally,
the
internal
state,
quote-unquote
melts
away
and
and
just
resolves
into
a
bunch
of
like
node
api
calls
right
and
so
right.
Our
internal
state
isn't
any
real
state
in
the
sense
of
of
there
being
data
in
the
final
executable
that
refers
to
our
state.
It
should
all
optimize
out.
D
And
and
it
it
forces
us
to
it,
forces
us
to
think
twice
before
we
add
our
own
state,
because
we
do
add
our
own
state
for
for
for
things
like
callbacks,
you
can't
avoid
it
to
translate
one
signature
into
another.
You
have
to
add
state
right
right,
but
this
this
sort
of
this
sort
of
intentionally
and
well
intentioned
nearly
binds
our
hands
right
to
not
add
our
own
state.
It's
all
avoidable.
A
A
E
E
And
I
think
it
is
also
worthwhile
to
point
out
that
gabe
said
that
he
looked
at
the
pr
and
all
of
the
tests
passed
right.
E
D
Add
yeah
yeah.
I
I
think
I
think
what
we're
trying
to
figure
out
here
is
the
all
the
methods
here
that
this
pr
proposes
to
add
constitute
are
there
among
them
any
that,
for
which
we
at
some
point
in
the
future
would
want
to
remove
the
const,
thereby
breaking
them
right
and
so
far
like
we're
still
going
down
the
list,
but
so
far
it
looks
like
all
of
them
are
just
straight
pass-throughs
to
core
and
therefore
they
can
safely
stay
calm.
A
Yeah,
that's
exactly
it.
We,
you
know
sort
of
as
a
test
case.
Let's
see,
are
there
any
of
these
that
we
look
at
and
say
maybe
sometime
in
the
future,
we
would
want
to
have
some
internal
state
and
that'll.
Give
us
two
things.
If
we
get
through
the
whole
list
and
say
no,
we
can
prove
this,
and
also
it
tells
us
how
likely
it
is
that
there'll
be
methods
that
we
think
we'd
want
to
actually
have
some
internal
state
make
sense.
D
Yeah,
I
was
a
bit
concerned
about
that
finalizer
because,
like
we
may
want
to
handle
our
own
finalization,
but
then
I
realized
that
there's
no
way
we
can
do
that.
Well,
actually,
there
is
a
way
we
can
do
that,
but
that
would
be
a
different
object
right,
because
right
now
add
finalizer
is
is
another
callback
right.
So
we
do
have
our
own
state
for
that,
because
the
the
pointer
that
the
user
passes
to
us
with
the
data
is
not
the
same
pointer
that
we
passed
a
core.
D
A
Yes,
you're
right,
so,
even
even
when
we
have
state,
like
this
add
finalizer,
we
are
changing
some
state,
but
we
change
it
in
the
c
api
exactly
because
we
want
all
of
the
c
plus
code
to
just
disappear
so,
and
I
think
that'll
typically
be
the
case
like
if
there
is
something
that
requires
state,
we
probably
want
to
add
it
to
the
c
api
so
that
the
wrappers
remain.
Just
you
know,
sugar.
D
Yeah,
the
the
state
that
we
create
in
this
method
in
ad
finalizer
is
not
state
that
is
stored
in
an
instance
variable
of
the
object
instance,
it
is
stored
in
core
right,
and
so
we
are
an
operating
state,
and
nor
are
we
ever
likely
to
be
writing
state
because
of
an
api
object.
Let's
remember
is
not
a
persistent
right,
it's
it's!
It's
a
local
reference
and
so
storing
state
on
it
is
completely
useless
because
it
dies
as
soon
as
it
goes
out
of
scope.
D
So
the
only
one,
the
only
one
of
where
we
should
be
careful
is
where
we
have
like
a
reference
like
we.
We
have
this
template
class
called
reference
right
and
then
and
then
that
class
is
a
candidate
for
having
state
right,
and
I
don't
know
if
any
of
these
functions
touch
that
so
it'll
be
interesting
to
see
as
we
go.
Yeah.
A
A
So
here
we
have
get
ref,
ref
and
unref,
or
even
like
back
into
that
same
state
of
like,
but
we're
maintaining
that
state
back
in
the
in
core
yeah
and-
and
it
really
has
to
be
because
you
could
go
back
and
look
at
that
same
value
in
the
through
the
c
api
right.
So
yep,
that's
right,
spread,
says
function.
D
D
You
know,
I
think,
there's
actually
a
work
around.
I
just
realized
that
there
may
be
a
workaround
later
on,
even
if
we
wanted
to
remove
cons
on
any
of
these,
which
is
to
just
store
the
state
that
we
need
to
modify
as
a
pointer
inside
the
object.
Just
as
the
n
api
value
is
a
pointer
inside
this
object,
which
we
can
then
modify
right.
So
so,
let's
say
later
on,
we
want
to
have
state
that
is
modifiable
inside,
let's
say
an
api
value
right.
So
what
do
we
do?
D
We
say
we
say
we
we
make
a
member
variable
of
an
api
value
that
is
an
api,
this
new
class
star,
variable
right
and
then
inside
one
of
our
cons
methods.
We
say
you
know
this
new,
this
new
class
arrow
method,
which
sets
the
state
inside
this
new
class
and
we're
all
we're
good
yeah,
just
as
yeah,
just
just
as
we
call
into
the
core
methods
now
which
modify
what
is
behind
the
an
api
value
pointer.
D
A
D
Could
actually
be
cheeky
about
this?
I
I
I'm
just
I'm
just
thinking
like
if
we
added.
Let's
say
we
added
this-
the
instances
of
this
new
class
as
member
variables,
not
as
pointers
as
member
variables
on
let's
say,
an
api
value
right
and
then
and
then
we
also
added
a
pointer
which
is
basically
ampersand
the
member
variable.
I
wonder
if
we
could
break
that
right,
because
the
compiler
might
not
be
able
to
follow
that
that
you
know
we're
referencing,
a
pointer
into
our
own
state,
which
we
should
not
be
doing.
A
I
think
what
we've
proven
is
that
yeah,
like
the
downside
to
that,
would
be
more
object,
allocation
and
stuff
right,
but
but
the
example
has
proven
that
that's
perfectly
legal
as
per
the
con
semantics,
yeah
yeah
yeah
right
so
yeah
you're
right,
we
could
work
around.
It
might
cause
some
performance
issues
or
whatever,
but
like
looking
at
these
still
like
get
set,
get
instant
status
instance
data.
There
was
a
little
bit
of
discussion
here.
B
A
D
A
C
My
only
thought
like
that,
this
change
is
relatively
old.
We
need
to
ask
offer
to
replace
it
on
the
latest
code
and
see
if
our
additional
methods
needs
to
be
also
modified.
A
C
But
at
least
I
know
that
author
is,
he
cares
about
this
change,
because
that's
right
a
few
weeks
ago,
then
we
start
discussing
this
topic.
So
hopefully
I
I
bet
he
can.
He
can
go
back
and
do
whatever
is
required
as
long
as
we're.
Okay
with
his
change,
he
probably
will
be
able
to
contribute
to
finish
it
up
correctly.
A
F
Will
be
a
major
changes
or
minor
a
minor.
F
A
A
C
I'm
sorry
like
I
have
a
can.
I
say
like
a
few
words
about
this
change,
that
I
sorry
I
missed
this
meeting
that
you
guys
discussed
with
stuff.
I
just
want
to
say,
like
the
stood
vector
always
requires
to
to
have
a
copy
like
it
does
not
behave
as
a
span.
C
I
just
I
think
there
was
some
misconception
during
the
last
meeting
because
then
it
was
discussed
so
even
vector
receives
like
a
pointers
stuff,
but
it
does
not
behave
like
a
sponge
is
pointing
to
your
storage,
but
instead
it's
always
copies
from
this
source
and
suit
vector
internally
always
does
heap
location
so
think
it's
not
as
efficient
as
might
be.
C
Does
not
behave
like
that
go
ahead,
it
does
not
behave
like
a
like
a
spam.
Spam
is
never
does
any
location,
stuff
you're
effectively,
given
this
pointer
and
size
and
effect
it
just
keeps
on
them
internally.
So
it's
just
a
view
to
the
data,
whereas
worker
always
has
its
own
own
storage,
always.
D
A
That
kind
of
makes
sense
because
the
vector
you
could
then
push
new
things
into
and
so
forth
right
yeah,
that's
right!
I
mean
I
think
that
would
be
an
argument,
not
necessarily
in
this
pr,
but
like
that
might
be
an
argument
to
say
we
should
act.
We
could
add
span
versions
of
all
the
ones
that
take
vectors
right,
yeah,
but.
D
C
My
proposal
would
be
like
if
we
introduce
spam
and
to
have
like,
if
def,
if
people
using
c
plus
plus
20
that
span
here
would
be
really
just
alias
for
stood
span
and
but
otherwise
we
provide
just
minimum
functionality
out
of
the
specs.
So
think
it
will
be
literally
for
developers,
it's
they're
using
your
new
compiler,
and
they
see
that
no,
no,
nothing
changes
their
code,
it'll
be
just
magic.
D
Yeah,
that's
that's
a
good
idea
using
an
if
def,
yeah
and
and
we
we
could,
we
could
use
like.
We
could
use
like
like
a
using
thing
to
say
like
using
you
know,
an
api
span
equals
std
span
if
available,
otherwise,
not
right
right
and
that
we
could
we
could.
We
could
reproduce
only
as
much
of
the
span
api
as
we
need
for
our
own
purposes.
C
And
thankfully,
modern
c
plus
plus
offers
a
bunch
of
special
kind
of
definitions
to
test
different
features
like
I
think
it
should
be
specific
definition
say
like
if
library
defines
student
span.
Certainly
it's
we
don't
even
need
to
invent
this
definition
to
check.
C
So
we
say
we
don't
need
to
check
if
it's
e,
plus
plus
20,
you
know
like,
because
somebody
can
plummet
c,
plus,
plus
20,
but
don't
have
to
spend.
So
we
can
write
with
specific
checks
like
if
library
what
you
use
today
implements
to
spend-
and
you
know.
C
Yeah,
yes,
if
yes,
what
I'm
saying
like
what
to
test
under
if
def
and
if
therefore
there's
a
special
special
variable,
we
can
test
for
if
it's
defined,
then
library
says
I
do
have
stood
span.
So
we
can
just.
A
D
Well,
hold
on
a
minute
is,
is,
is,
is
span
if
available
is,
is
that,
like
a
number
include
span.
C
D
Directed
okay,
so
then
hash.
If
def
preprocessor
directive,
then
hash
includes
span
otherwise
class
or
template
blah
blah
blah
class
span,
blah
blah
blah
and
if
hash
end,
if.
C
A
A
D
C
D
Like
I,
I
just
have
a
thought
there.
Our
methods
should
we,
we
can
add
an
override
and
correct
me
if
I'm
wrong
for
those
methods
that
accept
a
const
vector
reference
right,
because
a
conspector
reference,
you
cannot
change
or
can
you
I'm
not
100
sure
I'd
like
if,
if
one
of
our
apis
takes
a
const
vector
reference,
can
you
add,
could
you
possibly
add
elements
to
that
by
the
same
mechanism
as
you
could
to
like
a
const.
C
No
like
inside
of
inside
for
this
method,
this
vector
can't
be
changed
because.
D
D
Okay,
okay,
good
good,
so
so,
then,
for
all
those
methods
where
we
accept
the
const
reference
to
a
vector,
then
we
could
add
an
override
with
a
with
a
span,
because
the
vector
is
in
effect
a
span
at
that
point,
because
you
cannot
change
it.
It
just
happens
that
the
memory
inside
the
vector
is
allocated
by
the
vector
instead
of
by
the
user.
C
It's
the
only
thing
like
we
need
to
kind
of
look
at
say
if
we
provide
in
something
like
insulation
list
and
we
need
to
look
at,
we
don't
have
any
conflicts
who
would
actually
take
it
span
or
vector,
but
I
guess
we
have
override
specifically
for
installation
lists
so
think
we
should
not
be
missing.
D
A
Yeah,
I
think
it's
like
it's
a
good
idea,
but
just
not
something
we
need
to
do
say
just
for
this
one
method
and
let's
just
get
you
know,
let's
get
this
one
landed
to
add
it
add
the
one
method
and
then
yeah.
If
you
want
to
submit
pr
to
add
that
for
all
the
ones
where
it
makes
sense,
I
think
that's
a
good
way
to
go.
C
C
By
the
way,
I
have
a
quick
question
so
if
I
want
to
submit
some
issues
which
pretty
much
more
like
not
issues
but
more
like
topics
to
discuss
about
some
design
around
see
in
api
and
stuff,
what
would
be
good
reaper
to
submit
these
issues
to.
D
I
think
core
core
has
a
core
has
like
a
discussions
thing
where
it's
not
it's
not
an
issue.
It's
not
a
pr.
It's
just
discussion.
There's
like
I
forget
what
they're
called.
C
A
On
node
ad
on
api
or
the
core
or
note
api
before
yeah
core
has
discussions.
No,
but
I
mean
your
question
vladimir,
is
on
core
the
core
c
c
ap
course.
Yes,
yeah
yeah,
then
opening
either
an
issue,
or
I
mean
I
think.
Sometimes
the
discussion
happens
in
issues
but
like
yeah,
we've
started
using
these
discussions
as
well.
So
that's
just
another
way
of
opening
it.
C
A
D
A
A
C
It's
I
I
found
the
issues
implementing
them
on
other
platforms
for
other
javascript
engines
and
I
also
start
to
hit
them.
So
it's
like,
I
think,
like
we
can
change
something
there.
Sorry
sure
that
would
be
good
to
have
that
discussion.
A
Okay,
this
one,
I
think,
is
we
discussed
last
time
right.
Xinjiang
had
had
sort
of
tracked
it
down
to
the
exact
thing
that
we
might
backport
and
asked
about
where
we
would
backboard.
I
don't
know
if
there's
anything
more
on
that,
one
that
you
want
to
discuss.
H
E
There
was
another
issue
that
the
bot
marked
as
stale.
Okay,
this
was,
and
then
you
re-removed
it.
I
guess
you
removed
it
last
week.
It's
the
it's
on,
no
doubt
on
api.
It's
the
pull
request
right.
The
last
one
in
this
list-
and
this
was
a
migration
of
the
older
thread-
say
function
to
typed
thread,
say
function.
You
can
see
that
the
name
is
also
old
and
the
reason
that
we
had
blocked
this
was
because
it
required
a
newer
version
of
gcc
than
was
that
was
required
for
node
10.
A
E
A
Right
so
it
goes
to
four
nine.
So
yes,
that
should
okay,
that's
good.
E
A
We
have
windows
here,
yeah,
we
do
have
them
here,
but
yeah.
It
would
be
good
to
cross-check
against,
like
what
we
say
is
for
add-ons,
because
sometimes
the
difference
there
is
a
different
minimum
for
add-ons
versus
note
itself
and
windows
might
be
the
one
where
we
would.
F
D
A
A
So
maybe
it's
good
to
kind
of
align
it
with
that,
like
you
know,
when
we
do
december
major
to
drop
12,
this
also
goes
in,
and
that
would
be
that,
like
you'd
have
to
be
using
two
old
ones
like
not
just
the
past
lts,
but
the
lts
before
that.
E
Okay,
I
like
that
idea.
That's
all
that
I
wanted
to
discuss
for
stale
okay,
that
sounds.
A
Good,
so
back
to
milestone
11.,
so
tracking
for
modules
reported,
I
guess
nothing
really
new
there.
I
think,
in
terms
of
let's
see.
A
A
I
think
there's
just
still
no
massive
changes
or
difference,
but
still
a
pretty
healthy,
weekly
download.
So
then
looking
drives
for
full
coverage.
I
guess
we
don't
have
jack
out.
A
G
I
Hey
michael
yeah,
I
scratched
the
only
today
morning
or
you
can
take
a
look
at
it
comments
from
gabriel
only
today
morning.
So
okay,
maybe
we
can
take
a
time
until
next
meeting.
A
Sure,
well
I'll,
try
I'll
try.
You
know,
I
think
the
the
gabriel's
comments
were
pretty
minor
now
so,
like
I
think,
if
they
you
know,
if
it
looks
like
their
dress,
I'd
I'd
prefer
to
go
ahead
and
land
it.
So,
okay,
cool
I'll,
give
that
a
shot
hope,
maybe
this
afternoon,
depending
on,
if
other
things
get
in
the
way
or
not.
Okay,
okay,
that's
great
and
then
we're
down
to
the
list
of
issues.
So
I
don't
know
if
there's
any
issues
in
either
repo
that
people
have
in
mind
that
we
should
talk
about.
E
I
should
have
this
number
memorized.
I've
looked
at
it
burned
into
your
memory.
There
is
an
open
pr
for
1086.
E
There
we
go
okay,
so
what
this
was
doing
is
removing
const
from
those
methods
and
then
he
added
tests
to
make
sure
that
they
work
and
then
the
tests
don't
work
because
signal
wasn't
being
called
so.
I've
looked
into
this
and
what
we
had
talked
about
last
time
was
sort
of
modifying
what
we,
what
we
like
package
up
and
use
in
in
our
internal
code.
So
you
know
either
they
give
us
directly
their
their
data.
B
E
E
But
I'm
seeing
the
same
issue
where,
if
you
call
the
method
multiple
times,
sometimes
it
doesn't
get
called,
and
I
think
that
was
similar
to
the
other
issue
that
actually
made
this
fail
was
which
was
calling
it
with
null
pointer
or
something,
and
I'm
not
sure
the
internal
workings
of
all
of
the
lib
uv,
threading
and
whatnot
as
to
why,
if
we
do
several
non-block,
several
non-blocking
calls
stuff
just
doesn't
get
called,
or
something
like
that.
I.
D
I
have
a
hypothesis-
maybe
maybe
the
core
implementation
of
an
api
threat
say
function
is,
has
a
bug
in
it
like
I
wrote
that,
but
and
I've
tested
it
as
best
I
could,
but
maybe
I
missed
a
spot
and
because
the
idea
is
the
semantics
are
that
every
call
from
the
thread
results
in
a
call
on
the
main
thread
right,
whereas
the
semantics
of
just
a
simple
uv
async
handle
are
such
that
any
number
of
calls
from
the
secondary
thread
result
in
at
least
one
call
on
the
main
thread
right.
D
So
so
the
basically
the
zone
that
for
for
the
threat
say
function,
is
to
go
from
this.
Many
to
one
semantics
to
a
one-to-one
semantics
right-
and
I
did
my
best
to
do
that.
But
I
may
have
missed
some
synchronization
issues
or
something
so
one
possible
way
forward
that
I
can
think
of
is
if
you
could
try
to
write
all
of
this
without
using
know
that
on
api.
D
So
if
you
can
reproduce
this
with
c
alone,
then
you
will
have
uncovered
the
bug
in
threat.
Safe
function
right
because
then
we
can
eliminate
know
that
on
api
as
the
culprit
right.
Okay,
so
that's
another
possible
avenue
forward
and
if
you
don't,
then
that's
also
valuable
information,
because
then
you
know
for
sure
that
it's
somewhere
know
that
on
api
right
right.
A
E
E
Yeah
he
discusses
that
there,
because
we
had
all
asked
like,
is
it
possible
to
to
remove
or
put
kant
somewhere
else?
And
then
this
was
his
chain
of
reasoning
here.
A
A
A
We
call
their
method
from
a
chain
which
we've
marked
const,
which
really
isn't
we
haven't
forced
that
to
be
const
on
the
you,
the
end
users,
which
is
a
potentially
broken
chain,
breaking
change,
yeah,
okay
right,
so
that's
another
sort
of
wrinkle
to
think
about
when
we
think
about
other
methods.
But
I
don't
think
that
applies
to
any
of
the
other
ones
we
saw
so.
C
Can
I
just
kind
of
comment
on
this
kind
of
writing
here
says
like
conditional
variable
member
available
with
negative
51
is
not
const.
It's
typical
that
many
kind
of
classes
which
using
some
synchronization
primitives
like
conditional,
variable,
mutex
and
stuff
even
method,
is
constant,
but
typically
this
member
variables
marked
as
a
mutable,
because
thing
it's
considered
considered
to
be
acceptable
that
the
kind
of
synchronization
primitives
inside
of
classes
mark
as
mutable
like,
for
example,
ref
counting,
is
even
calm.
In
typically
it's
mutable
field.
E
So,
just
for
clarification
would
that
mean
that
you
would
be
able
to
make
the
method
const,
but
then
you
signify
precisely
which
variables
are
changing
by
marking
the
mutable?
Yes,
yes,
I
see.
A
A
F
A
D
D
D
This
may
be
worth
a
test
in
core
like
for
for
core
threat:
safe
function.
I
I
don't
know
I
if,
if
there
is
anything
special
that
we
can
do
right
like
if
the
if
the
user's
javascript
thread
side
callback,
which
processes
the
incoming
async
message
from
the
secondary
thread,
if
that
throws
an
exception,
then
we
are,
you
know
we're
we're
in
we're
in
an
async
context
and
I'm
assuming
the
async
context
should
correctly
throw
the
exception
at
some
point.
A
D
A
D
D
D
An
exception
yeah
so
yeah,
so
so
so
the
callback
function,
which
you
give
during
the
construction
of
the
threat
safe
function,
which
is
responsible
for
turning
whatever
data,
is
coming
from
the
secondary
thread
into
like
an
api
values
or
whatever
javascript
can
digest.
If
that
call
or
or
if
that
function
throws
an
exception.
Apparently
that
exception
is
getting
swallowed
rather
than
bubbled
up
to
wherever
it's
appropriate.
E
D
D
H
H
H
D
The
the
word
throw
does
not
appear
in
the
in
the
red,
say,
function
test
in
node
core,
so
I
don't
think
we're
throwing
anything.
A
D
A
So
I
think
we
figured
this
one
would
be
like
it
could.
It
could
cause
code
to
like
it
might
actually
cause
some
existing
code
not
to
run
anymore,
but
I
think
in
our
discussion
we
still
thought
it
was
the
right
thing
to
do
in
this
game.
It
is
correct,
behavior
too,
and
that
it's
a
low
enough
chance
of
affecting
existing
code
like
the
existing
code,
isn't
is
already
not
doing
what
it
was
expecting
to
do.
Yeah
and
we're
in
an
inconsistent
state.
A
So
you
know,
I
think
I
think
it
it's
still
like
december
major,
yes
and
okay.
You
might
end
up
with
some
add-ons
that
worked
okay
in
older
burns,
but
not
new
versions
but
like
this
is
a
case
where
that's
a
small
enough
chance-
and
you
really
want
to
surface
these-
like
it's
really
a
bug
yeah.
So
we
should
do
it
just
kind
of
what.
E
A
A
H
A
Or
variant
12.?
No!
Well!
No!
I
was
just
I
I
guess.
What
I
was
saying
is
like
we
really
in
in.
We
just
avoid
december
majors
and
no
no
dad
like
node
api,
because
it's
meant
to
be
stable
across
versions
right.
So
the
fact
that
it
we've
got
a
major
version.
Even
then
we
normally
wouldn't
make
it
we'd.
Add
like
a
new
method
or
we'd
work
around
it,
but
like
for
this
one,
you
know
I.
A
I
think
it
is
the
right
thing
to
say:
well
we're
going
to
land
it
in
december,
major
we're
not
necessarily
going
to
backboard
it,
but
like
going
forward,
you'll
get
the
right,
behavior
and
we've
given.
If
it
we
don't
think
that'll
affect
people
and
if
it
really
does
affect
people,
we've
got
to
fall
back
through
the
flag.
A
H
A
H
A
C
A
A
Anything
more
on
this
one.
We
should
talk
about.
A
No
okay,
any
others
that
we
should.
Actually,
I
see
we're
over
time
as
well,
so
any
others
that
we
should
talk
about
before
we
close
out.