►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
B
Fine
I
mean
I
think
this
is
the
part
where
you
guys
tell
me
what
the
convention
is.
You
know
is
in
the
situation
like.
Do
we
obsolete
that
API
and
I
was
added
not
too
long
ago
or
we
supported
don't
until
some
time
elapses
or
I'm
fine
with
you
know,
whatever
the
you
know,
people
know
me
doing
this
well,.
C
C
E
There
any
benefit
so
from
from
what
I
remember
the
reason
we
weren't
just
adding
to
the
previous
one
was
because
it
was
a
struct
and
we
didn't
want
to
add
a
whole
bunch
of
fields
to
a
struct.
But
if
we're
talking
about
now
adding
a
new
method
that
returns
a
class
can
be
structured
such
that
we
just
add
a
single
field
to
the
thing
returned
from
the
existing
API.
That
is
itself
a
class
that
contains
everything
else,
or
is
that
bad
for
some
reason.
E
E
It's
gonna
say
we
currently
have
you
know
I
I'd.
Their
way
forward
from
here
gives
us
a
set
of
ap.
Is
that
we're
not
thrilled
about
either
we
just
added
an
API
and
we're
gonna
deprecated
it
and
that's
something
new
that
looks
very
similar
or
we're
going
to
kind
of
massage
the
existing
one.
It
is
something
that
meets
our
needs
and
some
properties
look
like
they're,
more
important
than
others.
I,
don't
know
which
is
better
but
I'm
wondering
if
we've
completely
explored
what
that
might
look
like
I.
A
If
GC
generation
infos
currently
exposing
them
as
properties
and
not
directly
the
fields,
then
essentially,
if
I
understood,
Steve's
proposal
its
make
GC
info
a
internal
class
copy
all
of
the
properties
on
to
GC
generation
info
and
then
just
change
it
to
a
struct
wrapping
the
reference
type,
which
makes
it
a
reference
type.
But
without
changing
our
public
API.
E
C
G
H
B
G
B
A
C
B
D
D
A
B
A
B
H
H
B
Okay,
I
see
seems
strange
to
me,
but
why.
B
E
A
F
D
B
E
A
C
A
C
A
B
A
B
Because
I
didn't
I
should
put
this
in
the
proposal
which
I
probably
should,
but
you
know
I
can
ask
it
now
so
that
you
see
that
generation
info.
Is
there
any
way
that
you
prefer
to
you
know
it's
at
the
bottom.
I
was
GC
generation
the
info,
so
that
would
have
a
right
so
like
that
would
have
like
last
if
we
were
shipping
those
atheon
last
release.
That
would
have
four
elements
right,
but
since
worshipping
in
this
release
this
has
five
elements
and
in
the
future
it
might
have
more.
B
C
B
C
F
K
A
B
That
much
thought,
but
I
would
think
this
we
just
make
a
probably
we
have
an
array
that
you
know.
Gc
obviously
wouldn't
create
anything
new.
We
just
sign
inside
GC.
We
just
have
one
big,
you
know
struct
or
whatever
that
we
don't
end
at
the
at
the
end
of
each
GC
and
then,
as
far
as
how
this
info
gets
delivered
to
the
VC
outside
I'm
thinking,
you
just
you
know,
create
a
new
class
in
the
VCL
and
then
make
enough
call
and
get
that
filled
in
I'm,
going
back.
F
A
I
guess
the
the
difference
would
be
because
if
the
pause
durations
array,
for
example,
was
implemented
as
the
getter
is
returning
a
copy
of
the
you
know
the
collection
97
data,
then
that
means
that
the
getters
returning
a
new
array.
So
if
someone
writes
a
for
loop,
that's
actually
an
N
squared
operation,
and
so
the
the
getter
can't
return
a
new
array.
A
So
we
sort
of
discourage
properties
returning
arrays,
because
now
it's
ambiguous,
so
either
a
method
to
encourage
someone
to
cache
it
locally
before
they
loop
over
it
or
if
we
want
to
say
it
makes
more
sense
as
a
property,
but
we're
promising
that
we
took
it
as
a
snapshot.
And
if
you
mutate
the
one
that
you
get
back,
then
yeah,
it's
mutated,
don't
mess
with
the
GC
info
data,
but
one.
K
I
mean
you,
one
thing
you
could
do
is
making
it
lazy
right,
I
mean
you
could
say
we
don't.
We
don't
allocate
it
eagerly,
because
maybe
some
people
who
call
the
class
only
care
about
you,
know
the
Bulls
or
the
lungs
we
expose
here.
And
then
you
only
allocate
the
array
when
somebody
actually
pulls
on
the
property
from
prostrations
or
Jen
info
right.
B
A
B
D
A
And
calling
clone
on
it,
then
the
clone
of
that
object
would
need
to
or
you
should
copy
the
arrays.
But
now
it's
built
for
the
object.
When
somebody
gets
it
back
or
you
could
lazy
make
the
cloned
objects
do
a
lazy
copy
as
long
as
they
memorize
it
and
don't
return
it
as
a
new
one.
Every
property
get
yeah,
but
two
different
calls
to
get
memory
info
or
whatever
the
method
is,
should
see
two
different
arrays
by
reference.
C
I
B
B
B
C
K
Yeah,
if
we
can
do
that,
that
makes
sense
like
the
way
understood
Melanie's
comment
was
that
we
can't
do
that,
because
the
the
runtime
will
update
them
whenever
they
see
fit
and
if
he
already
gave
out
a
reference
to
that
then
and
it
you
know,
GC
happens
at
the
time.
Customer
code
runs
inspecting
the
GC
info.
You
might
actually
change
the
wages.
The
customers
looking
at.
C
A
So,
if
something
like
a
call
to
get
memory
info
happens
and
it
sees
that
the
index
is
not
the
equal
to
the
last
index,
that
it
says
new
GC
info
and
then
that
builds
the
array
and
just
returns
the
span
since
there's
no
caller
management
and
we're
not
going
to
be
upgrading
or
updating
at
the
background,
and
we
promise
we'll
never
ever
ever
update
it.
In
the
background,
then,
returning
read-only
span
would
be
similar
to
what
we
did
at
encoding.
Yeah.
D
D
A
Stored
in
a
field,
then
it
massively
limits
what
the
implementation
can
do.
But
if
it's
a
just
a
snapshot,
return
API,
then
there
would
never
be
any
further
rights
to
it.
So
it's
it's
less
bad
yeah,
but
you
know
we
get
it
on
when
people
want
growable
writers
of
like
Oh,
give
me
a
span
of
what
it
wrote
it's
like.
C
B
A
Yeah
so
because
we've
now
made
this
a
reference
type
and
and
and
such
which
was
already
being
done
for
the
GC
info
that
does
allow
the
the
optimization
of
when
you
call
it
you've
saved,
just
the
singleton
create
and
it
doesn't
up
get
you
don't
actually
build
a
new
one
until
the
index
changes,
so
that
will
save
on
allocations
all
right.
What
other
questions
do
we
have
yeah,
so
so
index
is
how
many
times
the
garbage
collector
has
run.
Yes
does
that
have
meaning.
B
A
A
B
A
B
The
only
update
that
index-
and
you
know
what
you
would
see
is
actually
you
know
you
might
see
an
index.
That's
not
well.
I
mean
it's
in
API
that
you
call
you
could
very,
very
well
call
it
and
get
an
index.
That's
quite
a
bit
larger
than
last
time.
But
let's
say
you
call
this
often
now
you
know
more
often
than
the
GCE
intervals.
So
you
would,
you
might
see
something
like
you
know,
two
three,
four
five
and
then
eight
three,
seven
four,
because
it
wouldn't
be.
B
B
K
B
B
K
C
We
could
we
could
create
a
cached
copy
of
the
data
between
GCS
and
every
time
someone
calls
us
ap.
So
actually,
let
me
back
up
a
little
bit.
Mayo
Nealon,
if
two
different
threatens
call
this
API
it
approximately
the
same
time.
This
is
kind
of
a
rephrasing
of
Jeremy's
question.
They
get.
B
C
C
Gc
index
and
then,
assuming
that
the
GC
index
hasn't
changed
between
subsequent
calls,
we
literally
just
hand
that
same
structure
right
back
to
the
caller
and
then
once
a
GC
happens.
We
throw
our
cache
structure
out
in
its
entirety
and
then
we
lazily
created
the
next
time.
Someone
calls
us
API
so
that
yeah
that
would
work,
because
when
we
lazily
recreated,
we
also
lazily
recreate
all
of
the
arrays
and
everything
else.
So.
C
K
K
K
We're
talking
about
so
basically
there's
two
things
here
right,
so
if
we
make
the
arrays
that
are
currently
on
GC
info,
if
you
make
them
spans,
then
the
user
cannot
easily
stash
away
those
arrays
directly
right
because
their
span,
so
they
can't
you
can't
put
them
anywhere
really
fully.
The
other
thing
we
can
do
is
we
can
make
them
meet
only
so
the
person
doesn't
get
to
modify
them,
because
if
they
erase
they
could
just
read
or
write
into
them
if
they
wanted
to,
which
would.
K
They
could
right
so
moving
to
read-only
span
you.
You
basically
eliminate
these
two
things,
but
the
caller
can,
of
course,
already
take
the
entire
GC
info
thing
and
stores
it
in
a
static
list
somewhere
right,
there's
nothing
preventing
them
from
doing
that.
So
I
was
just
asking
because
it
sounded
like
what
we
said
earlier
as
we
want
to
use.
We
want
to
move
to
spam,
so
they've
been
so
that
we
can
recycle
parts
of
the
arrays,
but
it
sounds
like
the
way
we
do.
The
recycling
is
basically
between
GCS,
which
means
two
different
people.
K
Basically
asking
for
the
same
GC
info
for
the
same
GC
would
see
the
same
data.
Each
of
them
would
see
you
know
their
own
view
effectively
for
the
span,
but
if
they
both
stash
away
that
you
see
in,
for
instance,
that's
fine
because
next
time
UGC
happens.
There's
a
new
array
created
that
you
know
the
next
caller
will
get
out,
but
there's
nothing
wrong
with
exposing
it,
and
that
seems
fine.
K
Sorry,
I
just
want
to
make
sure
that
if
people
do
something
that
is
fairly
nice,
which
is
you
know,
just
stashing
this
thing
in
there
in
a
list,
you
still
want
to
have
stuff
consistent.
C
C
A
E
K
Even
then
I
mean
like
I,
think,
even
if
you
called
you,
know,
GC
info
from
an
async
method,
even
if
the
compiler
has
to
host
the
locals,
it
would
host
a
reference
to
the
GC
info
read,
which
is
fine
right.
Only
if
you
actually
assign
local
variable
one
of
those
arrays.
You
would
have
any
issues
to
begin
with
right.
So
I,
don't
think
that
that
using
we'd
only
spend
on
this
type
would
make
the
old
scenarios
less
usable.
No.
C
E
A
G
B
E
B
B
G
G
B
K
I
think
to
me
index
kind
of
the
other
thing.
It's
like
I
think
the
naive
view
people
would
have
by
reading
the
docs
is
that
the
number
only
goes
up
right.
So,
if
you
just
say
well,
the
the
index
really
just
represents
the
data
that
this
you
know
basically
some
Veda.
That
indicates
which
she
see
this
data
was
actually
associated
with
right.
Then
I
think
index
is
a
bit
of
a
weird
term.
K
K
A
D
K
B
K
So
that's
a
different
argument:
I
think
I
think
that's
more
compelling.
But
if
I,
if
I
use,
windbg
sort
of
individual
is
a
perf
you,
for
example,
and
I
try
to
correlate
information
that
perf.
You
gives
me
of
something
I
collected
in
my
application,
then
aligning
those
names
makes
sense
to
me
as
otherwise
it's
super
confusing
right,
but
so
so,
if
you
already
expose
the
terminology
index
in
tools
and
other
places,
and
people
have
to
deal
with
that,
then
I'm
almost
in
favor
of
keeping
the
name
here,
because
that
it
makes
it
easy
for
people.
B
B
B
B
Yeah
I
mean
I,
don't
I
think
if
I
paste
those
it
would
look
very
odd
in
in
the
chat
window.
But
in
her
few.
If
you
look
at
the
GC
stats,
which
is
what
many
people
do
it
just
called,
you
know
the
first
column
and
just
called
GC
index.
So
that's
a
number
that
was
the
API
will
be
returning
as
aimday.
G
K
B
Yes,
it's
ready,
I
mean
the
crank
term,
for
this
is
these,
are
the
objects
are
ready
for
finalization
right,
which
is
why
I
insisted
like
this
was
actually
the
one
place.
I
said
to
not
do
not
call
it
finalized
about
object,
because
finalized
about
object
means
something
very,
very
different
from
ready
for
finals.
So.
B
C
B
A
B
A
D
B
An
API-
and
that
does
mean
the
same
thing
but
I
so
the
finalize
the
terms
related
to
finalization,
because
I
think
Yan
was
the
one
who
said:
oh,
it's
the
same
as
what
we
expose
in
the
perk
counters.
So
if
so,
we
should
use
that
and
I
do
agree
with
that.
But
when
it
comes
to
finalization,
we
do
have
different
terms
like
and
if
you
use
windbg
you
so
as
debugger
extension,
it
does
say
right,
ready
for
fun.
Animations!
Oh
you
know
like
which
one
do
we
use.
I.
B
K
Mean
you
were
basically
iterating
or,
like
you
like
saying
like
how
important
is
to
differentiate
it
from
finalized,
Abul
and
I.
Think
the
the
character
difference
between
the
work
between
these
two
words
is
so
little
that
I,
don't
think
people
would
pick
up
that
you
know
on
so
I'm.
Just
looking
at
finalized
object,
count
I
think
most
people
probably
have
the
same
conclusion
we
had,
which
is
somebody
was
not
like.
You
know,
didn't
feel
like
typing
all
the
word
finalize
it,
but
or
something,
but
they
would
probably
assume
it's
the
same
thing.
B
B
A
A
M
B
L
A
B
B
Right
I
mean
this
would
so
Jen
three
physically
is
I'm.
Sorry
large
physically
is
Jen
three
in
GC
right,
but
it
gets
collected
in
Gen
2
disease
because
we
don't
have
when
you.
When
you
look
at
the
collection
generation,
there's
nothing
that's
more
than
two
right.
This
is
zero
one
two,
but
internally
physical
agent,
a
large
organ
heap,
is
represented
as
generation
three,
so
this
will
return
as
generation
three
in
the
array
right.
B
C
Digesting
that
and
going
back
to
your
question
Jeremy,
the
only
I
can
imagine
maybe
adding
an
INT
member
to
this
saying
what
logical
generation
am
I,
if
her
my
own
e.
These
are
intended
to
represent
physical
generations,
but
I
don't
know
if
that
information
is
really
useful
to
people
did
that.
Did
that
correctly
summarize
what
you
were
said
me
only
so.
B
Why,
or
you
know
it
would
be
very
easy
to
make
them
understand
like
when
I
iterate,
through
this
array,
when
I
get
to
Gen
2
info
and
then
I,
look
at
the
next
gen,
3
and
I
know
that
their
expected
your
ingenuity
I'm
not
sure
if
it's
necessary
to
expose
that
they
are
collected
in
a
Gen
2
GC
in
this
API,
because
I
feel
like
that's
just
something
that
we,
we
should
explain
the
documentation
and
there
might
be
a
you
know
in
the
future.
We
might
decide
some
of
those
are
not
like
sure.
A
I
guess
part
of
the
question
is:
are
they
so,
as
somebody
who
understands
a
little
bit
of
how
garbage
collectors
work?
I
know
that
if,
if
I
hold
on
to
a
reference
longer
than
I
needed
to
that
something
can
slip
from
gen
0
into
Gen
2,
and
that
if
I
can,
if
I
somehow
was
tracking,
that
I
would
could
trace
back
to
oh
I
should
have
dropped
the
reference
here
and
that
would
have
made
things
go
better,
which
generally
means
hierarchically
things
that
get
freed
in
later
generations
may
have.
A
B
Generations,
it
means
that
it's
not
like
if
I
look
at
the
fifth
element
for
Soria,
if
I
look
at
the
fourth
element
in
the
ring,
I
know
that
those
objects
that
get
elected
there
are
are
not
you
know
like
so
later
than
if
I
look
at
the
third
element
in
the
rain.
That's
not
necessarily
the
case,
because
some
of
the
elements
in
this
array
might
get
collected
in
the
same
generation.
Okay,.
B
B
We
could
I
mean
we
could
maybe
expose
some
kind
of
a
new
in
this
that
says
you
know,
0
is
0,
1
is
1,
2
is
2,
but
3
is
large
object,
generation
and
4th
in
the
object
generation.
Something
like
that.
I
I,
don't
know
if
that's
necessary,
but
you
know
if
you
want
like
a
more
meaningful
mapping
or
more
more
similar
to
what
you
see.
Yeah.
C
B
Our
audience
probably
just
know
the
relationship
from
using
other
purple
like
today.
You
know,
if
you
look
at
per
for
you,
it
tells
you
like
that
they're
wide
stable
in
GC
stats.
It
tells
the
info
on
gen,
0,
1
2
and
then
says
large
objects
key.
So
you
know
people
who
are
used
to
looking
at
that
table.
They
wouldn't
know
like
okay,
when
I
iterate
through
this
array
and
I
do
want.
0,
1,
2,
3
or
and
I
know
that
those
aren't
spawn
to
what
I
see
in
that
disease
has
people.
N
B
N
Sorry,
my
mic
was
turned
down
so
if
I
write
an
application
for
dotnet
v
and
I'm
interpreting
this
gen
info
array.
B
B
B
B
B
So
let's
say
if
somebody
called
this
API
and
Donna
five,
and
he
knows
that
the
length
of
this
array
is
five
today
and
obviously,
if
we
were
to
add
another
physical
generation,
Johnette
fix
and
then
he
looked
at
the
men
again
he
wouldn't
get
fixed
right.
But
if
he
remembered
from
don't
know
five
there's
five
elements
and
he
if
he
was
to
look
at
the
first
five
elements
and
those
would
still
be
valid.
C
K
I
mean
I'm
also
not
super
concerned,
because
they
really
have
a
hard
time
seeing
application
authors
doing
any
sort
of
decision
making
in
their
logic
as
the
app
is
running
like,
and
then
you
upgrade
the
app
between
versions.
I
think
most
of
it
is
diagnostic
data
that
you
interpret
out-of-band
effectively
right
right,
like
you
probably
take
this
data
and
dump
it
somewhere
right,
I.
L
A
K
Sends
me
it's
a
more
like
the
interpretation
of
the
numbers
might
change
over
time.
I
think
what
is
it
good
number?
What's
a
bad
number
in
the
same
way
that
we
evolved
our
understanding?
What
is
a
large
truck?
What's
a
small
struct
right,
I
mean
they're,
not
really
breaking
changes,
they're
just
involvements
of
what
constitutes
a
healthy
process.
Yep.
B
C
B
B
B
K
D
K
B
K
B
K
B
K
B
A
Because
we
had
the
question
of
we:
don't
we
don't
understand
how
to
interpret
the
number
and
then
so
my
own
e
says
it's
collective
for
the
the
percentage
at
and
so,
if
I
guess,
let's
see,
if
I
understand
what
my
only
wrote
I
believe
it
is.
As
of
the
time
this
collection
finished,
the
total
percentage
of
process
lifetime
that
has
been
spent
in
the
GC.
B
A
lot
of
this
is
to
essentially
you
got
better
for
counters,
so
one
of
the
biggest
problems
from
counters
was
that,
because
her
counters
are
completely
subjective,
subject
to
how
often
you
sample
them
right,
so
you
could
get
a
perk
counter.
That
says
spent
time
in
GC,
that's
very,
very
high
because
you
happen
to
just
have
done
in
an
expensive
GC
right.
So
let's
say
you
just
did
a
Gentoo
block
in
GC.
You
could
have
easily
gotten
this
counter.
That's
like
many
9%!
B
B
This
is
kind
of
misleading
to
people
because
they
would
think
like
Oh
for
the
last
light,
some
people
they
only
sample
this
like
once
per
minute
right.
They
sample
all
counters
a
County,
afford
to
sample
too
many
too
often,
so
they
would
get
a
counter
that
says
for
some
time.
Gc
is
many
9%
and
then
they
would
just
keep
that
for
a
duration
of
the
sampling
interval.
B
A
B
This
is,
you
know,
part
we
count
pause.
Time
is
just
kind
of
an
elapsed
in
labs
time.
So
if
your
process
has
been
running,
let's
say
for
10
seconds
and
there
has
been
100
milliseconds
total
in
the
GC
pause.
We
just
you
know,
report
number,
that's
100,
milliseconds,
divided
by
10
seconds.
We
don't
count
CPU
time
because
there's
not
there's
no
like
there's
no
cheap
way
for
us
to
get
the
CPU
time
in
a
programmatically.
B
A
F
B
K
C
B
Yeah
this
is
when
this
is
the
only
one
thing
that
I
really
wanted
to
be
different
from
the
counters
in
general.
You
know
I
wanted
to
expose
the
same
kind
of
info
as
we
dirty
imperf
counters,
because
I
know
that
a
lot
of
people
wanted
those.
But
this
is
the
one
thing
that
I
think
like
we
should
definitely
fix
those,
because
the
way
that
perf
counters,
you
suppose
they're
just
caused
a
lot
of
problems
just.
C
Out
of
morbid
curiosity,
is
there
any
desire
to
make
any
of
these
properties
static
so
that
you
can
just
easily
get
the
one
property
that
you
care
about
as
opposed
to
getting
this
entire
property
back
like?
Is
there
a
need
to
elevate
the
pause
time
percentage
to
be
its
own
first-class
citizen
kind
of
separate
from
this
struct
so.
B
I
think
this
comes
back
to
how
do
you
get
info?
That's
consistent
within
one
GC
like
if
we
I
mean,
if
there's
a
way
to
do
that,
but
you
know
break
this
apart
and
that's
totally
fine
with
me.
But
the
reason
why
I
have
them
all
in
one
class
or
structure
is
because
I
want
the
user
to
get
the
consistent
info
for
that
one
GC
index
that
they're
getting
elevated.
G
B
C
And
that's
fair,
the
reason
I
had
asked
is
you
know
you,
you
went
into
detail
about
how
important
this
particular
property
was
and
that's
what
made
me
wonder
like?
Should
it
be
elevated?
But
if,
if
the
answer
is
it
really
needs
to
be
taken
in
context
with
everything
else
and
that's
a
great
reason,
not
elevator,
so.
B
This
one
field
actually
could
be
elevated,
because
this
is
not
like
this
is
updated
at
HGC,
but
this
doesn't
have
to
be
like
there's
no
problem,
if
you
just
say
like
I'm,
just
getting
this
one,
you
know
I'm
just
getting
the
pause
time
percentage
stand
alone
without
any
other
info,
because
you
know
from
G
C
to
G
C.
It's
not
like
this.
This
number
is
gonna
change.
All
that
much
right
because
of
the
run
name
thing
is
you
know
you
can't
change
a
whole
lot
after.
A
Yeah
I
mean
having
it
that
wouldn't
available
as
a
static,
but
also
is
the
snapshot
so
that
when
you
say
when
I
write
down
I,
this
was
my
total
memory,
and
this
was
my.
This
is
how
much
time
thus
far
asterisk
I'd
spent
in
the
GC
like.
So
it
seems
reasonable
to
have
it
here.
It
also
seems
reasonable
to
have
it
as
a
static
somewhere
else
on
GC.
N
A
Yeah,
because
it's
less
about
like
you,
may
want
it
to
be
consistent,
but
you
I
can
see
that
you
could
also
want
it
without
caring
about
the
consistency
that
it
seems
more
interesting
than
asking
about
the
finalized
of
the
object
count.
Because
if
you
ask
for
that
one,
then
you
probably
are
also
gonna
care.
What
the
you
know,
memory
percentage
stuff
looks
like
at
which
point
you
wanted
the
GC
snapshot
and
not
just
the
one
number
sure.
C
Think
it
makes
sense,
I
think
it
makes
sense
to
keep
this
as
an
instance
member,
because
it
does
make
sense
in
the
context
of
all
the
other
information.
On
the
same
instance,
what
I
was
asking
is:
is
there
a
common
scenario
where
somebody
would
want
only
that
information
and,
if
so,
maybe
there's
maybe
that's
justification
to
have
another
API,
which
is
just
a
public
static,
double
percent
time
in
GC
I
can.
C
A
A
Okay,
I
think
that's
the
end
of
the
questions
list
that
we
had
from
last
time,
because
there
were
some
simple
renames
of
his
concurrent
became
concurrent,
is
etc
and
I
guess
one
implementation
question
I
have,
since
my
eyes
went
straight
to
generation
here
this
is
still
bounded
between
its
0
1
or
2
right.
This
is
the
logical
gen
as
opposed
to
the
property
or
the
right.
Okay,
because
this
matches
the
GC
collect,
which
generation.
B
E
B
B
A
A
As
part
of
itself
is
up
to
you
right
now
there
was
there
was
a
request
for
it
in
the
chat,
as
opposed
to
somebody
needing
to
memorize
what
index
formant,
but
that
could
be
that
we
do
in
enum
and
then
you
index
using
the
enum
as
well
so
yeah
all
right.
Does
anybody
have
anything
that
they
cared
about?
That
I
didn't
write
down.