►
From YouTube: 2021-09-17-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
A
If
not
we'll
start
by
looking
what
was
tagged
for
milestone
11.,
so
the
first
one
is
looking
at
the
node
zero
port
and
the
review
that
was
requested
there.
A
number
of
nick
and
kevin
who
had
started
to
review
aren't
here.
So
I
think
we'll
just
assume,
there's
no
update
on
that
this
week.
A
A
Right,
so
I
think
this
one:
yes,
we
can
you're
much
better
awesome
excellent,
so
this
one
I
think
we
talked
about
last
time.
Jack
had
landed
the
issue
which
went
into
node
core
and
we
talked
a
little
bit
about
what
to
do
in
in
node
add-on
api
itself.
I'm
just
wondering
do
we
capture
that
in
some
other
issue.
A
But
I
guess
I
don't
know
jack
if
there's
any
update
on
this
in
terms
of
work
on
the
node
api
side
or
it's
just,
we
should
leave
it,
as
is
until
we
make
some
progress.
B
I
haven't
really
like
take.
I
haven't
really
gotten
like
able
to
get
a
look
at
it,
but
wait.
A
Think
in
in
core,
it's
now
done
yeah,
but
it
now
that
we
have
that
ability
to
basically
support
it
in
in
since
it's
in
core.
Now
in
the
code
within
the
node
add-on
api,
we
want
to
change
the
code
that
handles
throwing
errors.
Okay,
so
that,
like
you
know,
I
think,
I'm
not
sure
if
we
need
to
change
anything
in
symbols
or
their
they'll
currently
just
work,
but
we'd
probably
want
to
test
that.
A
Yeah,
exactly
in
the
note
it's
it's
sort
of
in
this
code,
which
is
where
we
end
up
with
this
fatal
error
yeah
instead
of
that
happening
like
so,
we
should
now.
Actually,
this
should
just
work.
I
think,
for
a
symbol
because
now
create
reference
should
work
on
a
symbol,
but
for
native
types
we
want
to
wrap
them
in
something.
Instead
of
throwing
an
error.
C
A
D
A
A
We're
gonna
make
it
opt-in
to
get
the
improved
behavior.
So
you
if
you
opted
in,
but
I
can't
remember
where
we
wrote
that
down.
If
we
did.
A
Api
opt
in
through
define
right
to,
if
opt
in
then
basically
improve
behavior.
A
A
A
C
C
C
C
Know
wait
a
second
we
can
we
can
we
we
might
be
able
to.
We
might
be
able
to
handle
this
gracefully,
I'm
just
thinking
like
if
we
so
so.
So.
The
problem
with
this
whole
thing
is
that
we
want
this
persistent
reference
because
an
exception
tears
through
the
stack,
including
the
the
scope
in
which
the
value
was
created
right.
C
We
can
do
that
if
creating
the
symbol,
fails
or
creating
the
reference
for
the
symbol
fails,
we
can
create
a
an
object,
store
the
symbol
on
the
object
as
a
property
or
or
an
array
whatever
it
doesn't
matter
and
and
then
get
a
persistent
reference
to
the
object
and
have
a
have
a
flag
inside
the
the
an
api
like
the
an
api
call
and
call
an
error
object.
It
says
disks
is
a
symbol
that
is
wrapped
as
an
object
right.
C
Okay,
I
see
yeah,
and
so
so
so
this
is
the
behavior
people
are
opting
into.
Is
this
this?
So
so
it
will
always
succeed.
We
do
not
propagate
the
error
coming
from
core
if,
if
it
fails
to
create
the
reference
for
the
symbol,
yeah
just
that
people
need
to
understand
that
we're
doing
this
wrapping
and
unwrapping
behind
their
backs.
A
Right,
so,
if
you
opt
in
and
in
the
opt
in
the
dock
that
talks
about
the
opting
in
it'll
say
in
the
future,
this
will
actually
work
properly.
As
a
symbol,
you
know
you
will
get
the
original
symbol,
so
write
your
code
so
that
you
can
handle
both
cases,
it
either
being
the
actual
symbol
or
it
being
a
wrapped
object,
and
then,
once
all
all
lts
versions
support
it.
We'll
flip
wait.
C
C
So
ultimately,
the
error
ends
up
at
the
at
like
if
the
user
doesn't
handle
the
the
the
error.
C
In
our
code,
we
can
check
that
it
is
a
wrapped
symbol
and
unwrap
it
and
then
send
it
to
the
engine,
because
at
that
point
nothing
is
tearing
through
the
stack
anymore
right,
because
it's
going
over
a
c
barrier.
C
So
so
you
know
it's,
you
cannot
bubble
an
exception
across
a
c
function
right,
so
we
have
code
that
that
ultimately
calls
an
api
throw
right
and
that
drone
that
which
is
passed
to
an
api,
throw
need
not
be
a
persistent
reference,
so
so
wrapping
exceptions
in
persistent
references
is
something
that
we
do
in
node
add-on.
Api.
A
A
E
C
Well,
well,
the
symbols
are
the
only
ones
that
truly
need
to
be
wrapped.
We
can
wrap
primitives
as
well,
but
with
primitives
you
can
just
copy
the
value
and
and
and
then
just
shepherd
the
value
through
the
stack
as
the
exception
tears
through
it,
and
then,
when
you
convert
it
to
a
throw,
you
can
just
convert
it
to
a
proper,
an
api
value
so
construct
a
string
construct,
a
number
constructor,
whatever
you
know,
depending
on.
What's
in
the
exception
right
like,
I
guess,.
A
C
We
don't
need
a
reference,
so
if
the,
if
you
don't
have
to
create
the
reference
right,
because
the
the
reason
we
create
the
reference
is,
is
because
right,
an
an
api
value
would
go
out
of
scope
as
as
it
tears
through
the
stack
right
yep,
but
a
primitive
that
is
stored
directly
in
the
error.
Object
would
not
go
out
of
scope,
it
doesn't
have
the
concept
of
scope
right.
It's
just
stored
in
memory.
A
C
A
C
A
A
But
we're
not
throwing
an
airness
necessarily
in
this.
We
just
end
up
throwing
an
error,
because
we
can't.
D
A
C
A
I
don't
know:
there's
a
to
cast
if
you'd
been
following
the
discussion
and
had
had
something
to
add.
A
Okay,
we
we-
we
were
just
talking
about
this
one.
You
know
the
get
clear
penny
exception
and
last
time
we
talked
about
wrapping
like
the
symbol
or
the
the
the
primitive
in
an
object,
but
gabriel
was
just
suggesting
that
you
know.
Instead,
if
we
just,
we
don't
necessarily
need
to
create
a
persistent
reference
if
the
if
it's
a
primitive
and
we
might
be
able
to
solve
it.
That
way
now
we're
just
taking
a
quick
look
at
the
code
to
see
like
is:
is
that
going
to
work
or
is
there
some
gotcha
that.
A
This
right
here
we
would
do
a
check
that
says
if
it's
not
an
object
being
passed
in
that
we
would
just
copy
the
value
in
and
out.
D
Yeah,
that
will
be
a
it's
very
initial
thought.
I
believe.
D
D
If,
as
far
as
I
can
tell,
there
is
a
shorthand
method
for
object
reference,
you
know,
so
I'm
not
sure
that
we
can
properly
handle
all
this
methods
on
the
objective
reference
for
primary
values.
C
C
You
know
the
the
the
set
this
the
set
property
can
fail
right.
So
there's
it
returns
a
boolean
whether
the
set
succeeded
or
not,
even
even
by
spec.
C
D
Right,
yes,
the
major
concern
I
have
on
this
approach
is
that
we
have
a
lot
of
rapping
in
not
add-on
api.
Yet
we,
what
we
have
for
another
add-on
api
is
that
it
is
a
very
thin
wrapping
on
the
natural
c
interface.
So
if
we
have
this
type
of
wrapping,
then
there
is
a
lot
boilerplate
code
in
the
api,
like
setup
tracking
and
many
other
code
pieces
that
we
are
going
to
duplicate
in
an
api
for
object
for
the
other
class.
C
That
that's
fair,
I
think
and
yeah,
so
so
yeah
you're
right.
We
we
shouldn't,
we
shouldn't
go
overboard
with
the
rapping,
so
I
I'm
sorry.
I
missed
it
because
of
my
audio
issues.
What
was
the
conclusion
on
on
just
you
know.
C
If,
if
creating
a
reference
for
a
symbol,
fails,
then
then
that
basically
tells
us
that
we
are
on
a
version
of
node.js
where
we
have
not
yet
implemented
where
we
have
where
we
don't
yet
have
jax
change
available
right,
and
so
how
about
we
limit
our
our
wrapping
into
an
object
to
just
just
when,
when
you
know
the
symbol
fails
and
then
and
then
we
unwrap
again
and
then
we
document
it.
In
this
case
we
will
wrap
and
for
primitive
values.
C
C
C
Michael
and
I
we
were
just
thinking
that
you
know
if,
if
you
try
and
api
create
reference
and
you
pass
in
the
symbol
and
it
doesn't
return
an
api
okay,
then
you
you
know
that
you're
on
a
node.js
version
that
doesn't
support
that.
Yet
right,
so
you
don't
have
to
call
an
api
get
note
version.
The
failure
of
of
of
creating
a
reference
to
a
symbol
is
itself
a
version
check
right,
and
so
so
you.
C
D
Yeah
one
problem
for
the
object:
wrapping
for
symbol
is
that
we
have
a
lot
of
let's
say,
disallow
javascript
execution
scope
in
node
core.
In
that
case,
we
will
fail
to
create
the
wrapping
since
the
object
dot
set
the
according
to
javascript
eventually,
so
that
would
fail
anyway.
C
Well,
I
mean
we
did
our
best
is
all
I
can
say
in
that
case
you
know,
and
we
can
document
this
and
say
that
you
know
if
you,
if
you,
if
you
do
throw
a
symbol,
then
then
you
know
these
are
the
these.
Are
the
caveats
right
like
we
will
do
our
best
to
do
it,
but
if
javascript
execution
is
so
excuse,
basically,
I
think
that
the
text
will
be.
C
A
A
D
C
Yeah,
that's
that's
a
good
point
for
for
for
for
non
for
non
for,
for
when
exceptions
are
disabled,
we
don't
even
need
this
like
yeah,
ideally
for
for,
when
exceptions
are
disabled,
we
wouldn't
even
need
error
to
to
be
a
subclass
of
object
reference
because
we
don't
need
to.
E
D
And
there
is
a
point
that
the
error-
and
the
exception
is
two
different
kind.
Error-
is
supposed
to
be
a
subclass
or
javascript
error.
Class
an
exception
can
be
arbitrary,
javascript
values.
So
eventually
I
was
thinking
that
the
exception
there
is
a
new
class
for
exception.
That
represents
the
the
arbitrary
javascript
value
and
that
will
be
x.
It
should
be
referenced
and
that
should
be
referencing
when
c
plus
plus
is
enabled,
and
the
error
is
just
a
plain,
arbitrary.
C
Yeah
yeah,
I
understand
yes
right.
So,
okay,
I
think
I
think
we
have
a
pretty
clear
picture.
So
where
do
we
go
from
here?.
A
D
A
A
It's
kind
of
like
is
it
what's
the
likelihood
of
somebody
having
to
change
their
code?
If
that's
really
really
really
small
then
like
in
the
wrapper,
I
think
we
can.
We
could
consider
it,
but
you
know
if
it's.
If
it's
that
you
know
most
people
are
going
to
have
to
change
the
code,
then
I
still
think
we're
in
the
category
that
we've
been
trying
to
avoid.
D
Mentioning
about
the
error
I
will
I
will.
I
want
to
mention
that
in
recent
typescript
versions,
they
are
marking
the
code
error
as
a
unknown
type
and
that
would
require
people
to
change
their
code
and
before
the
mostly
people
are
treating
the
court
exceptions
as
objects,
mostly
so
recently,
that's
good
version
by
defaulting
by
marking
the
exception
value
as
a
unknown
type.
It's
not
a
it
might
be
not
it
might
not
be
a
object,
so
people
have
people
have
to
change
their
code
eventually
and
that's
a
default
behavior.
A
D
A
D
Yeah
so
first
step
it
will
be
not
breaking
change
and
we
will
do
our
best
to
under
the
approach
mentioned
by
gabriel.
Like
say,
we
are
breaking
out
when
we
cannot
referencing
symbols
and
wrapping
it.
You
know
in
an
object
and
and
and
storing
the
primitive
values
in
negative
cell
and
recreating
this
primitive
value.
D
A
A
I
mean
it
may
already
be
there,
but
did
it
need
to
be
visible
or
could
we
just
store
the
value
in
every
case
and
the
reference
is
there
to
keep
the
value
alive
if
we
needed
to,
but
you
use
the
value
in
the
general
case
and
if
it
happens
to
be
an
object,
you
create
the
reference.
If
not
you
don't
does.
D
D
A
D
A
A
Sorry,
okay,
I
started
saying
we
we
get
this
value.
The
main
reason
we
create
the
reference
is
so
that
we
make
sure
that
value
stays
a
lot
yeah
right.
So
what
I'm
wondering
is
if
we
change
the
code
here,
that
basically
says
store
the
value,
because
we
always
want
the
value,
whether
it's
a
primitive
or
something
else
store
the
reference
to
the
value,
because,
if
it's
a
primitive,
we
don't
will
the
value
go
away.
A
I
guess
it
does
right.
Okay,
so
we
need
to.
We
need
to
actually
right.
So
basically,
it's
in
here
that
says
get
get,
something
which
either
points
to
an
object,
which,
I
guess
is
the
reference
or
it's
the
native
values.
Maybe
maybe
it's
ending
up
being
the
same
thing
as
we
were
already
talking
about,
but,
like
this
code
basically
says
and
like
if
it's
a
symbol,
it
could
basically
try
and
just
yeah
okay,
maybe
it's
coming
back
to
the
same
thing
for.
C
If
it
failed,
then
don't
go
fatal
right
away,
create
an
object
and
then
store
it
there
and
then
create
the
reference
to
the
object,
and
if
that
fails,
then
yes,
then
it's
fatal,
and
then
that
would
handle
symbols
and
it
would
handle
primitives
and
it
would
handle
everything
and
in
the
case
of
in
in
the
case
of
symbols,
sooner
or
later
it
will
not
fail.
So
it
will
only
be
for
primitives,
sooner
or
later
right.
A
C
C
D
No
external.
C
D
C
A
D
E
A
C
No
that's
right
so
so
sooner
or
later,
symbol
will
fall
into
the
category
where
you
can
just
simply
wrap
it
and
create
reference,
doesn't
fail
right,
right
and
and
and
then
only
the
primitives
will
be
left
and
that's
actually
exactly
what
we
want,
because
because
primitives
will
always
be
different
because
we
cannot
create
references
to
primitives.
A
C
A
A
Okay,
so
we
don't
need
to
make
it
opt-in
or
anything.
We
can
just
make
this
change
and
because,
because
within
you
know
api,
it
will
the
node
add-on
api.
It
will
be,
you
know,
storing
these,
these
things
indirectly,
if
necessary,
but
hiding
that,
because,
when
you
throw
it,
it
will
throw
the
right
thing.
C
Yes,
yes,
okay,
so
so,
basically
yeah
there's
still
the
there's.
Still
no
javascript
execution
allowed
a
case
that
that
lucas
mentioned-
and
that
is
that
is
valid.
However,
I
think
the
overall
picture
here
is
that
we
will
have
reduced
the
cases
in
which
attempting
to
throw
an
exception
will
result
in
a
fatal
error
so
because
we
we've
reduced
it
from
any
time.
An
api
value
is
not
a
reference
to
any
time.
Any
pi
value
is
not
a
reference.
A
A
C
C
C
So
no
you
you'd
want
you'd
want
to
look
at
the
implementation
where,
like
the
the
callback
wrapper,
is
what
you'd
want
to
look
at,
because
that's
where
we
have
this
situation,
that
you
know
if
you
know
where
we
we
do
a
try
and
catch.
So
just
look
for
try.
I
think.
A
B
A
So
basically,
here
it
needs
to
do
some.
Some
unwrapping
right.
A
C
C
A
Okay,
so
I
think
that
ends
up
being
a
fairly
small
change
then,
and
it
doesn't
need
to
be
opt-in
because
the
the
change
in
symbol
I
guess
is,
is
there
is
some
case
where,
like
on
the
c
side
of
the
code,
you
can
get
the
reference
from
the
error
object
and
that
will
change
right
between
the
the
two
cases.
Now,
that's
a
pretty
small
case,
I
think,
is
it.
C
Yeah
yeah
there's
I
mean,
but
we
we
do
store.
We
do
store
a
boolean
flag.
That
says
this
is
a
wrapped
error
right,
and
so
so
you
know
if,
if
that
flag
is
false,
that
means
creating
the
reference
succeeded
and
we
pres
and
we
proceed
as
we
do
today.
A
Right
right,
I'm
just
like
visible
changes
like
could
somebody
write
code
that
has
symbol,
you
know
as
you
as
you.
You
write
your
code,
you
test
it
on
a
version
that
doesn't
support
symbolism,
references
now
you
run
it
on
a
version.
It
runs
on
a
later
version.
A
C
A
Okay,
yes,
that
would
make
sense,
you
know
also
in
override
value,
so
that
it
does
unwrap
as
well
right
yeah
and
that,
basically,
I
think
if
we
do
that,
then
there's
no
visible
people
like
outside
of
there's
no
visible
change
outside
of
the
internal,
like
the
only
changes,
internals
anything
anybody
saying
give
me
the
the
symbol
will
still
get
the
actual
symbol,
both
c
code
in
it.
Okay,.
A
Okay,
so
I
think
I
think
that's
that's
pretty
clear
now
I.
D
D
Where
and
which
one
would
that
be
it's
defined
in
reference
class
and
it
it
has
a
operator
to
convert
reference
class
to
napier.
A
D
D
D
Decide
what
these
functions
behave
when
we
are
referencing
the
right
wrapping,
the
primitive
values
they
are.
People
can
get
the
wrong
reference
for
the
error.
A
C
C
But
but
but
in
the
case
of
the
in
the
case
of
the
casting
operator,
right
people
actually
want
the
the
c
reference
and
we
cannot
give
them
a
c
reference
to
a
primitive.
We
just
can't
right,
because
we
didn't
actually
create
a
c
reference
to
a
primitive.
We
created
the
c.
C
C
C
C
A
C
A
C
A
C
C
A
C
E
C
Sure
you
know
so
so,
where
we're
already
we're
already
kind
of
holding
people's
hands
and
giving
them
crutches
at
this
point,
you
know,
instead
of
having
them,
do
proper,
javascript
and
and
we're
going
way
out
of
our
way
to
help
them
out
here
right.
A
A
Capture
that
there,
so
we
are
five
minutes
after
already
I
did
want
to-
let's
see
just
if
we
quickly
there
was
one.
I
think
this
one
we
already
talked
about,
possibly.
A
I
think
that
one
yeah,
so
I
think,
that
one's
okay
and
actually
that
one
I'm
just
going
to
take
off
the
edits.
I
think
we've
done
what
we
needed
to
on
that
one
yeah
and
this
one
was
another
one.
I
just
wanted
to
take
a
quick
you
know
see.
Does
anybody
have
any
concerns
on
this?
Adding
this
iterator.
C
Yeah
I'd
have
to
have
a
look
which
one
is
this
930
yeah.
Let
me
open
that
yeah.
A
A
And
I
guess
jack
and
and
I
guess
we
lost
deepak
but
like
did
you
have
anything
on
the
test
front?
You
wanted
us
to
cover
to
get
you
unblocked
or
anything
like
that.
B
A
A
F
A
So
I
guess
gabriel,
you
know
if
you
just,
I
know
you're
looking
at
that
one
now,
if
you
just
want
to
comment
there,
if,
like
you,
don't
have
any
concerns,
comment
come
out
one
way
or
the
other,
and
then
you
know
I
can
take
a
look
at
landing
and
if
it's
there
all
right,
okay
sounds
good.
Okay!
Well,
thanks
for
everybody's
time,
then,
and
good
discussion
and
we'll
talk
to
everybody
later.