►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello,
everyone,
it's
tuesday,
so
it's
api
review
time
it's
spring,
so
we
have
blocking
issues
and
nicely
it
doesn't
overflow.
My
screen
today,
so
I
guess
technically
it
never
has,
but
all
right
since
we're
still
in
the
red.
We
still
want
to
go
quickly
where
quickly
for
us
means
not
all
that
fast.
C
B
So
I'm
not
sure
how
in
detail
you
have
discussed
the
proposal
of
adding
a
buffer
five
stream
options,
but
to
tell
the
long
story
short,
we
have
removed
almost
all
allocations
from
firestream
and
the
last
one
is
the
location
of
the
buffer
used
for
the
buffering
buffering
is
disabled
by
default,
and
when
you
try
to
read
1k
of
bytes,
what
we
do
is
we
allocate
a
4k
buffer
and
read
4k
bytes
from
disk
and
give
you
the
one
k
that
you
asked
for
yeah.
So
by
doing
that
we
reduced
the
number
of
ciscos.
B
However,
we
allocate
the
memory,
and
this
has
been
reported
by
some
of
our
users-
that
don't
like
the
fact
that
we
allocate
the
memory.
So
we
have
few
options
to
mitigate
that.
So
the
first
one
that
I
would
like
to
propose
is
extending
the
five
stream
options,
with
a
possibility
for
the
user
to
specify
the
buffer.
B
B
The
api
is
quite
simple.
The
problem
is
that
by
introducing
this
possibility,
we
cannot,
you
know,
run
away
from
use
bugs
introduced
by
the
users
by
misusing
the
memory.
So
in
theory,
someone
could
rent
the
buffer
from
the
pool
provided
to
the
five
stream,
but
never
return
it
to
the
pool,
for
example.
So
we
could
exhaust
the
arrival
or
someone
could
allocate
unmanaged
memory
and
free
it
when
we
are
still
using
the
memory.
B
B
B
The
disadvantage
compared
to
the
the
first
proposal
is
that
it
limits
us
only
to
managed
memory
and
some
of
our
super
users
like,
for
example,
rev
db
folks.
They
wanted
to
have
the
possibility
to
specify
unmanaged
memory.
C
Okay,
so
my
view
is
that
as
much
as
I'd
like
for
this
to
be
in.net,
I
think
that
it's
something
that
we
likely
want
to
talk
with
maoni
and
yan
about
and
come
up
with
a
a
generalized
pattern
that
were
that
we
can
use
across
all
apis
where
this
would
be
applicable.
C
C
So
there
there's
other
patterns,
so
the
main
problem
with
the
memory
of
byte
approach
is,
you
are
effectively
passing
in
europe.
You
are
passing
in
a
buffer
to
the
stream,
but
you
still
are
responsible
for
cleaning
it
up
when
the
stream
is
done.
C
You
know
this
could
just
be
a
call
into
malik
if
you
wanted
to,
but
ultimately
the
stream,
when
it's
done
has
a
way
to
clean
up
that
resource,
whether
that's
returning
it
to
the
pool,
freeing
it
or
just
being
a
no-op.
That
way
you
can
reuse
it
yourself.
However,
you
want,
and
so
it's
likely
something
that
I
think
we
want
to
talk
with
yon
and
maoni
and
come
up
with.
C
Or
or
even
an
I
allocator
and
then
you
would,
you
would
say
I
take
a
t
where
t
is
an
eye
allocator
and
that
then
you
know
that
you
say
I
want
to
allocate
these
elements
and
then
it
gives
you
a
buffer.
That's
big
enough
to
hold
all
of
that,
and
then,
when
you're
done
with
it,
you
you
say
free,
but
then
the
the
object
that
did
the
allocation
is
responsible
for
for
saying
when
it's
done
that
way,
you
don't
have
the
issue.
D
C
G
Yeah
I
mean
the
memory
class
can
can
return
native
memory
yeah.
I.
C
Right,
yeah,
but
just
like
with
the
ray
pool,
there's
a
lot
of
potential
issues
with
it
today
and
jan
and
maoni
all
are
already
looking
into
this
area
for
array
pool,
and
I
would
want
their
sign
off
saying
that
yes,
memory
pool
is
what
we
want
to
do
or
what
we
will
continue
with
in
the
future,
because
it's
the
right.
No,
I.
F
Mean
it's
fair
yep!
No,
I
mean
it's
just
a
question
of
like
how
far
off
are
we
right?
Like
I
mean
it's
always
sad
when
you
refuse
an
api
and
say
that
let's
invent
this
generic
mechanism
that
we
don't
even
know
what
it
is
like,
but
it
seems
like
we
already
have
ways
to
do
it.
It's
just
a
question
of
like:
what's
the
pattern
we
want
to
promote
and
what
do
we
feel
warm
and
fuzzy
about?
I
think
levi
like
what
are
your
thoughts,
because
dustin
here
were
the
ones
pushing
back
on
this
proposal.
H
So
I
tanner's
right
there
we
have
fielded
requests
to
add
pooling
to
other
types
in
the
framework.
The
ones
that
stand
out
to
me
are
memory
stream
list
of
t
and
string
builder
people
ask
all
the
time
for
us
to
add
pooling
support
to
those.
If
we
had
some
common
mechanism
where
we
could
add
pooling
support
to
everything,
including
file
stream
via
a
common
pattern,
we
would
absolutely
want
to
do
that
rather
than
create
something,
that's
one
off.
H
C
This
is
like
a
you
know,
net
eight
feature,
then
I
think
that
it'd
be
fine.
If
we
say
like
maybe
array
pooling
is
good
enough
for
this.
For
today,
or
maybe
this
is
going
to
be
an
okay
one
off
if
they
say
that
you
know
we're
looking
at
having
this
fixed
for
net
six
or
for
don
at
seven,
then
I
think
maybe
we
just
want
to
hold
off.
F
Yeah
I
mean
the
question
is
like
the
alternative
design
that
adam
is
proposing
here,
where
basically
file
stream
would
manage
its
own
buffers.
The
only
thing
you
get
to
say
is
basically
the
yeah.
Please,
please
pull
them
and
please
use
this
buffer
size.
Do
we
think
that
the
this
addresses
the
concerns
we
had
from
last
time.
H
I
I
wouldn't
do
pool
buffer
on
file
options.
That
seems
like
the
wrong
place.
To
put
it.
If
we
wanted
the
ability
to
to
specify
your
own
buffer,
I
would
do
what
was
listed
earlier
and
just
take
it
as
a
parameter.
If
we're,
if
we're
nervous
about
the
fact
that
this
might
not
be
a
viable
long-term
feature,
I
mean
didn't.
We
just
approve
a
preview
feature
mechanism.
F
But
I
mean
to
me
it's
also
kind
of
a
little
bit
of
a
cop-out,
because,
if
you
put
experimental
on
something
like
what
exactly
are
you
looking
for
in
terms
of
feedback
to
make
a
decision
right?
Because
if
it's
robustness,
then
I
don't
think
you
get
that
via
that
mechanism.
Anyway,
right,
you
would
have
to
like
monitor
watson
reports
for
a
year
to
figure
out
what's
going
on,
but
that
might
be
hard
right
if
it's
more,
like
okay
be
unsure
about
the
shape
of
the
api.
Whether
people
can
actually
do
something
useful
with
it.
F
D
F
H
F
A
A
F
A
B
Yeah
one
more
problem
with
disposing
is
that
at
the
disposed
time
we
are
not
sure
whether
there
aren't
any
async
operations
still
in
flight,
because
in
theory
somebody
could
start
an
async
read
and
just
dispose
five
stream.
Without
waiting
and
to
be
honest
with
you
I've,
you
know
the
original
poster
asked
for
the
possibility
to
provide
unmanaged
memory.
However,
I
believe
that
this
is
rather
a
niche
scenario.
B
The
allocation
of
the
buffer
itself
was
never
the
biggest
birth
problem
and
we
have
solved
all
other
big
problems,
and
this
is
you
know
this
one
compared
to
others
is
tiny,
and
I
just
wanted
to
have
like
to
be
able
to
say
like
zero
locations
now
like
we
have
to
get
rid
of
all
of
them.
So
I
I'm
completely
fine
with
you
know,
taking
tanner's
recommendation
and
talking
to
jan
and
moni
and
coming
up
with
some
more
generic
approach,
like
maybe
something
that
gives
us
a
factory
of
eye
memory
owner.
A
Yeah
I
mean
so
the
big
problem,
unless
I
mean
mayonnaise
involvement,
means
we're
tying
it
into
the
gc,
but
the
the
the
big
problem
with
that
is
again
file
stream
doesn't
know
when
it's
done
with
the
thing
we
have
this
thing
that
tracks,
when
things
have
gone
out
of
you
know
referential
integrity.
I
don't
know
something
and
that
that's
the
gc,
like
we.
G
B
Another
problem
is
that
most
of
our
users
don't
know
that
it's
possible
to
disable
the
buffering,
it's
quite
magical,
because
you
need
to
set
the
buffer
size
to
one,
and
I
have
received
a
lot
of
feedback
on
twitter
about
this
particular
problem
with
the
ri
location
and
most
of
the
people
were
not
aware
of
the
fact
that
it's
possible
to
disable
it.
We
are
planning
to
mention
that
in
the
preview
for
blog
posts
and
also
release
a
set
of
recommendations
for
best
practices
for
a
file,
I
o
performance.
B
So
sorry.
F
B
F
A
Moments
right
yeah,
I
mean
so
now
that
you're
creating
the
option
bag.
You
do
have
a
complication
of
you
know.
Do
you
want
to
say
zero
means,
do
the
default,
or
do
you
want
to
say
that
zero
means
it's
disabled
and
you
just
in
the
constructor
default
it
to?
It
is
a
class.
So
you
can't
do
that.
So
you
have
to
decide
how
you
want
to
handle.
B
F
But
maybe
that's
just
me
because
I
think
file
options
is
the
super
advanced
like
drill
in
kind
of
thing
I
mean,
maybe
that's
where
pooling
should
be,
but
it
seems
to
me
if
you
can
specify
buffer
size
whether
whether
the
buffer
is
pulled
or
not.
It
seems
kind
of
like
a
setting
like
you
want
kind
of
next
to
it,
not
buried
in
some
other
struct
work
for
its
legs
based
even.
B
F
H
F
I
don't
know
like
I
mean
if
we
decide
the
options
thing
I
mean
right
now.
The
design
is
such
that
you
can
easily
should
really
pull
those
right,
because
it's
just
like
it's
your
shared
options,
you'd
set
up
once
and
never
to
cheer.
You
know
never
change
again,
so
I
I
generally
don't
care
about
these
options,
types
in
terms
of
allocations,
because
you
know,
unless
they
hold
on
to
for
a
used
state
which
they
shouldn't.
Arguably
they
are
basically
zero
cost.
F
F
F
We
have
talked
about
analyzers
for
that
as
well,
but
they're
also
very
very
hard
to
get
right,
because
the
compiler
makes
defensive,
copies,
left
and
right,
and
so
you
have
to
be
very,
very
careful
about
how
that
is
being
done,
and
there
was
some
conversation
about
exposing
was
an
api,
so
you
couldn't
principal
analyzer
that
does
that,
but
so
far
that
doesn't
exist.
So
you
would
have
to
kind
of
replicate
the
compiler
logic
which
you
know
it's
flaky.
B
A
B
F
K
A
I
think
you
said
he
was
willing
to
let
zero
be
buffering,
is
off
disabled.
K
B
So
eric
your
question
is
whether
we
should
set
the
default
value
for
okay
in
explicit
way
here.
So
the
default
behavior
is
the
same.
Buffering
is
enabled
with
a
4k
buffer.
K
B
Yeah,
so
I
think
that
we
should
set
it
in
to
4k
in
explicit
way
and
the
difference
with
five
stream.
Constructor
will
be
that
zero
will
be
accepted
as
a
way
of
disabling
the
buffering,
because
currently,
if
the
firestream
constructors
throw
for
zero
and
negative
values
through
it,
one
as
buffering
disabled
and
everything
bigger
than
one
as
actual
buffer
size.
B
B
A
H
Eric
are
you
eric
t?
Are
you
on
the
call.
D
Yeah,
I'm
actually
wondering
is
in
the
call,
okay,
some
some
some
context
on
this
issue.
I
actually
only
saw
it
this
morning,
but
I
had
this
discussion
about
this
very
proposal
with
andy
and
steve
told
a
few
weeks
ago
and
my
conclusion
and
steve
steven's
conclusion
was
that
this
would
create
issues
like
diamond
issues
with
interfaces
that
provide
implementations
for
that
method.
So
I
I
wouldn't
personally
support
this
yeah.
D
I
guess
I
guess
I
should
have
removed
the
ready
for
review
label,
but
I
I
only
just
saw
it
so
I
I
I'm
also
wondering,
if
andy
might
have
you
know,
given
that
we
had
this
conversation
in
the
past,
I'm
wondering
if
he
had.
D
He
made
some
new
findings
that
might
invalidate
the
point
about
diamond
problems
being
an
issue
with
this
particular
method,
but
the
main
example
that
basically
makes
this
impractical.
If
you
scroll
down
is
you
would
need
to
provide
implementations
for
I
collection
of
t,
and
I
read
only
collection
of
t
and
you
have
many
many
classes
that
implement
both
interfaces
so
immediately.
A
Yeah
I
mean,
I
think,
right
now,
our
general
stance
is.
I
don't
know
that
anybody
who's
in
this
meeting
right
now
has
used
dims
and
if
they
have
used
dims,
I
don't
know
they've
used
them
in
a
library
they've
published
and
that
they've
then
versioned.
So
one
of
the
big
things
right
now
is.
H
We
have,
we
have
andy
joining
us
now.
We
managed
to
get
them
in.
A
Yeah,
so
what
really
the
question
for
you
is?
Why
are
you
not
concerned
of
this
introducing
diamonds
me?
Yes,
you
andy,
the
proposer.
A
So
it
was
pointed
out
in
in
the
comments
on
the
issue
that
I
read
only
list
and
I
list
would
probably
both
want
to
provide
implementations
for
the
base
member,
which
means
now
any
type.
That's
both
I
list
and
I
read
only
list
it
has
a
diamond
conflict
because
they
both
have
a
count
so.
A
Fair,
I
mean
I
guess,
but
then
that
would
be
saying
that
we
didn't
never
overwrite
it
in
the
interface
hierarchies
and
make
all
the
types
have
to
go
back
and
do
it
like.
We
can't
use
the
interfaces
to
help
out
because
we
have
separated
read-only,
and
I
read
only
list
in
our
list
like
we
can
never
unify
them,
which
means
we
can
never
unify
an
implementation
for
this
particular
member
other
than
the.
I
can
enumerate
myself
and
count.
A
E
I
A
E
It
right,
if
we
do
it,
if
we
do
it
now,
it
wouldn't
be
moving
it,
the
the
point
being
that
we
have
to
figure
out
like
what
we
would
want
to
introduce.
So
here's
the
thing,
I'm
fine.
If
the
the
resolution
here
is,
we
tried
our
best
and
we
couldn't
make
it
work,
but
I
didn't
see
that
I
would
like
to
see
a
justification
of
why
we
can't
do
this
because
I
looked
all
over
the
repo
and
I
cannot
find
one
well.
The
short.
K
E
E
F
D
F
E
Yeah
now,
if
we
can't
extension
yeah
okay
for
visibility,
then
it
maybe
doesn't
matter
because
the
answer
is,
we
change
the
implementation,
but
then
we
should
really
decide
what
the
implementation
is.
So,
for
example,
the
current
implementation
I
went
and
it
checks
to
see
like
dynamically
type
checks,
to
see
whether
or
not
the
target
is.
I
collection.
E
Well,
it
wouldn't
exist
on
ionumerable
non-generic
or
we
put
it
on
innumerable
non-generic,
but
that's
like
a
decision
that
we
probably
have
to
make
now
the
whole
dynamically
type
checking
for
a
non-generic
version
inside
the
implementation,
for
I
enumerable
of
t
is
already
a
little
bit
like
I
pointing
out
the
implementation
problems,
for
this
made
me
think
that's
a
little
sketchy
anyway.
F
Yeah,
so
to
answer
your
first
question,
I
think
the
problem
with
the
diamond
so
last
time
we
looked
into
this-
was
the
question
of.
Can
we
make
the
mutable
interfaces
extend
the
read-only
ones
so
that
we
don't
have
this
dichotomy
in
our
class
hierarchy
and
the
reason
we
couldn't
do
it
when
we
introduced
them
was
because
of
explicit
interface
implementations
right,
because
the
the
base
methods
would
have
different
identities
from
the
derived
ones?
And
so
basically,
we
thought
that
maybe
we
can
use
explicit
interface.
F
Members,
sorry
default
interface,
members
to
map
them
so
that
when
you
basically
extend
eye
collection,
you
don't
have
to
redefine.
You
know
I
would
only
collection
members,
because
that's
already
done
by
eye
collection
and
it's
kind
of
doing
what
jeremy
suggested
by
basically
now
you
have
a
derived
interface
defining
default
members
for
its
basis
and
that
works
so
long.
You
don't
have
a
hierarchy
with
a
diamond
anywhere,
but
the
polymers
of
our
collection
interfaces
like
dictionaries,
for
example,
they
implement
frequently
multiple
different
generics
and
then
they
both
go
back
to
the
same
ancestor.
E
F
Yeah,
I
mean
that's
fair,
I
mean
I'm
not
convinced
either
it's
like
last
time.
We
looked
into
this.
We
we
spent
significant
time
and
then
gave
up
like
I
mean
the
the
because
it
wasn't
the
biggest
problem
at
the
time
either
right
so,
but
basically
it
is
the
yeah.
The
concern
is
basically
what
happens
when
we
do
that
right.
I
F
A
But
I
mean
right
now:
the
the
cynical
interpretation,
which
is
probably
true,
is
we're
in
a
catch-22
of.
We
won't
use
dims
because
we've
never
used
dims
and
we
definitely
won't
use
dems
on
eye
enumerable
because
we've
never
used
dims,
and
so
we
don't
understand
what
the
role,
what
the
breaking
changes
are.
The
only
thing
we
know
is
anytime.
Anybody
has
come
up
with
them.
A
E
So
I
I
distinctly
remember
some
of
those
conversations
and
they
were
for
all
of
the
discussions
at
that
time
that
I
was
a
part
of
were
for
existing
members.
E
They
were
not
for
new
members,
so
I
think
that
there
needs
to
be
another
discussion
specifically
for
adding
new
members
and
then,
if
you
want
to
be
conservative
about
it,
just
in
general
for
like
all
dim
stuff-
and
if
you
want
to
be
conservative
about
bionumeral
in
particular,
then
I
think
you
should
have
a
write-up
of
why
it's
not
possible
for
any
variant
of
I
enumerable
before
adding
something
new
to
I
enumerable,
like
that's
the
super
conservative
approach.
E
If
you
really
want
to
be
careful
about
bioenumerable,
then
it
would
be
to
say:
okay
when
we
think
about
adding
new
things
to
ionumerable
that
would
be
appropriate.
As
default
interface
methods,
we
should
figure
out
what
the
problems
are
with
default
interfaces
interface,
methods
on
innumerable
first
and
write
them
all
down.
F
I
mean
so
far
like
what
you
said
is
actually
not
true
like
we
don't
have
a
massive
desire
to
add
a
ton
of
methods,
so
I
know
mobile
right
so,
like
usually
we
solve
problems
when
we
have
them,
and
so
we
went
three
years
without
having
to
do
that.
So
that's
that's!
That's
how
we
never
ended
up
writing
it.
E
F
H
But
by
the
way,
just
just
for
some
historical
interest
like
we
did
bring
to
api
review
a
year,
maybe
two
years
ago
default
interface
implementations
on
I
enumerable
of
t
such
that
they
would
implement
the
non-generic
I
enumerable
interface
for
you
like
they
would
forward
calls
to
move
next.
Current
dispose
would
no
off
and
so
on,
and
this
group
at
the
time
said
well
wow,
that's
really
valuable,
but
we
don't
think
we
can
do
it
for
the
same
reason,
the
group
didn't
know
what
would
break
if
we
were
to
do
that.
A
A
Always
ends
up
being
dictionary
of
to
key
to
value
like
that,
any
time
that
we've
ever
thought
of
doing
anything.
It's
always
on.
I
enumerable.
We
end
up
a
dictionary
of
tiki
to
value
and
it
ends
up
creating
a
conflict
and
then
just
showing
where
all
the
conflicts
are
going
to
come
out
of.
E
A
E
H
F
I
mean
we
can
certainly
do
the
write
that
I
think
I
have
no
objections
to
that.
It's
just
that.
You
know
the
demand
is
usually
the
other
way
around
right.
It's
not
like.
We
have
to
provide
a
write-up,
but
we're
not
doing
things
because
the
risks
are
higher
than
the
rewards,
usually
right.
So,
for
example,
the
the
thing
that
levi
suggested
was
useful
people
that
have
to
actually
manually
implement.
F
I
enumerable,
which
is
not
a
very
common
scenario
right
most
of
the
people
that
implement
enumerables
do
this
by
writing
iterators
or
they
just
compose
existing
collections
and
forward
calls
right,
so
they
so
the
so.
The
concern
is
like
yeah
we're,
adding
a
feature
that
benefits
a
few
advanced
users.
F
E
F
F
It's
not
like.
E
Been
okay,
you
know
what
that's
not
true,
it
should
have
been
cheap
and
the
reason
was
because
you
should
have
done
this
in
a
documented
way.
If
you
have
a
big
conversation
with
david
wright,
where
you
decide
a
new
rule
for
the
framework
for
innumerable
what?
If
half
you
got
hit
by
a
bus,
and
we
have
to
figure
out
what
to
do
about
innumerable
now,
like
there's
no
record
of
this,
and
somebody
just
goes
and
adds
it
and
then
it
breaks
like
write
down
the
decision.
F
I
I'm
gonna,
I'm
gonna
jump
in
here
a
little
bit
folks,
we're
like
way
off
in
the
weeds
in
terms
of
some
process.
I
think
there's
a
good
discussion
to
be
worked
out
in
terms
of
what
level
of
documentation
we
need
to
have
around
this
problem
space.
I
think,
for
the
moment,
this
particular
issue
is
not
moving
forward
today.
Should
we
move
on
to
the
next
site
on
the
agenda.
E
E
H
Well,
I
will
say
I
will
say
that
if
you
go
to
issue
29513
jeremy
did
add
a
lengthy
comment
to
the
bottom
of
that
detailing
what
he
believes
the
problem
is.
We
should
probably
confirm
whether
or
not
that
problem
is
real.
A
So
fdg3
has
a
an
annotation
from
me
that
says.
The
only
rule
we
understand
so
far
is
never
provide
an
implementation
of
a
of
a
base
method,
because
that
creates
diamonds,
but
that
otherwise
we
don't
have
enough
experience
to
know
what
the
actual
rules
should
be,
and
that
continues
to
be
true,
because
every
time
we've
come
up
with
a
place
where
we
feel
that
we're
willing
to
start
experimenting,
they
go.
Oh
we're
net
standard
2o
because
we
care
about.net
framework,
so
we
can't
use
dimms
and
then
we
go
back
to.
I
H
A
F
K
E
E
F
E
F
Yeah,
I
think
the
the
question
is
also
language
is
that
this
is
the
whole
like.
Do
we
care
about
cli
or
whatever
sorry
cls,
but
like
we
don't
really
care
about
tls
compliance
is
the
mechanism,
but
we
do
care
that
our
framework
is
consumable
by
other
languages
right.
So
the
the
problem
then
becomes
is
like
what
what
do
we
be
and
f
sharp,
do
as
well
right?
It's
not
just
what
does
the
runtime
do,
but
yeah
all.
A
A
All
right
so
for
those
who
don't
feel
like
reading
a
tiny
screen,
what
I've
put
in
the
notes.
We
currently
have
apprehension
about
adding
dems
at
this
level
for
this
particular
method.
We're
concerned
that
the
obvious
solution
is
to
re-implement
the
methods
in
eye
collection
of
tni,
read-only
collection
of
t,
which
now
provides
multiple
non-unified
implementations
to
concrete
types
that
would
manifest
as
a
runtime
breaking
change
for
any
type.
That
already
implements
those
two
interfaces,
but
we
agree.
We
could
use
some
better
concrete
guidelines
here
going
forward.
A
C
E
E
E
D
E
A
Yeah,
which
is
then
anything
any
type
that
has
overwritten
all
those
things
explicitly
implemented
count
because
they
have
a
thing
called
link
that
they
think
is
a
better
public
name.
Then
those
would
now
not
provide
account
implementation,
so
they
would
fail
to
compile
or
fail
time.
I
don't
think
that's
true.
E
E
Or
or
something
like
that,
right,
like
you,
can
there
are
a
variety
of
different
mechanisms
you
can
do
you
can
you
can
just
make
it
a
different
name
or
whatever,
and
then
you
default
implement
that
and
then
so,
basically,
you
know
what
just
we
should
go
through
and
make
sure
we
can't
figure
it
out.
Some
other
way.
A
F
A
F
Yeah,
let's
just
like,
because,
given
that
we
have
the
people
in
the
room,
I
would
start
with
them.
So
I
guess
then,
to
mobility.
First
yeah
yeah.
F
A
J
Eric
erhardt
logged,
an
issue,
that's
linked,
and
basically
the
issue
is
that
if
you
call
this
crate
method,
it
may
invoke
the
serializer
later
when
you
call
to
jason
string
and
because
they
can
call
the
serializer
which
is
not
trim
safe.
We
had
to
add
we
need
to
add
an
attribute.
We
haven't
done
that
yet,
but
we
need
to
add
an
attribute
to
the
create
method
which
causes
other
kinds
of
issues,
especially
since
the
json
node
base
class
implements
tostring,
and
it's
a
virtual
method,
of
course
on
object.
J
So
the
idea
is
to
split
up
the
crate
into
two:
a
safe
crate
and
an
unsafe
trade,
and
in
order
to
do
this
without
completely
kind
of
changing
the
programming
model,
a
bunch
of
overloads
were
added
to
create
for
the
supported
types,
and
these
are
the
safe
ones.
H
Unsafe,
so
my
my
first
question
is
like
you,
you
have
a
bunch
of
overloads
that
take
nullable
types
like
nullable
pool,
nullable,
byte
and
so
on,
but
the
implementation
just
returns
null
like.
Why
not
just
force
the
caller
to
pass
a
non-nullable
value
to
these
methods.
A
H
I
I
was
just
trying
to
figure
out
like
if,
if
somebody
would
be,
if
somebody
would
be
surprised
that
I
passed
like
a
nullable,
I
passed
null
to
the
question
mark
method
and
instead
of
returning
a
json
value
that
represents
null
it
just
returns
null.
J
J
A
nullable
of
fool
will
return
a
null
json
value.
J
A
J
J
J
As
long
as
the
serializable,
meaning
that
we
can
call
the
serializer
later,
when
you
call
two
json
string,
you
know
it'll
work,
so
that
was
the
intent
of
the
the
name
of
you
know
from
serializable
value
anyway,.
J
A
Just
saying
like
once,
we
have
date
time
offset
date,
time
and
guide
in
here
like
it's
not
like
we're
everything.
That's
in
here
is
primitives,
and
this
is
the
non-primitives
plus
we
have
the
creative.
If
you
give
it
the
serializer
state,
then
you
can
call
the
simple
name,
and
it's
only
when
you
call
the
the
one
that
it
needs
to
make
it
up
on
the
fly
that
you
have
to
call
the
long
name.
So.
F
I
mean
the
problem
with
primitives
is
that
there
is
a
it's
not
like.
There's
this
one
definition
of
a
primitive
right
I
mean
you
can
either
say.
Is
this
you
know
intrinsic
in
il?
Does
it
that's
keyboard
where
there's
multiple
dimensions
to
that,
and
they
don't
all
agree
on
what
is
truly
a
primitive
type
right,
but
I
think.
F
H
Wouldn't
wouldn't
most
people
just
call
create
anyway,
passing
in
their
serializable
type
like
if,
if
I'm,
if
I'm
literally
just
typing
on
a
keyboard,
I'm
going
to
see
a
bunch
of
overloads,
create
I'm
also
going
to
see
that
I
can
just
pass
any
arbitrary
value
to
create.
So
why
would
I
ever
call
create
from
serializable
value?
Well.
J
E
J
Yeah,
so
so,
actually
this
particular
method
isn't
directly
related
to
the
main
issue.
It
was
just
like:
okay,
you
know,
trim
ability,
sorry,
the
json
type
info
was
added
after
json
node,
so
our
are
at
the
same
time.
So
we
couldn't
add
this
at
the
same
time,
but.
I
F
J
Cross
that
one
basically
is
replaced
by
the
crate
from
serializable
value,
plus
the
explosions
below
the
very
first
crate
that
takes
just
type
info
is,
is
really
unrelated
to
the
main
issue.
J
F
I
F
J
Can
reference
an
existing
converter
for
those.
J
And
for
the
programming
model
for
95
users
won't
notice
this
right,
because,
if
they're
calling
create,
I
mean
if
they
happen
to
use
in
the
preview
four
bits,
at
least,
if
they're
calling
creative
t
that's
in
red,
they
just
you
know
that
it'll
still
when
they
come,
recompile
it'll
just
compile
assuming
they're
using
a
primitive
type.
Or
you
know
one
of
these
known
types.
G
Is
there
a
way
that
the
trimmer
could
be
smarter
with
the
existing
generic
method?
Is
that
a
silly
question.
B
K
F
J
J
And,
and
for
the
most
part
since
there's
inference
on
these
crate
methods,
you
don't
have
to
yeah
when
the
intellisense
is
gonna,
be
you
know,
kind
of
big,
I
guess
when
it
pops
up,
but
it's
not
gonna
go
into.
J
K
F
D
J
J
And
and
if
you
scroll
down
a
little
bit
more
just
to
close
on
it,
there
was
an
implicit
some
implicit
operators
that
were
missing
explicit
operators
that
were
missing
for
jason
element.
We
don't
have
to
add
this,
but
but
since
we
covered
all
of
the
other
values
above
except
for
these,
except
for
jason
element,
I
think
it
makes
sense
to
round
out
the
parity
between
create
and
the
operators.
J
F
Oh
because
you
returned
nullible
from
the
nullable
and
not
another
from
the
number
yeah
I
see
yeah,
I
was
under
the
impression
that
you
could
just
take
a
non.
You
could
only
accept
the
nullable
and
then
the
user
has
implicit
conversions,
but
then
they
also
get
another
one.
But.
A
A
F
A
A
J
A
Yeah
personally
I
mean
I,
I
know
that
there
are
people
who
care
about
the
you
know
150
bytes.
It
takes
to
just
declare.
This
method
is
existing,
it's
below
my
carrying
bar,
so
I
have
no
problem
with
the
top
part:
I'm
not
totally
sold
on
create
from
serializable
value,
but
don't
have
a
better
name
and
we
kind
of
want
people
to
not
call
it
if
they
care
about
trimming.
So
having
not
a
great
name
is
fine,
so
I'm
I
personally
am
like
whatever
sign
off
on
this.
F
J
Ignoring
trim
ability,
I
mean
you'd,
want
to
call
create
from
serializable
value
when
you
have
an
anonymous
type,
when
you
have
your
own
custom
data
type
or
when
you
have
a
pokeball
or
collection,
and
you
want
to
be
able
to
assign
that
to
adjacent
value
and
serialize.
It.
J
J
F
Yeah
because
I
mean
like
realistically
what
happens
is
now
when
I
pass
in
my
poco
and
I'm
not
trimming,
I
don't
care
right.
Everything
will
just
work
if
I
enable
trimming
now
I
get
linker
warnings
because
I
have
these
restrictions
right,
but
that
seems
fine.
I
mean,
like
you,
get
informed
that
you're
doing
something
that
may
not
work
right,
but
why
would
I
have
to
call
the
method
of
a
different
name
to
do.
A
That
I
mean
we
could
go
either
way,
it's
just
a
question
of
so
I
don't
know
and
maybe
eric
you
know
how
much
trim
ability
should
matter
to
people
in
coming
releases
because
by
having
a
different
name,
it
means
that
we
have
a
place
in
method
group
documentation
that
we
can
say
this
method
group
is
not
trim
friendly.
If
you
can
rewrite
your
code
so
that
you
can
call
create,
then
you're
trim
friendly.
If
we
think
it's
kind
of
niche,
then
the
attribute
says
enough.
F
When
you
put
this,
I
am
linker
friendly
attribute
on
your
libraries
right
that,
presumably,
that
code
would
have
run
right
because
I
feel,
like
I
don't
know
like
it
seems
weird
to
me
that
we
say
we
put
attributes
on
it
and
then
we
invest
in
a
design
time
experience
to
give
people
squiggles
and
warnings
and
then
at
the
same
time
also
say.
Oh
by
the
way
we
have
a
naming
convention
throughout
the
framework
that
we
name
everything.
F
A
Yeah,
so
I
guess
when
I
saw
it
my
my
first
thought
was
really
it's
of
why
it
made
sense
and
steve.
You
can
tell
me
if
this
was
part
of
your
thinking
or
if
it's
just
a
bonus
reason
is
if
you're
calling
the
one
the
the
generic
one
and
you
have
the
pre-generated
thing
from
the
source
generator.
You
probably
want
to
pass
it.
But
if
it's,
if
everything
else
that
calls
create,
is
you
pass
the
one
thing
and
you're
done,
and
this
thing
has
40
overloads,
so
you're
not
going
to
cycle
through
them?
A
You
don't
see
that
there's
a
better
thing
that
you
could
do
by
passing.
A
second
argument.
So
by
this
the
this
t
is
the
one
you
want
to
call
only
if
you
have
no
better
option
so
having
a
different
name
makes
you
have
to
kind
of
think
about
it.
But
if
we
don't
care
about
the
like
the
mild
perfect,
then
whatever.
F
Yeah
I
mean
it
depends
on
who
you
want
to
optimize
for
right.
I
think
I'm
okay
with
different
names,
I'm
just
saying
imagine
I'm
a
developer.
You
know,
as
philip
said,
I'm
an
old
country
developer
right,
I'm
just
using
you
know
the
dom.
I
don't
care
about
trimming,
I'm
not
doing
anything.
Fancy
I
just
write
a
very
simple
app.
F
K
We
have
other
cases
where,
like
one
overload
is
marked
quote
unquote,
unsafe
and
the
other
one
is
mark
safe
right,
like
json
serializer.serialize,
if
you
call
the
overload
that
doesn't
take
in
the
json
type
info,
that's
that's
unsafe,
so
I
mean
you'll.
If
you
care
you'll,
get
the
link
or
warning
that
you're
calling
the
jsonvalue.create
that's
not
safe
right
like
us,
naming
it
us
naming
it
something
different,
doesn't
doesn't
stop
you
from
getting
the
link
or
warnings
or
doesn't
start
you
from
getting
the
link
or
warnings
right.
J
Yeah,
we
just
call
it
create.
I
I
think
from
the
discussion
that
we
had
eric
and
I
had
earlier.
We
we,
you
know,
didn't
really
decide
on
a
hard
name,
but
it
doesn't
collide.
I
mean
it
will
pick
the
the
more
specific
overload
down
below.
F
K
Mean
the
99
cases
you
want
to
call
create
with
us
what
I'm
going
to
call
a
primitive
value.
I
don't
care
what
anybody
else
thinks
it
is
like.
I
want
to
call
jsonvaluecreatestring
double
whatever
right,
and
so
I
I
want
that
to
just
work
and
the
reason
why
this
one's
safe
is
because
these
primitive
values
are
intrinsic
to
the
serializer
like
they
don't
need.
F
J
J
Right
for
sure
yeah
what
once
one
other
my
fyi
one
other
small
benefit
of
doing
the
separate
crate
methods
is
we
can
auto
assign
a
converter
because
we
know
hey
you're,
calling
the
int
you
know
create
with
an
int,
for
example,
we
can
get
in
converter
and
we
don't
have
to
do
a
dictionary
lookup,
so
it
actually
does
help
in
a
roundabout
wave
performance.
J
F
E
A
J
J
J
It
it's
it's
an
implementation
detail,
but
json
element
the
explicit
operator
can
throw
if
the
json
node
you're
passing
in
is
an
object.
Json,
I'm
sorry,
json
object
or
json
array.
We
don't
have
to
throw
there,
but
if
you're
going
to
create
adjacent
node,
that's
based
upon
adjacent
element,
that's
an
object
or
an
array.
Then
you
should
pass
that
json
or
what
am
I
trying
to
say
here?
J
F
C
H
List
so
in
in
an
ideal
world,
like
I
absolutely
agree
with
tanner
like
implicit
conversion,
should
never
be
lossy.
I
I
would
be
willing
to
fudge
a
little
bit
that
implicit
conversions
shouldn't
throw
like,
and
it
it
makes
me
want
to
take
a
shower
to
say
that,
but
we
have.
We
do
have
precedent
for
that.
H
Like
casting
the
t
array
to
a
span
of
t
is
an
implicit
conversion
and
can
throw,
but
it
throws
so
rarely
yeah
whatever
it's
generally
useful
for
people
to
have
the
implicit
conversion
and
ignore
the
0.5
chance
it
could
fail.
F
H
D
F
H
F
J
And
by
the
way,
and
by
the
way,
my
description
of
the
the
throwing
capability
of
jason
element
wasn't
correct
in
the
sense
that
if
you
pass
in
a
json
element
that
that
is
an
odd
based
upon
json
object
or
json
array,
it
should
create
the
proper
json
node.
It
won't
throw
create
on
json
value.
However,
is
it's
different
because
that's
has
to
return
adjacent
variables,
yeah.
J
In
this,
in
this
case,
it
should,
it
should
have
to
know.
A
F
It
just
seems
yeah.
It
just
seems
odd
to
me
that
we're
saying,
because
basically,
if
json
node
and
json
element
are
effectively
the
same
concept,
then
it
seems
odd
that
one
is
explicit
and
one
is
implicit
like.
If
anything,
I
would
have
expected
the
allocation
one
to
be
explicit
and
the
non-allocation
might
be
implicit,
but
it's
the
other
way
around
so
like
I
would,
I
would
probably
say,
like
we
probably
should
make
them
both
implicit.
Then,
like.
I
don't
know
why
you
would
have
make
one
side
right.
The
car.
A
F
A
F
A
J
So
and
in
theory,
if
jason
element
has
some
adjacent
value
kind
or
some
kind
of
weird
type,
a
pointer
I'm
just
making
something
up,
I
don't
know
that's
not
supported
by
jason;
no,
they
could
throw.
J
A
J
F
F
J
J
There
is
a
constructor
that
that
takes
it.
F
A
J
Yeah,
well,
you
can
either
use
the
cast
operators
that
we,
you
know
or
you
go
through
the
sterilizer.
A
J
Okay,
so
if
you
have
adjacent
value
or
json
node
in
general,
and
you
want
to
get
a
json
element,
that's
the
question.
Yes,.
J
Someone
writes
other
than
the
serializer.
Perhaps
I
mean
a
roundabout
way
of
doing
it
with
the
jit
with
jason.
I
don't
think
it's
possible.
It's
primarily
intended
for
incoming
right
interop
with
json
element.
F
Yeah,
I
don't
think
anybody
pushes
back
on
the
feature
it's
more
like.
We
generally
have
the
guidance
that
says
if
you,
if
there
is
something
you
can
do
with
a
casting
operator,
you
should
be
able
to
do
the
same
thing
without
relying
on
the
casting
operator
because
they
are
not
part
of
the
normal
api
surface.
Right
like
the
problem,
is
that
basically
undiscoverable,
you
have
to
know
that
you
can
invoke
them.
Implicit
ones
are
usually
somewhat
discoverable.
So
long
people
have
a
feel
for
what
what
is
compatible
right.
F
F
J
The
interesting
thing
is
that
when
you
create
a
json
node
through
a
parse
method,
it
is
backed
by
json
element
and
purposely.
You
can't
easily
get
that
out,
because
if
we
allow
you
to
get
it
on
that
case,
that's
fine
because
it's
already
there.
But
if
you
want
to
create
one
because
for
you,
you
created
a
new
dom,
for
example-
and
you
created,
you
know,
adjacent
object
and
you
want
to
get
a
json
element
out
of
that.
J
Value
to
adjacent
value,
if
you
pass
in
because
you
can
specify
well
in
the
crate
methods
here,
then
you
can.
Then
you
can
get
the
same
value
out.
J
J
At
one
point,
we
had
to
get
value
method
that
you
could
that
we
would
have
several
layers
of
pullback
jasonville.com
and,
let's
say,
okay,
if
the
t
value
doesn't
match,
then
you
know
we're
going
to
start
looking
at
the
json
element
and
if
that
doesn't
match
we're
going
to
call
the
serializer
and
do
kind
of
this
magic
for
you
and
today
and
then
basically,
based
on
some
discussions,
we
decided
that
that's
too
much
magic
and
we'll
just
keep
it
straight
forward.
A
Yeah
I
mean,
I
guess
the
only
reason
that
I
wonder
if
we
don't
want
the
implicit
element
to
node
is
that
that
can
be
a
that
could
be
a
whole
lot
of
particle
allocations.
A
Like
if
your
json
element
represents
a
very
large
structured
document,
the
fact
that
jason
node
will
create
a
different
object
for
each
individual
portion
of
that
document,
like
you
could
go
from,
you
have
one
tightly
compacted
thing
to
you
just
created
over
a
million
objects.
That's
that's
a
lot
for
what
looked
like
you
passed,
a
parameter.
J
It
it
doesn't
happen
right
away,
so
basically
there's
a
direct
reference
to
that
element
and
then,
as
you
navigate
your
tree
and
you
navigate
to
other
objects
or
arrays
or
you
ask
for
okay,
so
they're
they're
lazy
under
value
or
something
like
that,
then
arrays
explode
objects
explode,
but
it's
still
lazily
done
throughout
the
whole
tree.
Okay,
I
guess
that's
fine,
so
the
performance
actually
of
this
method
versus
json
element
is
about
the
same
like
within
one
percent,
because
it
just
keeps
a
copy
of
json
element
until
you
start
navigating
or
asking
for
values.
F
Yeah,
that
seems
fine,
I
mean
I
mean.
The
only
thing
I
would
say
is
like
it
seems
I
don't
know
like
is
how
often
do
people
have
to
pass
across
the
boundary
right
like?
If
you
think
it's
substantially
rare,
I
I
would
probably
aware
I
would
probably
just
not
have
converting
operators
that
would
probably
just
have
you
know
an
instance
method
that
gives
you
one
like.
I
mean
for
spanish
arabia,
doing
it,
because
people
pass
them
around
a
lot,
and
so
we
don't
want
to
write
the
code
every
single
time.
F
J
F
J
Oh
well,
jason,
okay,
jason
goldman
is
read
only
but
it's
very
performant.
So
if
you
happen
to
get
a
hold
of
a
json
element,
maybe
you're,
you
know
using
json
document
and
you
know
an
eye
disposable
pattern
and
all
that
goodness
and
then
you
find
a
certain
node
that
you
want
to
start
now
editing
you
can
do
that
by
passing
an
adjacent
element.
You
know
to
these
these
operators
or
the
create
method,
and
then
you
know,
modify
it
and
then
serialize
it
or
call
the
serializer
whatever
you
want.
J
F
A
F
F
F
Then
I
can
say
dot
two
node
right
and
then
I
get
back
a
json,
oh,
that
that
that
to
me
makes
a
lot
more
sense
as
a
as
a
as
a
consumer,
or
I
mean
even
like
to
have
a
json
node
static
factory
method,
you
can
say
json
node.create
and
you
pass
in
the
element.
That's
also
fine
right,
because
those
are
the
places
I
would
probably
be
looking
for
right.
I
would
not
magically
try
to
cast
and
see
yeah.
J
A
J
Yeah
exactly
I
I
think
I
mean
in
fact
we
could
create.
Add
some
static,
create
methods
to
json
node
instead
of
json
value
right,
and
that
would
make
more
sense
actually.
J
I
think
so
I
mean
the
two
changes
right.
One
is
called
the
crate
with
serializable
value,
whatever
just
create
and
then
remove
those
four
new
overloads
for
now.
K
K
One,
oh,
you
mean
okay,
this
one,
this
one's
going
to
call
these
unsafe
api;
basically.
A
J
K
J
A
D
A
K
A
Fair
enough
yeah.
K
H
H
Sorry
some
quick
comments
on
this.
That
jeremy
has
written,
don't
forget
to
add
the
like,
not
null,
if
not
null,
attributes
and
blah
blah
blah,
where.
H
A
Oh,
I
guess
good,
no
excuse
destruction.
All
the
things
that
are
knowable
are,
I
don't
think
not
null.
If
not
null
applies
to
nullable
of
t,
I
thought
that
was
only
if
it
was
a
reference
question
mark.
F
F
H
A
F
You
can't
do
that
because
they're
different
types
right
so
the
so.
This
only
works
for
the
reference
types
cases,
because
it's
the
same
type
and
you
just
described
runtime
behavior
right,
which
for
nullible,
doesn't
make
a
sense
right
because,
if
like,
if
you
give
me
a
non-null
in
like
then
you're
not
well,
I
guess
I
can
give
you.
I
guess
you
could
apply
it
to
another
blinds
right,
because
then
I
said
like
they
denied
it
will
in
they
give
you
back.
I
promise
it's
not
going
to
be
now
right.
You
could
do
that.
A
All
right,
so
I
don't
think
there
are
any
other
knowable
annotations
that
we
need,
and
then
this
comment
is
out
of
dates.
I.
F
A
Okay,
I
think
this
is
right
now.
A
J
L
All
right,
the
next
one
10
minutes.
A
All
right:
hey
backlog,
synchronous,
deserialized
and
serialized
to
a
stream
using
json
serializer
one
five,
seven,
four,
it's
a
four
digit
number:
how
cute.
F
K
K
A
H
We
also
added
in
608
serialized
async
enumerable
method
to
json
serializer.
Presumably,
we
want
de-serialize
enumerable.
A
H
Okay,
so
you
don't
want
the
ability
to
pull
off
values
one
at
a
time
you
you
still
want
only
the
ability
to
deserialize
the
whole
object
in
a
single
shot
right.
A
A
J
Yet,
by
the
way
we've
had
to
work
around
this
issue
internally,
we
have
some
http
extensions
for
asp.net
and
we
have
to
do
some
ugly,
threading
hacks.
You
know
on
weight
methods
that
can
go
away
once
we've
done
this
it'll
help
clean
up
the
maternal
code
as.
J
A
A
I
guess
I
could
indent
those
things
I
think
I
got
it.
F
A
Somewhere
after
you
lost
the
ability
to
host
the
streams,
somebody
had
commented
in
chat
that
it
totally
worked,
and
then
I
tried
it
and
it
was
flabbergasted.
So
thank
you,
chat,
yeah.
H
There
there
was
an
open
question
and-
and
maybe
this
is
a
separate
issue,
but
there
was
an
open
question
as
to
like
whether
we
wanted
ildasm
to
just
ignore
it
or
you
know,
have
a
force
parameter
to
ignore
it
or
whatever.
But
is
this
not
the
right
group
for
that
then.
F
F
The
attribute
was
a
bad
idea.
Not
the
deprecation
of
it
is
a
bad
idea,
because,
fundamentally
there
is
critical
mass
of
obfuscators
that
don't
honor
it
today.
So
I
I
think,
there's
just
no
point
in
doing
that,
like
if
you,
if
you
actually
care
about
your
ip,
just,
don't
write
it
in
net
or
obfuscate.
It
right
like.
Basically,
these
are
the
two
options
you
have
right,
and
so
I
feel
like
this
thing
gives
you
a
false
sense
of
honest
people
being
honest
and
so
like
I
don't
know
what
the
point
of
that
is
and.
H
H
This
one's
actually
pretty
straightforward.
Actually
I
I
think
we
can
get
this
in
under
10
minutes
they.
H
Basically,
when
you
call
me
when
you
call
marshall.alec
right
now,
like
we
have
a
bunch
of
allocation
apis,
but
they
don't
guarantee
any
type
of
alignment,
say
that
say
that
you
really
need
something
to
be
8,
byte
or
16
byte
aligned,
I
think,
as
an
implementation
detail,
some
of
the
alec
methods
might
say
sure
it's
always
going
to
be
eight
byte
align,
but
they
and
but
maybe
that's
only
an
implementation
on
a
specific
operating
system
or
on
a
specific
architecture,
blah
blah.
H
And
if
you,
if
you
really
need
alignment
like
we,
we
right
now
force
you
to
do
it
manually.
These
are
going
to
be
apis
accelerator,
apis
that
wrap
the
underlying
c
runtime
aligned
allocation
routines.
H
C
Yeah
yawn
and
I
were
in
favor
of
just
saying
that
these
are
crc
runtime.
The
c
runtime
provides
a
minimal
amount
of
guarantees
and
doesn't
run
into
the
same
issues
that
alec
h
global,
for
example,
does
where
it's
tied
to
an
operating
system,
specific
api
and
therefore
it's
a
breaking
change
to
do.
Basically
anything
in
the
future.
H
Yeah
my
I
originally
had
pushback
to
to
saying
that
they
called
into
the
sea
runtime
until
jan
and
tanner
kind
of
explained,
in
the
thread
that
it's
it's
typical
nowadays
to
have
exactly
one
runtime
per
process,
and
you
don't
have
nowadays
situations
where
two
different
libraries
will
load
two
different
versions
of
the
runtime.
I
mean
if
you've
statically,
linked
like
more
power
to
you.
I
guess,
but
that's
just.
C
C
Notably
yawn
raised
three
three
questions
in
in
the
issue
here:
the
first
one
should
the
apis
return
void
star.
Instead
of
into
pointer,
we've
been
leaning
towards
using
actual
pointers
for
pointers
to
buffers.
My
vote
was
yes,
we
should
be
returning
void
star
here.
Should
the
apis
take
the
buffer
size
as
in
as
an
inuint
rather
than
init
so
unsigned?
C
My
vote
was
also
yes,
there's
no
reason
to
limit
this
to
two
gigabytes
on
a
32-bit
process,
nor
to
artificially
mismatch
from
the
c
api
which
we're
basically
doing
a
one-to-one
correspondence
with
and
the
last
one
is,
should
we
just
call
these
alec
and
free
and
alec
aligned
and
alec
and
aligned
free,
or
should
we
actually,
you
know
append
it
with
memory
like
is
in
the
top
post
here,
and
my
vote
was
also.
We
should
just
call
this.
You
know
alec
realic,
free,
those
are
the
simple.
G
C
That
was
a
question
that
I
raised
separately
that
no
one
else
really
had
any
input
on,
which
was,
if
you
look
across
what
most
standard
native
allocators
provide,
there's
actually
a
number
of
methods,
in
addition
to
the
ones
listed
here,
and
therefore,
should
we
actually
define
like
a
a
separate
memory,
utilities
class
or
something-
and
I
did
not
suggest
a
name,
basically
just
a
static
class
on
interop
services.
That
is
separate
from
marshall.
That's
hope
whose
whole
purpose
is
any
of
these
memory
management
functions.
A
Like
honestly,
my
my
preference
would
be
that
you
know
whatever
allocate
things
we
have,
they
don't
return
void
star.
They
don't
return
in
pitter.
What
they
return
is
safe
handle
because
then
they've
already
hooked
up.
What's
the
right
free
for
you
and
then
you
can
get
the
int
pitter
and
then
that's
the
void
star
out
of
it.
I.
A
Right
and
yeah,
and
so
you
would
need
these
in
order
to
power
the
safe
handle
but
like,
but
once
we
start
adding
like
I'm,
I'm
guessing
on
linux,
because
when
I
looked
at
the
man
page
for
posix
memolined,
it
didn't
talk
about
a
separate
free.
So
I
think
on
on
posix
systems,
free
aligned
and
free
are
going
to
be
the
same
thing,
but
on
windows
they
seem
to
be
different,
and
so
that's
seems
like
we're
just
creating
room
for
problems.
A
C
Right
so
so
posix
does
have.
I
don't
remember
if
it's
aligned
underscore
free
or
free
underscore
aligned,
it
does
define
it
it's
just
it's.
Basically,
an
optimization
and
free
is
supposed
to
work
for
your
aligned
allocations
regardless.
It
may
just
do
additional
logic
to
determine
what
block
you're
in
rather
than
assuming
that
it's
already
at
the
start
of
a
walk.
Okay,.
C
I
actually
have
a
list
a
little
bit
further
down
of,
for
example,
microsoft
publishes
me
malik,
which
is
a
native
memory
management
alternative
to
the
the
c
runtime
functions
and
it
it
provides
posix
and
windows
compat
for
a
lot
of
functions,
and
I
listed
all
the
variants
that
exist
and
therefore
what
we
might
you
know
we
could
theoretically
add
in
the
future.
If,
if
enough,
people
ask
for
different.
C
I
don't
think
that's
an
issue.
Every
abi
in
the
world
is
tied
to
the
sea.
Runtime
even
rust
is
tied.
Limitedly
to
the
sea,
runtime
in
terms
of
malekin-free,
like
windows,
is
fundamentally
tied
to
it
and
they
anything
that
they
replace
in
the
future
is
either
going
to
be
completely
breaking
or
will
have
some
kind
of
c
runtime
compat
layer
sounds
good.
F
That
I
don't
I'm
not
even
sure
I
buy
that
like
if
there's
a
fundamental
reason
why
we
can't
support
the
c
runtime
interval
layer.
I
would
just
deprecate
that,
like
you,
look
at
the
marshall
type
right
a
lot
of
the
stuff
on
it
is
like
tied
to
windows
and
guess
what
we
still
go.
Cross-Platform
just
fine
right.
You
just
make
certain
things,
throw
right
worst
case.
C
Yeah,
I
I
think
that
we
should
have
a
different
class
and
we
should
not
use
it
pointer
because
every
single
person
is
going
to
have
to
cast.
Also
inpointer
has
a
fundamental
problem
in
that
it
is
a
sign.
Type
and
pointers
are
not
signed,
pointers
are
unsigned
and
you
can
run
into
all
kinds
of
issues.
If
you
don't
use
it
correctly,.
F
I
A
A
C
You're,
if
you're
touching
marshall
you're
already
dealing
with
unsafe
code
and
half
the
apis
take
unsafe
variants.
Anyways
now,
like
the
the
whole
push
from
the
runtime
team,
is
to
move
towards
more
explicitly
unsafe
code,
because
this
semi
safe
code
that
looks
safe.
But
it's
really
not
just.
It
is
a
pit
of
failure.
100
percent.
C
H
Yeah,
I
I
I
would
agree
like
we
should
just
do
the
right
thing
going
forward.
Instead
of
trying
for
consistency,
which
also
means
nuance,
instead
of
meant
yeah,.
A
I
mean
I
would
like
so
I'll
cave
easily,
but
my
my
feeling
is,
if
you're
on
the
same
type,
you
should
follow
the
same
pattern,
and
if
we
made
a
new
type
then
it
can
be
the
new
pattern
like
I
don't
I'm
not
saying
it
needs
to
be.
We
don't
use
pointers
anywhere.
It's
we
don't
use
pointers
on
marshall
allocators.
A
C
C
Yeah
that
and
that
would
allow
us
to
add,
like
calc
in
the
future
or
xalic
or
you
know
any
of
the
other
alternatives
still.
H
A
So
I
I
believe
that
it
should
be
a
lowercase
a
if
we
did
not
already
have
re
alec
as
having
capital
a
on
marshall.
Now
that
it's
not
on
marshall,
there's
room
for
discussion
on
marshall.
It
should
obviously
follow
the.
A
H
So,
just
just
for
full
disclosure,
someone
in
youtube
chat
did
mention
that
native
memory
will
clash
with
native
span
if
it's
ever
added.
I
don't
think
this
is
a
huge
issue
to
be
honest,
because
this
is
going
to
be
in
a
different
name.
Space.
H
H
If,
if
we
have
an
int
linked
span,
instead
of
just
int,
it's
some
north
star
feature
we're
all
wishing
would
be
done.
A
C
We
could
definitely
have
indexers
that
take
like
native
and,
like
array,
for
example,
implicitly
supports
int.
You
went
long,
you
long
innant
and
inuint,
and
it
turns
out
it's
broken
yes,
so
we
we
probably
could
and
should
add
the
equivalent
overloads
on
span
just
for
consistency
with
array,
but
outside
of
that
it
doesn't
buy
a
lot
other
than
you
don't
have
to
downcast.
When
you
input
it
you,
you
still
can't
actually
allocate
and
do
things
with
indexes
that
long.
H
I
see
jeremy,
you
have
a
question
marks
for
the
alignment
parameter.
Is
it
because
you're
thinking
alignment
well,
what's
the
crt
api
for
that.
C
There
is
not
a
direct
c
runtime
equivalent
for
it,
it
is
a.
It
is
a
c
runtime
extension
that
is
commonly.
C
C
So
it
should
be
nuant
yeah,
that's
also,
but
I
was,
strictly
speaking,
alignment
comes
before
size.
H
Really
because
I'm
I'm
looking
at
windows
is
size.
H
C
H
K
H
H
H
F
Yeah
we
should
match
the
c.
Names
will
be
my
preference,
if,
because
I
mean
otherwise
adding
new
c
style
methods
gets
harder
and
harder
if
they
have
different
name
interventions
from
ours
and
give.
This
is
really
an
api
that
is
used
for
people
that
are
coming
from
the
c.
I
would.
I
would
just
use
the
c
names,
but
is
it.
B
F
B
F
C
C
C
H
So
if,
if
we're,
if
we're
saying
that
this
api
is
for
standards,
then
would
we
remove
free
aligned
because
alloc,
aligned
or
sorry
aligned,
alec
just
goes
with
free.
H
C
C
and
for
c
we
are
c11
compliant,
but
not
the
optional
part.
So
if
it's
an
optional
api,
it
may
not
exist.
C
But
we
we
can
always
check
and
if
it
does
exist,
not
expose
free
aligned
and
if
it
does,
then
we
would
expose
it
and
call
it
align
free.
I
mean
it
depends
on
what
it's
called
well
on
windows:
it's
free
aligned.
But
if
we're
matching
the
ordering
of
the
of
the
c
names,
then
I
would
imagine
it'd
be
aligned,
underscore
free.
H
F
J
C
H
C
C
Element
count:
that's
what
I
called
it.
Oh
yeah
yeah
never
mind.
C
A
D
A
H
H
C
A
Yeah,
because
this
is
this
is
just
called
e-l-s-I-z-e
in
posix,
and
then
this
is
in
elem.
Instead
of
using
the
in
prefix,
we
use
the
count
suffix
and
then
this
just
turns
el
into
element.
So.
F
F
Exactly
so,
we
only
measure
managed
heap,
we
don't
care
about
negative,
so
one
thing
is
like
on
the
last
thing:
we
just
approved
the
one
where's
that
we
don't
need.
The
diagnostic
id
eric
was
questioning
that
and
I
on
on
second
thoughts.
I
agree
with
him.
We
should
just
give
it
the
diagnostic
id
just
for
two
reasons.
One
of
them
is
it's
just
more
consistent
and
the
other
one
is
there's.
Probably
a
topic
that
actually
warrants
its
own
help.
Page
would
be
my
guess,
because
it
is
a
controversial
non-intuitive
thing.
F
A
I
forget
to
mark
this
one
approved:
I
did
that's
gonna
shoot
or
destroy
the
video.
Oh,
no
just
it
didn't
undo
close
tab
didn't
refresh
it
cool
there.
Now
it
said
the
whole
thing
was
the
right
thing,
the
whole
time,
all
right.
So
yeah,
good
thing.
You
didn't
take
that
bad
emo
because
we
touched
the
backlog
today.
H
F
H
Yeah
and
the
one
that
I
want
to
talk
about
is
is
first
in
the
backlog,
so
hopefully
we
won't
get
more
than
two
or
three
new
red
issues
coming
over
the
next
few
days,
yeah.
H
I
imagine
is
looking
forward
to
the
one:
that's
what
is
that,
like
four
or
five
down
yeah
four.
A
A
So
all
right,
so
thanks
for
joining
us,
everyone
and
oh
wait.
What
are
we
next
thursday,
thursday
or
friday,.
F
Well,
I
just
I
just
codified
the
rules
we
were
supposed
to
use
so
like,
but
I
mean
it's
still.
You
know
there's
still
some
room
for
interpretation
there,
because
I
because
I
sort
by
creation
date,
which
isn't
always
the
fairest.
Realistically
we
should
sort
by
when
it
was
marked
api
ready
for
review
last
and
that
that's
not
as
trivial
unfortunately,
so
I
don't
do
that,
but
that's
probably
will
be,
would
be
more
fair
to
the
process.
Yep.