►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
All
right
do
we
have
jason
people
on
the
call.
D
Oh
boy,
I
I
know
there's
some
discussion
in
the
issue
about
this,
but
this
is.
This
is
gonna,
be
fun
if,
if
you
don't
know
ahead
of
time
whether
the
the
collection
is
comfortable
or
not,.
A
Okay,
eric
t-
I
see
your
name
on
this.
Would
you
agree
with
that.
F
Yeah,
I
would
think
so,
even
though,
like
it's
very
slim,
so
I
think
we
could
maybe
do
this
in
half
an
hour
optimistically
speaking.
Actually
I
approved
this
just
this
morning,
for
I
said
it
as
ready
for
the
review
just
this
morning.
It's
it's
basically
just
three
methods.
I
don't
know
how.
How
do
people
feel
about
doing
this
today?.
D
D
G
D
But,
to
be
honest,
I
don't
think
the
two
can
be
divorced
like
that,
because
when
we
start
talking
about
things
like
index
and
range,
our
slice
methods
are,
for
instance,
guaranteed
to
return
an
instance
of
the
exact
same
type
that
the
original
disk
parameter
is.
And
how
do
you
do
that
with
things
like
I
enumerable.
D
So
when
you,
when
you
slice
an
array
or
a
string
or
a
span
or
a
memory
or
something
like
that,
we
return
back
to
you
a
concrete
span
or
string
or
memory
or
something
doing
that
on
an
interface
is
a
bit
weird,
because
we
don't
actually
have
a
guarantee
that
we
can
even
create
the
type
that
the
original
this
brand
was
so
already.
We
would
be
violating
one
thing:
what
one
facet
of
what
we
said.
D
We
want
our
site
apis
to
look
like
so
that
that's
why
I
think,
like
our,
we
can't
really
divorce
the
api
review
from
the
actual
implementation
of
the
method.
They
have
to
be.
F
Talked
about
sure
yeah
for
what
it's
worth.
The
original
poster
has
actually
provided
implementations
which
I've
taken
a
look
at,
and
they
seem
reasonable.
The
core
idea
there
being
that
it's
basically
using
the
exact
same
for
your
question.
It
uses
the
exact
same
semantics
as
take
and
skip
so
that.
F
D
F
Do
that
without
solving
the
halting
problem?
Well,
I
I
mean,
if
you
can
actually
click
at
the
implementation,
it
will
show
you
how
it's
done,
but
it's
it's
doable.
D
You're
concerned
about
source,
one
dot
element,
the
very
first
thing
that
they
have
here:
source
one
dot
element
at
index
full
and
carat
five.
D
Don't
we
already
have
that
with
take
last
yes,
but
you
could
t
take
last,
like
the
the
name
explicitly
says,
I'm
going
to
you
know
enumerate
the
entire
thing,
whereas
element
at
doesn't
necessarily
imply
that,
like,
if
I
do
element
at
index
colon
carrot,
1
billion
like
do.
I
reasonably
expect
to
enumerate
every
single
element
from
the
underlying
enumerable,
like
I'm
enumerating
one
billion
elements
that
I
know
I'm
just
going
to
throw
at
the
end.
C
Today,
if
you
do
element
at
50
000,
it's
and
you're
you've,
given
it
a
non,
I
I
collection
it's
going
to
iterate
through
50
000..
It
is.
D
E
I
I
think
the
concern
here
is
when
you're,
when
you're
taking
it
from
the
front,
you
just
have
to
iterate
and
throw
away
up
to
index,
but
if
you're
taking
from
the
rear,
you
actually
have
to
get
the
count
first
and
then
get
the
index
from
the
end
of
that
count.
So
you
actually
have
to
potentially
iterate
the
entire
numerable,
regardless.
F
Well,
the
the
design
here
basically
talks
about
iterating
the
annual
once,
but
that
necessarily
implies
if
you're
taking,
if
you're,
taking
the
element
that
card
five.
For
example,
it
means
having
to
store
at
least
five
elements
in
a
queue.
So,
if
you
do
like
carrot,
you
know
the
entire
size
of
the
enumerable.
It
basically
means
that
you
would
have
to
store
every
single
element
of
that.
A
H
A
Awesome
all
right
so
you're
up
first
levi
with
rng
crypto
service
provider,.
D
Yeah,
so
no
one
should
be
using
this
type.
Everyone
should
be
using
the
static
apis
that
we
put
on
the
base
classes
done.
That
said,
there
is
a.
D
There
is
one
potential
scenario
that
I
could
see
where
someone
might
want
to
keep
using
this
type,
and
that
is
for
unit
testing
purposes.
Their
own
code
takes
the
abstract
base
class
as
a
parameter
and
during
unit
tests
they
mock
it
out
and
in
the
actual
implementation
of
their
application.
They
pass.
You
know
the
concrete
rng
crypto
service
provider,
but
again,
like
everyone,
should
just
be
using
the
static
methods
on
the
base
type.
No
one
should
be
using
the
instance
methods.
A
B
A
D
I
I
don't
think
I
don't
think
artwork
respects
that
to
be
honest,
but
let
me
let
me
double
check
that.
A
D
Yeah
because
it's
the
rng
crypto
service
provider
type,
is
a
dumb
wrapper
around
an
implementation,
and
the
implementation
takes
no
such
parameter
across
aws.
G
D
Well,
this
would
forward
to
them
anyway,
but
really
what
we're
trying
to
do
is
we're
we're
trying
to
simplify
the
api
structure
and
say
like
this.
This
whole
complexity
that
used
to
exist
regarding,
like
oh,
read,
the
documentation
on
whether
this
is
type
say.
Oh
you
know
now
you
have
to
remember
to
dispose
this
and
then
you're
finished
with
it
blah
blah
blah
like
no
just
ignore.
All
of
that
just
call
the
static.
Give
me
a
random
data
method
and
you
know
go
on
with
your
life,
so
we
introduce.
G
New
apis,
we
think
they're
clearly
better
and
handle
all
the
cases
that
the
old
one
did,
except
maybe
for
the
fact
that
they
don't
implement
the
same
abstraction
like
you
mentioned
earlier,
but
let's
ignore
that
for
now,
and
so
we
just
want
to
tell
people
don't
use
this
use
the
new
one,
it's
easier,
it
does
the
same
thing
basically,
but
it
does
it.
Does
it
a
lot
with
a
much
cleaner
and
simpler
understand?
Api,
yes,
great
makes
sense.
A
Yeah,
the
recommended
is
just
to
call
randomnumbergenerator.fill
and
fill
your
your
buffer,
and
if
you
do
need
an
instance
because
you're
doing
mocking,
then
you
can
call
randomnumbergenerator.create
and
it'll.
Give
you
the
the
system,
r
g,
you
shouldn't,
you,
don't
need
to
care
that
it
came
from
windows
cappy,
because
it.
A
D
D
I
would
probably
change
the
message
that's
listed
in
the
issue
here
and
just
just
provide
examples
of
like.
Oh,
if
you're
using
the
instance,
get
bytes
api
use
the
static
one.
Instead
and
just
like
link
two
update
samples
or
something.
B
A
A
So
we
have
the
class
hierarchy
of
type
called
rheindol.
Reindoll
was
the
algorithm
that
now
is
known
as
aes
aes
has
more
restrictions
than
the
full
algorithm
did
in
core.
We
don't
actually
support
the
full
render
algorithm.
It's
just
a
wrapper
over
aes
and
we've
had
at
least
one
bug
caused
by
the
fact
that
we
don't
think
about
this
hierarchy
anymore,
because
it's
just
a
wrapper
over
aes,
but
we
had
forgotten
to
overwrite
a
property
to
to
forward
to
the
implementation
and
well
it
turns
out.
A
A
A
G
H
Minor
suggestion
should
we
be
recording
this
for
most
benefit.
Well,
it's
it's.
A
A
So
for
aes
we
have
the
aes
dot,
create
static
method
which
returns
a
non-public
type,
but
we
have
the
public
type,
a
as
crypto
service
provider
in
aes
managed,
both
of
which
just
wrap
instances
of
aes.create
or
themselves
just
use
the
same
code
but
like
aes
manage
is
not
managed.
Aes
crypto
service
provider
does
not
use
windows
cappy,
and
the
same
thing
is
true
for
everything
here
in
this
list.
D
So
this
this
one
is
a
little
interesting
compared
to
previous
proposals,
because
these
types
actually
are
used
significantly
throughout
full
framework,
just
because
people
out,
of
course,
haven't
used
them.
So,
if
they're,
if
they're
copying
their
full
framework
code
into
a
core
clr
app,
then
it
would
still
compile
with
eb
never
but
going
forward.
It
will
no
longer.
A
Yeah
yeah
for
the
you
know
new
expressions.
It's
easy
enough
to
replace
them
with
the
right
answer.
A
It
may
require
more
work
than
I've
had
to
do,
because
if
it's
a
you
know
variable
declaration,
then
you'd
have
to
go
change.
The
variable
you
may
have
to
change
the
variable
target
type,
and
you
know
it
may
be
that
they
had
a
method
that
took
a
shaw,
384
crypto
service
provider
when
they
really
just
meant
hash,
algorithm
yeah.
So
it's
it's
not
a
it's,
not
a
100
foolproof.
A
We
can
write
a
a
replacer
analyzer,
but
it
is
a
very
mechanical
change.
It
is
yeah.
D
A
Ryandoll
one
is,
if
you
change
the
block
size,
it's
we
don't
support
that
which
you
would
have
gotten
from
the
pnse,
but
yeah,
and
now
it's
like
hey
by
the
way
this
algorithm
is
called
aes.
You
can't
see
it
in
the
type
hierarchy,
but
use
a
yes,
and
these
are.
You
went
to
specific
pop
up
a
level.
D
Yeah,
if
we
do
off
solutions
like
this,
I
would
prefer
for
us
to
front
load
them
in
an
early
preview.
Just
so
we
can
see
how
painful
they
are,
because
I
I
would
think
that
if
we
provide
good
guidance
on
this
like
it
literally
would
be
a
you
know,
search
and
replace
for
most
people.
D
A
A
Sha-1
cng
does
not,
because
it
wasn't
part
of
net
standard
2o
that
whole
assembly
just
is
pnse
on
unix
sha-1
csp
does
because
it
was
part
of
netstandard.
J
A
Right,
like
all
the
kaz
types
yeah,
if
you
try
to
make
them,
do
work
it's
because
we
we
don't
support
the
feature
of
kaz
in.net
core,
and
I'm
aware
we
call
it.
D
Good
differentiator:
this
is
what
you
were
mentioning
earlier,
though
right,
where
we
had
a
feature
that
simply
doesn't
exist
right,
and
we
presumably
don't
want
this
analyzer
rule
to
kick
in
correct
in
those
scenarios.
D
I
I
would
probably
say
if
a
method
unconditionally
throws
at
the
nsc
like
that
method
should
probably
be
mark
obsolete
or
something
rather
than
unsupported,
on
a
specific
os
competition,
because
these
attributes
that
we're
discussing
here
are
conditional
right.
C
Analyzer
doesn't
need
to
be
specific
to
these
attributes.
Basically,
it's
saying
there's
something
that
throws
platform
not
supported
and
the
method
is
unadorned.
So,
what's
going
on,
do
something
whether
that's
attribute
you
know
unsupported
os
platform
or
attribute
obsolete.
That's
the
developer's
call.
Okay,
that
makes
sense.
D
A
Yeah,
that
seems
fair,
that
it
would
warn
if
there's
no
unsupported
os
supported
os
or
obsolete.
D
D
They
also
have
things
like
if,
if
like
ad
advanced
cindy,
isn't
supported
through
a
new
pnsc,
but
presumably
the
caller
has
checked
is
supported
before
calling
it
and
that's
not
really
an
os
check.
It's
a
capability
check.
C
A
B
C
Assemblies
don't
play
don't
factor
into
this
at
all.
This
is
purely
looking
at
implementation
to
say:
does
a
method
always
throw
platform,
not
exported
exception
and
doesn't
have
an
attribute
on
it?
If,
yes,
if,
if
it
throws,
it,
doesn't
have
an
attribute
warrant
yeah
during
these
during
compilation
during
compilation.
C
B
B
C
Yeah
now
that
said,
your
your
question
is
valid
like
if
we
believe
that
you
know,
maybe
it
would
be
useful
to
other
people,
but
really
we're
focused
on
ourselves
and
bootstrapping
ourselves.
We
can
add
whatever
you
know,
whatever
analyzers,
we
want
into
a
net
runtime
specific
analyzer
and
then
see
how
useful
it
is
and
consider
exposing
it
in
the
future.
It
doesn't.
You
know
we
can
have
things
that
are
private
to
the
runtime,
because
the
99.999
percent
case
is
done
in
runtime.
A
Okay,
so
like
on
on
jeff's
notes,
slash
interpretation
questions.
A
C
B
L
And
we
do
not
have
a
way
to
annotate
conditional
platform,
unsupported
platform,
yet
so
correct,
yeah.
C
L
C
L
I'm
pretty
sure
we've
already
found
all
of
the
all
the
cases
of
if
the
entire
method
body
is
through
pnse,
I
think
the
tooling
we
did
that
helped
us
create
the
list
of
where
to
decorate
attributes.
You
know
found
those,
so
this
really
was
for
for
merrick's
cases,
those
more
nuanced
places
where
the
etheropian
sc
wasn't
as
obvious,
but
as
you're
saying
since
we
don't
have
a
good
way
to
decorate
conditional
support.
L
A
Okay,
so
is
that
that
we're
saying
no
at
this
time
that
it
doesn't
seem
to
have
value,
particularly
as
a
as
a
public.
C
Thing,
I
don't
think
it
has
value
publicly
right
now
and
if
someone
believes
it
has
value
internally,
anyone
can
go
and
do
it.
L
A
All
right,
because
we
don't
currently
have
the
ability
to
mark
things
as
os
specific
based
on
parameter
input,
can
only
be
reliable
for
methods
that
are
entirely
throw
a
new
platform,
not
supported
exception.
As
such,
we
don't
think
there's
sufficient
value
in
it
at
this
time
when
it
is
possible
to
do
something
more
complicated.
The
analyzer
should
not
warn
if
the
method
is
declared
obsolete.
In
addition
to
the
os
based
attributes
did
that
cover
it.
A
A
B
A
C
We
have
thread.start,
which,
like
all
good.net
methods
that
you
work
to
run
on
some
other
thread,
captures
the
execution
context
and
flows
it
across.
We
have
a
pattern
methods
like
thread,
pool
cues
or
work
item
where
you
slap
it
unsafe
in
front
of
it,
and
that
means
don't
don't
flow.
The
execution
context
we
now
have
such
an
unsafe
start
or
two
overloads
of
unsafe
start
internally
on
thread,
and
the
proposal
here
is
to
just
make
them
public.
C
What's
the
actual
benefit,
the
the
main
benefit
is
the
thread.
That's
created
doesn't
end
up
rooting
whatever
was
in
execution
context
for
the
lifetime
of
the
thread.
C
So
if
you
had
some
state
in
execution
context
in
an
async
local
and
you
spawned
a
thread,
for
example,
with
the
portable
thread
pool
now,
which
is
now
def
by
on
by
default,
if
we,
if
you're
doing
something
that
causes
a
new
worker
thread
to
be
created,
because
we're
now
calling,
we
were
calling
thread
dot
start
anything
in
an
async.
Local
would
then
be
captured
by
that
thread.
C
For
the
duration
of
that
thread,
living
in
the
thread
pool
so
by
using
unsafe
start,
it
prevents
that
I
mean
that
seems
like
a
bug
in
the
threat.
Implementation.
G
G
C
Context
yourself
right,
the
workaround
is
for
all
these
cases
is
to
call
if
not
executioncontext.isflowsuppressed,
executioncontext.suppressflow
and
store,
whether
you
suppressed
it
into
a
boolean.
Then
called
the
function
you
care
about,
and
then
after
you
call
the
function
say
if
boolean
equals
true
execution
context,
dot,
restore
flow.
D
C
It
makes
it
safe.
The
unsafe
naming
is
historical
because
execution
context
used
to
flow
all
of
kaz
and,
like
all
the
cas
information-
and
you
know,
impersonation
information
and
everything
to
do
with
security.
And.Net
was
floating
execution
context.
Now
it
literally
just
flows,
async
local,
now,
certain
things
in
a
sense,
there's
still
aspects
of
security,
because
things
like
windows,
identity
now
store
the
impersonation
information
in
and
async
local.
So
you
can
kind
of
squint
at
it
and
say
it's
still
a
safety
thing.
C
I
think
the
only
question
with
one
that
gspp
raised,
which
is
you
know
we
have-
we
have
two
overloads
of
thread.start,
one
that's
parameter
list
and
one
that
takes
an
object,
parameter
he's
wondering
whether,
and
so
the
proposal
was
to
do
the
exact
same
thing
for
unsafe
start
he's
just
asking
whether
we
would
want
to
consolidate
them
into
a
single
overload
with
a
nullable
with
a
null
defaulting
parameter,
and
this
is
just
really
what's
our
guidance
on
this
sort
of
thing
moving
forward
rather
than
you
know,
there's
no
performance
issue
here,
it's
just
a
question
of
what
we
want
our
apis
to
look
like.
A
I
think
that
it
one
parameter
and
we
don't
expect
future
overloads.
That
default
is
the
way
that
we
would
go
and
that
we
would
only
split
it
if
there
was
a
you
know,
a
perf
reason
if
it
gets
to
avoid
a
bunch
of
conditional
code
that
you're
arguing
is
important.
C
A
Because
null
is
the
only
thing
we
could
pass,
we
understand
how
we
would
make
the
future
overloads.
We
don't
expect
to
make
future
overloads,
so
we
don't
think
that
going
from
only
one
method
in
the
method
group
to
more
than
one
is
going
to
be
complicated,
so
it
seems
like
a
good
candidate
for
default.
To
me,
the
only
reason
not
to
do
it
would
be.
A
C
C
A
J
E
Looks
like
he's
not
here,
okay,
so
so.
Basically,
a
long-standing
issue
is
that
on
windows,
for
this
call-
or
that
is
for
c
plus
instance
members,
you
can
actually
add
an
additional
calling
convention
which
modifies
how
how
the
abi
works
in
particular,
it
impacts.
Struct
returns
in
that
simple
struct
wrappers
are
not
treated
as
simple
wrappers
they're,
actually
treated
as
structs,
and
have
to
be
returned
via
a
hidden
out
parameter.
E
This
is
just
proposing.
We
expose
a
new
call,
conf
member
that
can
be
used
with
function.
Pointers
to
clearly
indicate
that
this
is
a
member
function
and
therefore
the
jit
can
do
the
right
thing.
A
Okay,
I
am
a
little
confused
about
because
the
proposed
api
uses
the
words,
call
conf
member
function
and
then
sample
usage
does
not
so.
E
So
the
way
this
c
sharp
compiler
works
is
it
looks
in
the
the
assembly
that
contains
system
object
and
contains
and
has
no
dependencies
in
the
system.
Runtime
compiler
services
namespace
for
any
members.
That
start
with
the
name
call
conf,
so
call
cons,
stid
call
call
con,
cdecl,
okay,
etc.
B
E
This
case
you
say,
stand
call
member
function.
This
is
the
same
as
the
suppress
gc
transition.
Member
that
we
approved
a
few
weeks
ago.
H
E
A
A
E
It
it
doesn't
have
an
explicit
the
closest
thing.
Is
this
call?
But
it's
actually
not
this
call
it's
a
instance,
member
with
a
separate
calling
convention
and
both
jeremy
and
aaron
indicated
they
did
not
want
to
reuse.
This
call
because
of
this
also
because
they
want
this
to
explicitly
be
a
modifier
rather
than
interpreted
as
a
proper
calling
convention
itself.
E
A
Yeah,
but
my
only
concern
with
it
is
that
being
sort
of
you
know
vagus,
is
that
if
we
start
supporting
native
calls
to
libraries
built
with
mumble
mumble
language,
that
you
know,
we
have
member
function,
which
meant
c
plus
conventions
and
something
else.
But
if
we
can
tell
that
from
the
the
other
call
conv
and
it's
a
modifier
to
that
qualcomm,
then
I
guess
that
makes
sense.
E
Right
and
as
far
as
most
abis
are
concerned,
it's
while
they're
built
around
c
and
c
plus
plus
respectively.
They
aren't
strictly
tied
to
that.
So,
for
example,
the
what
linux
uses
is
known
as
the
titanium
abi
for
c
plus
plus,
but
it's
actually
just
the
general
abi
meant,
for
instance,
members
and
stuff
for
any
compatible
language.
E
D
D
Do
you
know
if,
if
jeremy
and
others
are
are
lined
up
to
do
this
work
once
the
api
is
approved
because
there
there's,
like
actual
runtime
implementation
right,
it's
not
just
an
api.
E
Right,
I
believe
that
they're
lined
up,
they
already
went,
they
already
implemented
suppressed
gc
transition,
for
example,
perfect
that
we
approved
it
like
a
month
ago.
D
So
I
I
understand
the
scenario
for
this:
the
right
right
now,
when
you
define
a
safe
handle
derived
type.
The
way
that
the
interrupt
feature
in
the
runtime
works
is
sorry.
The
convention
is
that
you
don't
provide
a
public
constructor
for
it.
You
provide
a
protected
instructor,
primarily
and
then
there's
a
non-public
set
handle
method
which
is
implemented
on
the
base
type.
I
believe
that
that's
protected
anyway,
when
you
call
a
invoke
method.
D
The
interop
layer,
if
it's
constructing
a
safe
handle
on
the
return,
will
use
private
reflection
to
call
the
safe
handle
constructor
that
basically,
that
scaffolds
the
safe
handle
type
itself
and
then
we'll
again
use
private
reflection
to
call
the
set
handle
method
in
order
to
say
here's,
the
actual
value
of
the
save
panel.
D
A
Any
of
the
places
that
a
safe
handle
is
exposed.
You
now
just
call
set,
handle
and
change
the
value
of
what
it's
tracking
and
it's
gone
from
a
a
type
that
is
basically
a
a
gc
tracked
wrapper
to
it's.
A
gc
tracked
wrapper
that
you
can
change
the
value
in
I
mean
I
guess
you
could
have
always
done
that
with
private
reflection,
but
adding
the
public
api
just
feels
dirty.
D
A
To
call
that's
what
the
one
on
the
instance
member
on
safe
handle,
what
it
does
it's
just.
I
don't
even
know
why
it
exists,
because
the
handle
field
is
protected
and
all
it
does
is
set
the
handle
field.
A
C
A
A
Yeah,
it
just
feels
too
weird
to
me
to
be
exposing
it.
I
think
a
much
better
guidance
would
be
that
we
have
constructors
that
take
int
pitter
on
all
of
our
safe
handle
types,
and
you
just
construct
it
to
what
you
want
it
to
be.
A
C
P
invokes
such
that,
if
you
were
hit
in
you,
don't
have
to
incur
that
after
you've,
already
called
the
native
method
and
gotten
back
your
end
pointer
that
needs
to
be
protected
so
set
handle
is
just
setting
a
field,
because
that
won't
fail.
B
J
C
And
the
source
generator
emits
the
equivalent
of
the
stub
that
the
the
interrupt
stub
that
the
runtime
would
have
generated
for
me
at
runtime.
M
A
He's
right,
yeah
yeah,
once
you
mention
it,
makes
sense,
it's
that
you're
supposed
to
create
the
instance
so
that
you're
guaranteed
to
have
the
ability
to
track.
It
then
do
the
work
then
do
the
os
call
and
then
link
it
back
up
yeah.
I
like
it
better
on
marshall,
honestly,
like
I
don't
like
having.
M
A
It
may
be
fine
to
say
that
we,
that
our
guidance
is
all
safe
handles,
should
have
a
default
constructor.
Okay,
like
I'm,
that's
fine
as
a
guidance
formula.
I
have
no
objection
there.
It's
just
should
set
handle,
be
the
public
member
on
the
handle,
which
means
that
we're
now
exposing
to
anybody
that
we
return
one
of
these
instances
to
a
way
to
mutate
the
value
without
reflection,
that's
in
their
face,
or
do
we
put
it
on
marshall,
which
is
you're
going
out
of
your
way
and
you're
messing
with
the
system
and
have
fun?
A
D
There
are,
there
is
precedent
for
having
dangerous
apis
on
safe
handle
and
they're
actually
annotated
with
the
dangerous
prefix
it
allows
manual
recounting
of
safe
handle
instances
there
is
dangerous,
get
handle,
you
could
have
dangerous
set
handle.
I
mean
it's
it's
a
bit
weird
because
in
this
particular
case,
well
with
the
existing
dangerous
methods,
dangerous
really
means
you're
responsible
for
ref,
counting
like
please
don't
get
it
wrong,
whereas
if
we
have
dangerous
set
handle
it's
something
beyond
recounting.
It's
also
saying
like
you
could
potentially
corrupt
the
instant
state
of
the
handle
itself.
Well,.
A
M
So
I'm
not
I'm
absolutely
not
I'm
absolutely
for
that
as
well.
I
preferred
the
api
approach
as
opposed
to
exposing
things
primarily
because
it
will.
It
will
permit
existing
code
to
just
opt
in
that
was.
That
was
the
idea
there
would
be.
No,
there
would
be
literally
no
change
everybody's
safe
handles
that
currently
exist
would
just
work.
M
D
Yeah
the
reason
I
brought
it
up
is
just
if
we
decide
to
make
it
an
instance
method
on
safehandle.
I
would
probably
prefer
the
dangerous
prefix
if
it's
public,
as
opposed
to.
M
M
Gotcha
it's
this,
so
is
there
a
strong
opinion
on
that?
Like
I
I
do.
I
do
prefer
for
all
the
reasons
that
I
think
jeremy
mentioned
and
I
I
think
levi
you're
kind
of
in
the
same
realm.
I
prefer
it
being
on
the
marshall
class
because
it
does
explicitly
mean,
like
you're
you're,
doing
something
very
specific
for
a
very
clear
reason
and
it's
related
to
marshalling
you're,
not
just
using
it
yeah.
A
I
also
like
your
comment,
aaron,
that
if
we
do
it
as
marshall.createsafehandle
of
eventually
there's
a
t
in
here
somewhere
yeah
there,
we
go
that
that
it
means
that
this
pattern
works
for
all
types
and
we
don't
have
the
go
retrofit
our
current
ones
that
wouldn't
don't
have
a
default
constructor
and
put
out
guidance
of
hey
by
the
way
for
your
safe
handle
to
play
nicely
with
source
generators.
You
need
to
do
this
thing.
It's
like
well,
here,
marshall
will
do
the
thing
that
the
runtime
was
already
doing
and.
M
We
could-
and
this
was
brought
up-
I
I
don't
know
exactly
where,
but
this
was
brought
up
on
another
thread
about
the
source.
Generator
could
actually
detect
that
case
and
special
case
it
and
just
emit
the
reflection
call
in
the
source
generator
when
we
like
are
interrogating
the
type
and
saying
oh,
it
doesn't
have
a
open,
it
doesn't
have
a
public
constructor
we'll
we
can
just
replace
the
new
instantiation
with
customized
code
that
just
activates
it,
because
it
knows
that
it
does
have
a
private
constructor.
M
M
I
know
we're
trying
to
get
away
from
reflection
in
some
of
these
lower
level
apis
because
of
the
linker
concerns.
So
I
I
really
do
appreciate
the
compromise
like
yeah.
Let's
update
guidance,
tell
everybody
the
thing
and
add
this
new
api,
but
there
is
the
it
is
going
to
be
a
larger
pr
when
we
update
all
of
our
existing
handles
and
say
they're
all
public
now,
just
so
that
we
can
participate
in
this.
So
there
are
a
couple
of.
A
Yeah,
I
think
it's
so
I
think
I'm
suggesting
that's
fun.
I
think
I'm
suggesting
approve
the
api
for
the
alternative
design
and
endorse
the
notion
that
we
change
our
guidance,
that
safe
handle
type
should
have
a
default
constructor.
That
represents
an
invalid
instance.
C
B
M
That
and
that
way
we
keep,
I
guess
the
argument
here
is
we
keep
the
safe
handle
clearly
and
clean.
We
don't
have
this
weird
set,
handle
that's
absurd
and
that
can
really
get
you
in
trouble,
which
I
think
levi's
point
is
fair.
If
we
would
to
expose
that
it
really
needs
a
dangerous
prefix,
because
you're
doing
something
wonky
and
we
can
leave
the
set
handle,
as
is,
I
think,
yeah
the
name.
B
C
So
the
problem
is
like
one
of
the
reasons
safe
handle
was
originally
introduced
was
to
minimize
the
chances
that
you
could
make
a
native
call
get
back
a
handle
and
then
something
goes
wrong
and
that
handle
is
leaked
and
so
with
safe
handle.
The
idea
is
you
construct
it
before
you
actually
make
the
native
call
that
creates
the
handle
you
want
to
wrap
in
case
you
were
in,
you
know,
a
low
memory
situation,
so
you
because.
C
You
make
the
native
call,
you
get
that
pointer,
then
you
go
to
allocate
the
safe
handle
and
it
ooms
and
now
you've
got
a
leaked
handle.
So
you
allocate
safe
handle
first,
if
it
ooms
you,
you
you've
not
yet
made
the
native
call.
Then
you
make
the
native
call.
You
get
back
the
pointer
and
then
storing
it
into
the
safe
handle
is
just
assigning
a
field
which
won't
fail.
G
C
G
The
new
marshall.set
handle,
in
other
words
it's
not
so
much
marshall.set
handle
which
lets
you
set
it
any
arbitrary
time
you
want
and
get
yourself
into
all
kinds
of
trouble.
It's
like
marshall.init
handle
and
it's
defined
to
only
work
on
a
handle
that
has
been
constructed
using
the
default
constructor.
D
A
Yeah
you
need
that
the
way
of
so
it
could
be
that
the
one
on
marshall
only
works
if
safe
handle
that
is
invalid
is
true.
A
C
I
do
wonder
if
we're
making
this
more
complicated
than
it
needs
to
be
we're
already.
In
the
marshall
class
which
lets
you
read
and
write
arbitrary
memory,
and
this
code
is
going
to
be
on
the
fast
path
of
every
ep
invoke
throughout
the
entire
system.
Once
we
have
our
way
in
source
generators
used
everywhere,
I
wonder
if
we
really
want
to
incur
the
cost
of
checking
whatever
and
then
you
know
throwing
an
exception
and
blah
blah
blah.
G
C
G
We
don't
want
to
introduce
any
additional
proof
overhead.
This
absolutely
is
critical,
so
any
kind
of
validation
that
we're
not
doing
today
is
probably
a
non-starter.
I
just
worry
a
little
bit
that
once
we
once
we
expose
a
thing
called
set,
handle
somebody's
gonna,
use
it
and
then
they're
gonna
go.
Why
didn't
this
work?
And
we'll
say
you
called
a
thing
on
marshall.
D
G
D
C
G
M
G
C
Can
we
go
back
to
the
create
whatever
method
for
a
second,
so
john
had
proposed?
Not
adding
that
and
he
had
written.
C
M
Yeah,
absolutely
that's
what
I
was
getting
at
like
we.
Could
we
can't
just
throw
that
that
line,
that
code
is
put
up
right.
M
M
M
M
C
C
C
M
Right,
I'm
sorry,
I
didn't
follow
that
say
that.
C
M
D
A
Yeah
my
concern
or
thinking
of
why
we
would
add
the
method
is
because
for
not
a
source
generator
that
we're
working
on,
but
anybody
else
doing
a
similar
source
generator
that
the
if
the
amount
of
reflection
was
tricky.
A
But
if
it's
just
activator
create
instance,
then
the
only
other
argument
would
be
to
force
it
to
have
a
by
being
a
generic
method,
you're
forced
to
have
a
concrete
type,
or
at
least
a
composable,
concrete
type,
as
opposed
to
activator,
create
instance,
which
could
use
a
a
very
or
a
variable
of
type
type.
D
Yeah-
and
we
have-
we
have
other
tricks
that
we
can
pull
if
the
source
generator
ends
up,
producing
slow
code
like
we
can,
we
can
fix
that
up
in
post-production.
C
Yeah,
I
think
the
argument
would
be
that
our
guidance
is
you
have
a
public
instructor,
so
this
won't
matter
all
of
our
types
which
represent
the
99
case
for
safe
or
90
case.
Whatever
will
have
a
public
constructor,
so
it
won't
matter,
and
so
the
slightly
slower
construction
code
will
only
impact
code
until
it
updates
to
where
they're,
using
a
custom,
safe,
handle
and
they've
not
yet
updated
to
follow
the
guidance
and
then
all
of
your
optimizations
activator,
create
instance
levi
kick
in,
and
it's
really
no
worse
anyway.
I
M
Okay,
so
it
looks
like
the
consensus
here
would
be.
We
update,
we
update
guidance,
special
case,
the
source
generator
with
yan's
proposal,
and
if
we
detect
that
there
is
no
public
default,
and
then
we
create
a
new
api
on
marshall
init
handle
and
make
some
very
mean
comments
about.
Don't
use
this
unless
you
know
what
you're
doing
and.
C
D
E
E
How
do
they
do
that
in
a
safe
way,
disposing
it
properly.
A
Yeah,
as
long
as
you
have
the
the
safe
handle
object
in
a
using
everything's
fine.
E
Well,
most
of
the
times
you
don't
have
a
using
that's
possible,
like
you'll,
have
a
native
window,
which
is
wrapped
by
form
or
control,
which
itself
has
an
underlying
in
which
tracks
the
end
pointer
and
is
disposable,
and
you
make
sure
it's
disposed
of
via
the
finalizer.
Normal
dispose
pattern.
D
Right
so
it
if
you're,
bypassing
like
the
point
of
safe
handle,
is
to
make
the
invokes.
You
know
somewhat
easier
for
everyone
to
write
right
if
you're.
If
you
want
to
bypass
them,
then
you
know
that's
on
you
to
make
sure
that
you're
handling
lifeline
correctly,
which
is
fine
right
if
you're,
if
you're,
creating
a
very
high
performance
library-
and
you
have
the
technical
skill
to
be
able
to
do
this,
like.
A
And
that's
what
the
public
dangerous
ad
ref
and
dangerous
releaser
for
is.
If
you
can't
put
the
object
in
it
using
then
you
can
dangerous
address
finally
dangerous
release,
and
now
you
can
use
dangerous
git
handle
in
the
middle
for
as
many
calls
as
you
want.
Yeah.
C
I
was
just
looking
at
source.net.
It
looks
like
across
the
various.net
repos
tracked
by
source.net.
There's
about
200
types
derived
from
either
safe
handle
safe
handled,
minus
one
is
invalid
or
safe
handle
zero.
Minus
one
is
invalid
and
they're.
You
know
sprinkled
across
the
various
repos
there's
a
couple
in
windows
forms
there's
a
bunch
in
wpf
there's
some
in
asp.net
there's
some
in
runtime
et
cetera,
yeah.
C
G
A
D
A
G
C
M
D
It
is,
in
fact,
a
special
case
by
interrupt.
Oh,
is
it
I
o
martial
arts,
dot
cpp.
M
A
A
M
M
M
C
I
think
it
should
in
particular,
if
I
I
don't,
I
can't
speak
to
I've,
not
looked
to
see
what
the
cost
is
today.
You
know
this
better
than
I
would
aaron
of
creating
the
safe
handle
in
the
run
time
today,
but
I'm
assuming
that,
no
matter
how
fast
levi
has
made
activator
create
instance
that
whatever
we're
doing
in
the
runtime
today
is
faster.
B
M
M
What
it's
doing
like
I'd
have
to
look
at
what
it's
doing
specifically
inside
of
the
generated
martial
arts.
I
don't
know
the
reason.
C
C
Anyone
who
any
repo
that
we
switch
over
well
any
safe
handles
that
are
public,
that
we
expect
will
be
used
by
customers
in
their
own
p-invokes
or
any
safe,
handles
that
are
used
in
our
own
repos,
with
our
own
p
invokes
where
we
expect
those
p
invokes
to
switch
to
using
source
generators.
C
We
should
make
sure
that
the
new
source
generator
solution
is
as
fast
or
faster
than
what
they're
currently
using,
and
that,
if
sorry,
it's
a
long
stream
of
ifs,
but
if
how
these
are
created
in
the
new
way,
with
reflection,
activator,
create
instance
or
create
factory,
is
slower
than
what
the
runtime
is
doing
today.
M
Okay,
that's
fair,
so
the
plant
for
the
source
generator
just
for
right
now.
There's
two
steps
to
this,
because
this
is
a
very
large
mechanism.
What
we're
basically
doing
is
first
pass
on
our
source.
Generator
will
be
for
only
for
net
core
app.
That
is
all
that
is
going
to
be
applied,
and
that
is
likely
the
extent
of
net
six.
M
Consumable
in
a
supported
way
publicly,
that
is
the
plan
we
may
make
it
support.
We
make
it,
we
may
make
it.
You
can
use
it,
but
you're
going
to
have
to
inject
all
the
types
manually
like
if
you
just
want
to
have
the
code
generated,
that's
possible,
but
we're
not
putting
it
into
the
box.
We're
not
really
evangelizing
it.
M
G
C
I
just
wanna
just
before
we
go
into
the
next
thing.
I
just
wanna
I'd
love
to
comment
on
the
issue,
but
for
the
thread
start
one
or
thread
on
safe
start.
I
was
just
looking
at
it
and
I
realized
we
need
to
uncombine
them
and
I,
like
I
left
a
comment
to
that
effect
because
there's
some
semantic
differences
between
start
that
takes
a
parameter
and
start
that
doesn't,
in
particular,
around
error
handling.
I
Yeah,
I
also
wanted
to
say
I
missed
it
when
it
first
came
up,
because
I
did
not
meet
fast
enough,
but
I
could
speak
to
the
logger
message.define
issue.
If
you
guys
want
to
go
over
that.
I
Here
is,
in
you
know,
types
that
use
this
logger.
You
know
microsoft
extension
blogging.
You
can
use
loggermessage.define
to
do
this
very
efficiently.
It
uses
structs
to
wrap
up
arguments
and
so
forth.
To
avoid
allocations-
and
one
thing
it
does
is
it
doesn't
do
the
actual
log
to
logging
providers
if
the
logger
isn't
enabled
at
all.
So
you
know
sometimes
the
logger's
just
turned
off.
In
this
case,
though,
sometimes
we
want
to
skip
the
is
defined
check
in
the
generated
action.
I
That's
returned
from
logger
message.defy,
because
we're
already
doing
and
is
enabled
check
ourselves.
The
example
that
david
gives
is
accessing
like
connection.connectionid,
which
could
like
lazily
allocate
a
string.
If
there's
no
logger
enabled
you'd,
rather
not
do
that.
I
So
we
can
check
before
allocating
the
string,
but
then
we
effectively
check
logger
is
enabled
twice
because
we're
checking
inside
the
generated
action
and
outside
before
we
call
it.
So
this
would
add
an
optional
boolean
parameter,
which
is
skip,
enable
check,
which
would
say,
we've
already
called
as
defined
ourselves
effectively.
A
I
mean,
I
guess
another
reason
you
may
want
to
skip.
It
is
so
you
can
save
it
as
a
field
because
they
can
theoretically
get
active
or
turned
on
later,
or
is
that
not
a
thing
yeah?
No,
it
can
yeah,
it
can
be
turned
on
as
the
process
is
running.
So
if
you're
saving
it
as
a
static
read-only,
you
would
almost
always
want
to
say
skip
enable
check.
N
I
Case
it's
kind
of
hidden,
it
could
probably
be
more
explicit
but
connection
dot.
Connection
id
is
doing
some
expensive
operations.
So
if.
N
I
Right
exactly
so,
it
is
virtual
and
it's
something
that
can
be
called
very
frequently
like.
If
you
have
asp.net
like
or
microsoft
extensions.
The
bug
log
enabled
you,
you
know
many
logs
per
request
and
you
can
do
you
know
a
lot
of
requests
per
second.
I
I
N
Yeah,
I
mean
the
only
reason
I'm
asking
is
because
oh
it
looks
fairly
involved
to
call
the
api.
Like
I
said
it's
relatively
messy,
but
I
guess
you
you
do
it
once
somewhere
right
and
then
basically
all
the
times
when
you
actually
call
it,
you
go
through
whatever
delegate
that
get
returned
right.
So
the
call
sets
are
always
moderately
clean.
I
Right
yeah,
so
these
delegates
are
created
once
per
process.
N
I
don't
think
so
they
are
literally
just
like
because
basically
it
returns
the
delegate
right
in
that
long
just
takes
those.
I
A
A
Did
any
of
the
defines
use
any
of
the
t's
in
the
signature,
or
is
it
just.
H
A
E
Yes,
so
there's
a
set
of
bath
functions
that
are
recommended
by
the
ieee
spec
that
are
exposed
in
most
other
languages,
including
java,
rust,
go
c
plus
plus
we
actually
expose
these
in
the
mono
android
java
lang
name
space
for
compatibility
there
under
these
names,
but
essentially
the
proposal
is
we
should
be
exposing
these
functions.
E
As
they,
they
are
useful
for
a
number
of
mathematical
scenarios
and
they
help
avoid
precision
and
loss
of
accuracy
when
computing
with
the
inputs,
so
in
particular,
there's
hypot,
which
computes
the
hypotenuse
I
opted
for
the
short
name
just
because
that's
what
we've
done
with
every
other
math
api
exposed
so
far,
such
as
square
root,
cube
root,
sine
cosine,
etc.
E
There's
x,
m1,
which
is
e
to
the
power
of
x,
minus
one
and
its
inverse
log
p,
one
which
is
log
x,
plus
one.
A
E
E
Not
lose
backups
they're
internally
implemented,
so
so,
for
example,
there's
no
hardware
instruction
for
x,
it's
generally
just
a
taylor
or
newton-raphson
implementation.
That
does
enough
iterations
to
be
correct.
That's
the
case
with
all
of
these
functions.
D
So
it
would
be,
it
would
be
potentially
a
little
slower
than
doing
the
naive
x,
squared
plus
y
squared
square
root,
but
it
would
give
you
a
more
accurate
result.
Correct.
E
The
same
reason
why
x
exists
rather
than
just
doing
math.pow,
because
x
is
actually
able
to
use
the
base
as
if
to
infinite
precision,
rather
than
if
you
do
pow,
you
actually
have
to
use
the
rounded
version
of
e.
E
We
would
be
missing
the
cor.
We
are
so
we
already
exposed
log
log,
10
and
log
two
there's
log
plus
one
functions
for
each
of
those.
So
if
we
were
to
have
parity,
we
would
also
be
exposing
log
2,
p1
and
log
10
p1.
E
N
E
There's
so
we
are
likely
not
going
to
move
the
functions
to
managed
code,
it's
possible
that
we
eventually
centralize
on
a
single
native
implementation
for
all
platforms,
but
that's
very
much
up
in
the
air
and
still
needs
further
design,
work
and
discussion.
N
Yeah
I
mean
in
principle:
I
have
zero
problem
with
exposing
additional
math
apis.
My
only
concern
is
that,
because
you
know,
they're
probably
not
trivial,
to
implement
if
we
can
just
call
them
from
the
c
runtime
it's
fine,
but
if
we
have
any
plans
to
remove
the
c
runtime,
then
you
know
any
method.
We
call
becomes
reliability
right
or
any
function.
I
should
say
we
call
becomes
a
liability.
So
unless
that's
the
case,
I
don't
see
an
issue
with
it.
E
Yeah-
and
I
think
even
if
it
was
that
we
eventually
decided
to
port
these,
to
manage
code,
I
imagine
because
of
the
number
of
math
apis
and
because
of
difficulties
and
other
things,
it
would
likely
become
an
iterative
process
sure.
So
I
wouldn't
be
concerned
with
the
number
of
apis
we're
exposing.
D
Given
the
different
runtimes
that
we
compile
against,
do
they
all
return
the
same
result
given
the
same
inputs.
E
No
because
they
all
forwarded
the
c
runtime
and
each
c
runtime
implementation
is
different,
which
we've
had
you
know,
potentially
at
least
tens,
if
not
hundreds
of
bugs
over
the
years
against.
But
it's
an
incredibly
complex
issue
and
I've
got
a
work
item,
4.net
6,
to
write
up
the
proposal
on
how
to
handle
that
and
try
and
drive
it
forward,
but
because
of
the
complexity
of
the
area.
E
Correct
if
we
choose
a
native
implementation
to
centralize
on,
all
of
them
will
already
be
exposing
these
functions,
and
so
it
would
just
be
essentially
changing
from
calling
dc
runtime
to
calling
a
linked
lib
m.
Instead,.
E
A
E
E
E
I
think,
on
the
other
hand
as
well,
the
names
like
squirt
are
often
seen
on
calculators
and
in
mathematical,
notation
they're,
supported
by
things
like
wolfram
alpha,
they're,
fairly
common
names,
just
like
you
use,
cos
not
cosine
right.
E
Yeah,
typically
speaking
like
on
wolfram
alpha,
if
you
do
x
10,
it
interprets
it
as
10
being
the
base
of
the
exponent,
and
you
do
log
two.
The
two
is
generally,
if
you're
doing
proper
mathematical
notation,
it's
the
subscript
right.
N
E
Well,
we're
getting
very
close
to
the
point
where
we've
exposed
all
recommended:
ieee
functions,
the
ones
we're
missing
are
like,
like
I
mentioned
earlier,
x2
and
the
others
for
parity
compound
root
to
an
arbitrary
n
and
then
some
sine
and
cos
and
tangent
overloads
that
deal
with
pi,
because
pi
in
floating
point
is
non-exact
and
these
apis
allow
you
to
interpret
it
as
an
exact
pie.
N
E
A
N
Yeah,
I
think
that's
kind
of
the
thing
I
mean
fundamentally
like
if
we
just
match
the
c
runtime
names.
I
think
it's
trivial,
I
think
as
soon
as
we
try
to
like
improve
the
naming,
then
the
more
we
know
the
easier
that
gets,
but
otherwise
we
end
up
in
a
world
where
we
have
like.
Oh,
we
have
these
semantics,
but
then
you
know
based
on
additional
functionality,
that
you
know
become
inconsistent
or
we
can't
keep
it
up
or
something
so
that
might
be
easier,
but
it
just
matches
the
names.
It
probably
also
doesn't
matter.
A
The
whole
set,
so
I
I
think
that
sounds
like
I
should
mark
this
as
needs
work,
send
it
back
to
tanner,
for
please
give
all
of
the
functions
from
recommended
operations
and
we'll
we'll
give
it
a
quick
go
through
on
the
nod
in
a
later
meeting.
J
N
D
D
E
So
so
the
list
that
I
just
typed
is
the
full
set
that
we
are
missing.
It's
x,
minus
one
x,
two
x,
two
minus
one
x,
ten
x,
ten
minus
one
log,
plus
one
log,
two
plus
one
log,
ten
plus
one
hypotenuse
compound
root,
n
sine
pi
cos,
pi,
tan
pi
and
then
a
sine
pi,
a
cos
pi,
a
tan
pi
and
a
tan
two
pi,
and
they.
N
E
Yeah
for
for
root
in
in
particular,
I
think
that's
the
one
where
we
would
deviate
on
the
name
when
we
exposed
log,
for
example,
we
took
we
took
the
base
as
an
explicit,
separate
argument
and
we
didn't
call
it
log
n.
C
E
No,
I
was
looking
at
the
754
specs.
A
A
A
All
right,
25608,
vectors
and
span
so
it
looks
like
adding
read
only
span
constructors
and
writable
span
copy
twos
on
the
vector
two
three
and
four
types.
So
I
think
that's.
E
E
Basically,
we
expose
these
on
vector
of
t
we're
missing
the
overloads
for
vector
two
three
and
four
on
vector
of
t.
We
also
expose
span
constructors,
but
that
I
think,
was
just
an
oversight
because
we
also
exposed
the
read-only
span
ones
and
since
span
is
convertible
to
read-only
span.
I
opted
just
read-only
span
for.
N
These
so
yt,
like
I
mean
I
understand
they
because
they're
all
strongly
typed
right.
E
E
The
well
there
is
in
that,
if
you're
on
a
big
indian
machine,
you
have
to
read
it
as
a
big
indian
float,
but
we
expose
the
same
overloads
for
vector
of
t.
E
Yep,
it's
got
both
bite
and
tea.
I'd
be
fine
with
saying
we
just
support
float
here,
and
if
someone
really
wants
to
use
bite,
they.
A
Yeah
they
could
do
the
and
yeah
unsafe,
as
or
whatever
it
is.
A
Span
or
read
only
span
of
float
constructors
and
the
writable
span
afloat
copy
twos,
starting
with
that,
and
if
someone
really
has
an
argument
for
why
they
want
the
bytes
and
not
the
to
not
have
to
use
unsafe
as
then
they
can
try
arguing
it.
But
since
we
don't
already
have
on
these
types
a
copy
to
a
bite
array,
we
only
have
copy
to
a
float
array.
J
J
N
J
E
Should
have
those
as
well-
and
I
just
missed
them
in
the
writing
up
the
proposal.
N
F
N
You
can
ask
for
the
for
the
for
the
length
right
and
it's
static
anyway,
and.
N
A
Yeah
I
mean
doing
the
out
or
adding
the
out
variant
means
that
you
have
a
nice
pattern
for
composition
instead
of
like
special
casing
per
type
you're
calling,
but
I
think
that's
how
we
justified
it
after
the
fact
with
good
was
or
that
we
suggested
always
doing
it,
or
maybe
only
I
suggested
always
doing
it
for
composition
purposes.
D
N
N
D
D
N
A
N
Numerix
yeah,
the
only
reason
I
want
this
is
because,
like
I
haven't
done
it
yet,
but
I
have
the
prototype
where
I'm
indexing,
the
api
is
reapproved,
so
we
can
search
after
the
fact
and
then
it
works
better
when
we
actually
know
the
names
for
the
api.
A
N
A
N
A
A
But
like
you
know,
these
two
were
probably
you
know
a
few
seconds
to
talk
about
or
a
few
minutes
to
talk
about
one
and
then
we
just
approve
the
other
one
like
we
did
with
some
crypto
absolutions
earlier
yeah,
fair
enough.
But
yes,
hopefully
we
can
get
back
to
one
a
week
soon
and
be
happy
about
that.
A
Alrighty
awesome,
so
that
was
quite
a
productive
session
and
we'll
see
how
well
the
publish
button
works
after
this.
So
thanks
everybody.