►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
A
B
And
if
you
want
to
do
optional,
things
then
fall
back
to.
I
was
thinking.
If
you
want
to
do
optional,
things
fall
back
to
the
default
constructor
and
specify
everything
but
like
in,
like
just
the
canonical
case,
or
at
least
the
the
one
all
the
ones
that
I
ran
into
doing
the
health
check
service.
They
all
needed
these
three.
You
know
event
id
log
level
and
message
and
if
you
scroll
up
it
just
it
it's
completely
convoluted
to
have
to
specify
event
id
log
level
message.
Each
time
you
write
these.
C
D
B
E
Did
sarab
have
reasons
to
want
the
other
ones
to
support
the
optional.
C
Events,
did
I
say
events?
Oh
yeah,
that's
another
thing.
I
was
also
looking
there's
an
event
name.
If
we
wanted
to
have
all
the
parameters
specified
in
the
constructor.
Should
that
also
be
included.
F
F
A
C
C
Okay,
right
and
while,
while
we're
at
it,
let's
also
make
event
id
option.
C
Make
event
id
optional
to,
in
instance,
like
nullable?
Actually,
no
I'm
thinking
like
zero
would
because.
B
C
I
will
respond
in
two
minutes.
I
have
to
open
up
the
issue.
Sorry,
but
it's
five,
two
two
two
three:
I
don't
wanna
derail
the
meaning.
So
let's
just
have
this
one
as
argument,
one
constructor.
B
B
G
I
think
so
yeah
could
actually
set
up.
G
A
Okay,
like
this
is
slowly
paging
back
in.
I
I
feel
like
we
decided,
we
didn't
want
any
constructors
and
that
you
should
just
name
the
parameter,
and
we
were
fine
with
just
saying
you
have
to
name
the
the
property
sets,
because
this
is
attribute
syntax,
not
like
you're.
Never
creating
one
of
these
manually.
A
B
A
F
And
they're
all
different
types
too,
which
makes
me
feel
better
about
it.
So
it's
not
like
people
are
likely
to
get
the
order.
G
In
the
data
annotations
name
space,
quite
a
few
of
those
attributes
have
multiple
overlands
in
their
constructor.
A
Okay,
yeah.
I
know
that
for
a.
A
B
So
it's
having
parameter
constructors
and
settable
properties
on
on
attributes.
That's
the.
A
That's
one
of
our
general
non-patterns
is
that
for
attributes
it's
the
trying
to
page
things
in
from
multiple
context.
We
like
the
constructor
parameters
for
required
things
and
then
optional
things
become
just
the
settables
and
then
we
generally
don't
have
accelerators
in
attributes
is
my
recollection.
A
A
B
I
mean
for
sure
we
obviously
don't
need
this
new
constructor
right.
It's
not.
This
is
it's
a
bit
of
a
vanity
thing,
but
it's
still
I
mean
I
didn't
have
just
three
of
these
right.
There
was
like,
I
don't
know,
10
or
12.
You
know
in
a
class,
and
it
was
just
like
looking
at
this
wall
of
text.
I
was
like
this
is
a
lot
of
stuff.
What
can
I
get
rid
of
and
these
jumped
out
as
pretty
obvious
of
like
these
aren't
necessary,
so.
H
I
I
think
in
particular
the
event
id
and
log
level
with
the
first
one,
the
common
paddle
pattern
being
event:
ids
dot
and
the
latter
one
being
an
enum,
and
so
it's
always
going
to
be
log
level
dot.
I
think
those
ones
make
a
lot
of
sense
to
be
just
parameters
and
expected
through
the
parameter
or
through
the
constructor,
just
because
listing
the
name
of
the
property
or
signing
duplicates
information,
but
for
message.
H
It
almost
seems
like
that
one
should
be
a
named
parameter,
because
passing
in
arbitrary
string
doesn't
tell
you
what
this
is
in
in
the
parameter
list.
It
could
be
a
message.
It
could
be
a
caption,
it
could
be
a
prefix.
A
Yeah
the
but
I
mean
I
don't
know
the
event
id's
dot
is
like
this
is
what's
in
the
sample
here,
but
I
don't
know
that.
I
A
F
C
H
It's
a
warning
so
notably
there's
also
an
issue
here.
Logger
message
attribute
log
level
and
logger
message
attribute
event:
id
are
conflicting
overloads
if
you
pass
in
zero
or
default,
because
zero
is
implicitly
convertible
to
an
enum,
and
so
I
believe
they
conflict.
A
F
A
G
Happy,
I
only
see
but
okay
yeah,
I
I
the
max
that
I
see
on
the
screen
is
a
three
point.
F
G
G
C
A
H
A
Right
they,
yes,
so
my
my
recollection
is
there
was
talk
of
like
that.
The
next
version
was
going
to
have
like
possibly
different
ways
that
things
could
be
set
and
that
at
that
point
message
would
become
optional
and
and
that
it's
the
same
attribute
for
some
reason
and
and
then
we
just
shrugged
and
said
then
make
everything
get
set
and
have
a
default
constructor
and
we're
done
with
the
issue.
But
apparently
we're
not
done
with
the
issue.
So.
G
A
C
I
I
didn't
get,
I
didn't
get
the
question,
but
I
just
posted
something
that,
like
with
the
attribute
having
an
empty
string
messages.
K
C
Okay,
so
in
the
so
the
the,
if
you
don't,
provide
them
and
if
you
don't
provide
a
the
answer,
is
you
can
have
a
bunch
of
arguments
in
your
log
method
and
you
can
have
like
it
will
keep
the
structure
in
the
log
message
without
you
even
having
an
message
string.
C
F
C
F
F
C
C
But
one
last
question:
I
think:
was
it
levi
that
asked
if
not
null
message
should
also
be
allowed?
G
A
The
constructor
will
run
if
you
ask
reflection
for
the
attributes,
otherwise
it
doesn't.
The
generator
is
probably
not
looking
at
reflection.
It's
looking
at
the
the
syntax
nodes,
so
I
mean
we
can
make
the
constructor
body
do
whatever
we
want.
It
just
doesn't
matter
in
nine
nines
of
all.
In
instances
of
this
attribute.
A
You
can't
I
mean,
but
you
know
tooling,
is
still
going
to
look
at
it,
be
like
message
wasn't
assigned.
What
do
I
assign
it
to?
I
can't
assume
that
it's
I
mean
the
tooling
can
assume
it's
empty
or
the
string,
hello,
world
or
whatever,
but
like
implicit
defaults,
have
to
be
done
both
in
the
constructor
and
in
the
tooling.
A
But
yeah,
if,
if
there's
a
situation,
where
message
being
null
means,
do
something
else
or
it's
theoretical
that
it
would
do
that
in
the
future,
then
we
should
just
as
leave.
I
said,
put
the
question
mark
in
the
property
and
be
like
caller
beware,
whatever
null
means,
which
is
probably
actually
just
fine
to
do
anyway,.
C
A
On
yeah,
really
it
comes
back
to
the
question
of.
Was
there
a
scenario
for
the
generator
that
was
supposed
to,
or
that
does
exist
or
is
planned
to
exist
where,
if
a
message
was
not
specified
in
the
attribute
that
some
other
behavior
happens,
such
as
binding
to
the
first
string
property
and
the
signature
or
whatever.
F
C
A
J
L
I
have
reached
out
to
the
customer
to
the
original
poster
alex
and
what
actually
turned
out
it.
It
wasn't
that
just
alex
wanted
to
read
a
specific
offset.
He
also
wanted
to
provide
multiple
buffers
and
have
the
possibility
to
do
it
in
parallel.
So
that's
why
I
have
added
two
new
methods:
read
scatter
and
write
gather.
L
L
That's
the
feedback,
I
got,
it
was
simple
solution
and
it
would
just
work.
It
was
fine.
L
So
in
the
updated
proposal
we
have
a
method
that
first
of
all
allows
to
open
a
given
file
by
specifying
all
of
the
five
stream
constructors
and
the
method
returns
save
our
handle.
We
have
a
method
that
allows
us
to
get
the
length
of
the
file
because,
let's
say
if
we
want
to
read
the
file,
we
need
to
know
the
length
up
front.
L
L
D
So
I
have
just
a
kind
of
a
meta
comment
here,
which
is
that
we
have
talked
in
the
networking
space.
We've
talked
a
lot
about
adding
scattergather
I
o
to
both.
Well,
we
have
it
on
socket
to
some
extent,
but
it's
all
we
don't
have
memory
or
span
support
for
it
today.
It's
all
in
terms
of
array
segment,
but
we've
talked
about
adding
first
class
scanner
gather
I
o
support
to
both
socket
and
stream,
and
so
it
seems
like
this
api
is.
D
The
first
is
blazing
a
trail
here
that
I
hope
we
would
want
to
use
the
same
pattern
for
in
in
those
classes
as
well.
I
don't
have
a
strong
opinion
on
whether
this
is
the
right
pattern
or
not.
I
just
want
to
make
sure
that
whatever
we
do
works
in
that
space
as
well
and
for
stream,
of
course,
there's
no
file
offset.
L
So
here
the
request
was
to
make
it
offset
based
and
the
main
reason
for
doing
that
was
to
allow
for
a
threat,
safe
concurrent,
reads
and
rights,
and
so
and
because
of
that,
we
didn't
want
to
add
it
to
five
stream,
because
in
five
stream
we
have
this
position
of
the
concept
of
position
and
every
read
is
supposed
to
read
the
next
bytes
yeah.
No,
I
get
the
desire,
I
get
the.
D
A
D
L
L
L
So,
as
far
as
I
remember,
the
remarks
didn't
mention
when
it
can
happen,
you
just
need
to
be
ready
for
that
and,
for
example,
in
case
of
five
stream.
We
have
this
logic
today
that
we
are
retrying
the
right.
D
L
A
L
That's
a
very
good
feedback
and
I
think
that
we
can
switch
to
white
and
not
introduce
any.
L
G
And
file
offset
is
intended
to
be
unsigned
here,
because
I
know
you
know
signed
links,
don't
or
negative
links.
Don't
make
sense
for
the
scenario.
Negative
offsets
don't
make
sense,
but
we
have
traditionally
on
stream,
even
our
64-bit
values
have
been
signed.
Often
I
don't
know-
maybe
it's
just
a
week
a
week
because
you
have
like
you're
taking
file
offset
as
a
year
long
you're,
returning
the
value
as
long
and
that
value
is
clearly
never
going
to
be
negative.
G
L
H
B
L
L
And
also
tanner
mentioned
the
sick
method
when
it
comes
to
sick
that
one
of
the
regions
can
be
the
end.
L
So
if
we
accept
a
negative
offset
and
an
enumeration
that
tells
it's
it's
from
the
end,
then
we
have
to
perform
another
cisco
to
get
the
length
of
the
file
and
calculate
the
actual
offset,
because
the
underlying
os
methods
don't
accept
it.
They
just
accept
four
offset
from
the
beginning
a
long
value.
G
Got
it
so
so
you
expect
that
the
handles
used
in
these
apis
are
positioned
at
zero,
correct
yeah.
G
L
So
it's
like
the
fact
that,
given
500
has
an
offset
set
for
all
of
the
methods
that
we
are
talking
here
right
now.
It
doesn't
matter
because
for
on
windows
for
read
file
and
write
file
and
read
files,
scatter
and
gather,
we
would
be
providing
the
offset
on
our
own
and
by
the
way
recently,
we
have
introduced
a
breaking
change
to
five
stream,
and
five
sim
is
no
longer
synchronizing
the
position
with
os
offset.
G
L
G
L
D
D
L
I
just
wanted
to
make
it
really
future-proof
and
for
every
low-level
high-performance
scenario
available,
and
I
think
this
could
be
really
useful
for
big
files
so
yeah.
I
would.
H
Prefer
to
have
long
as
soon
as
someone
says,
two
gigabytes
is
more
than
enough.
I
I
point
out:
no,
it's
not
bs
is
finally
moving
to
64
bit.
Everyone
eventually
needs
more
than
two
gigabytes
in
some
scenario,
so
I
really
don't
like
us
artificially
limiting.
L
A
D
Yeah
the
main
concern
I
have
about
it
is:
I
think,
that
that
it's
probably
a
common
scenario
that
I've
got
existing
read
code
like
I've
got
code
that
does
read
and
offset
into
a
single
buffer,
and
then
I
go
oh
wait.
I
want
to
actually
change
this
into
a
read
scatter,
but
now
and
I
am
passed
two
or
three
buffers
into
it
and
and
but
now
my
return
values
are
long,
and
that
means
as
a
user.
D
What
do
I
need
to
do?
I
probably
am
going
to
do
something
like
cast
it
to
an
end
and
which
hopefully
works,
because
I
know
how
big
my
buffers
actually
are,
but
it
seems
like
a
potential
source
of
bugs.
In
other
words,
people
are
used
to
dealing
with
the
result
of
read
as
an
int,
and
if
it's
now
a
law,
then
they
are
in
most
cases,
probably
just
going
to
cast
into
an
end,
and
that
may.
G
J
G
A
You
need
to
deal
with
the
fact
that,
like
the
numbers
are
bigger
now
so
long
makes
sense
to
me
and
if
it's
people
don't
understand
what
long
is
and
they
just
cast
it
to
end,
then
they're
not
capable
of
calling
scatter
correctly.
Like
I
don't
know.
A
If
you're
smart
enough
to
call
scatter,
you
should
be
smart
enough
to
know
that
longs
are
bigger
than
ants,
and
you
need
to
check
that
one's
like
that.
It's
not
too
big,
which
is
either
do
a
checked
cast
or
have
custom.
Oh
my
god.
How
do
I
deal
with
the
fact
that
I
need
to
return
an
end
because
otherwise
we
just
have
to
throw,
and
that
feels
like
if
we
were
gonna,
throw
on
that
one.
We
should
just
not
add
it.
Yeah.
D
I
take
the
point
and
I
can
imagine
there
are
scenarios
where
you
actually
do
want
to
do
a
read
scatter
into
that
results
in
a
read
of
more
than
two
gigabytes.
I
just
I
think
the
the
vast
majority
of
cases
are
going
to
be
like
I've
got
a
handful
of
16k
buffers
and
I
want
to
skip,
read
scatter
into
it
and
in
that
case
long
is
just
getting
in
your
way
and
but
I'm
not
sure,
there's
anything
to
do
about
it.
Yeah.
A
G
Yes,
so
we're
also
improving
native
array
and
native
span
as
part
of
this
right,
yeah.
A
A
Because
I
had
missed
that
this
one
is
returning
you
long
do.
We
need
the
64th
bit.
L
Yes,
because
the
five
stream.length
is
also
64
bit
and
files
can
be
bigger
than
two
gigabytes.
H
H
I
I
just
wanted
to
try
the
the
native
os
apis,
almost
always
return.
Unsigned
net
is
really
the
odd
thing
out
where
it
returns,
signed,
values
for
all
indexing
and
lengths,
and
it
causes
no
end
of
perf
problems
in
various
scenarios,
because
this
is
signed.
But
it's
really
unsigned
because
negative
values
are
always
disallowed,
but
the
jit
can't
know
that,
so
it
just
becomes
a
question
of
consistency
or
do
the
right
thing
and,
in
my
opinion,
do
the
right
thing
is
unsigned.
G
A
What's
what's
interesting
here
right
is
so
our
general
don't
put
the
you
tight
or
don't
put
the
types
that
require
a
scientist
modifier
since
for
byte
it's
signed
is
the
modifier.
A
I
mean
that
does
stem
from
cls
compliance,
which,
yes,
is
no
longer
really
a
thing
but
the,
but
that
is
you
know
our
pattern,
so
scattergather
on
stream,
like
is
probably
going
to
be
long.
Not
you
long.
It's
here
on
the
safe
file,
handle
you're,
doing
more
ioe
things
and
we're
representing
what
the
as
long
as
the
posix
and
windows
are
both
in
agreement
that
this
is
an
unsigned
value.
A
Then
I
think
saying
unsigned
here
is
totally
sensible
if
they
both
agree
that
this
is
an
unsigned
value,
then
we
could
say
unsigned
here
is
totally
sensible,
but
file
stream's
still
going
to
call
it
signed
long,
because,
basically
our
answer
is
once
you're,
not
basically
bare
metal.
We
don't
really
use
unsigned
numbers
and
aside
from
bite,
and
so
it's
a
question
of
is
the
is
the
mismatch
of
this
is
returning
you
long,
but
higher
level
constructs
are
all
going
to
have
to
do.
A
The
conversion
check
is
that
worthwhile
is
my
long-winded
question
and
the
answer
could
be
yes,
I'm
just.
I
ask
questions.
H
G
L
L
There
is
because
here
we
are
opening
the
the
handle,
so
we
kind
of
own
it
and
if
the
the
handle
will
be
specified
by
the
user,
so
the
user
somehow
creates
the
handle
we
we
are
still.
We
still
need
to
call
a
method
that
obtains
a
lot
of
information
about
given
handle,
for
example,
to
find
out
whether
it
was
open
for
async,
io
or
syncio,
and
whether
it
targets
a
regular
file
or
type
or
socket
or
unknown
file.
H
A
L
L
So
this
is
a
proposal
that
I
would
like
to
come
up
get
back
here
in
the
future,
but
I
have
asked
people
for
feedback
on
twitter.
I
haven't
found
a
single
person
that
actually
needed
that
the
person
who
originally
created
the
issue
mentioned
that,
after
doing
some
research,
it
turned
out
that
no
all
direct
wasn't
because
of
direct.
This
is
the
linux
thing,
wasn't
actually
what
the
outro
wanted.
L
I
I
A
Okay,
so
I
think
we're
actually
up
to
read
scatter
now,
we've
sort
of
flirted
with
it,
and
now
I
think
we're
really
here.
So
I
think
we've
agreed
that
long
as
good
as
the
return
type
we're
good
with
you
long
on
the
offsets.
A
Yeah,
why
can't
this
be
a
read
only
well,
I
know
I
guess.
I
know
why
it
can't
be
a
read-only
span
of
span
or
an
enumerable
of
span
or
anything
of
span,
but
why
is
it
a
memory
of
memory
for
a
non-async
api.
D
G
M
That
is
certainly
an
easier
thing
to
pull
off.
You
know.
The
spanish
fan
is
a
thing.
We've
talked
about
a
number
of
times
and
it's
it's
never
quite
met
the
bar
of
like
this
is
important
enough,
but
is
it
gonna
happen
at
night?
Seven?
I
doubt
it
probably
it'll
take
quite
a
while
to
put
through
so
we'll
know
by
the
middle
of
dot-net,
seven
whether
it'll
happen,
but
I
don't,
I
don't
think
so
we
might
be
able
to
do
it.
M
The
feature
we've
contemplated
is
actually
allowing
ref
structs
in
a
more
general
fashion.
D
I
have
a
scenario
for
span:
is
a
generic
parameter
if
you're
interested
but
I'll,
take
it
yeah?
No,
that's
so.
M
Several
people
do
yeah.
D
A
M
Basically,
runtime
magic
would
make
it
work
and
you
just
have
like
the
api.
You
can
use
it
but
like
let's
not
discuss
that
here.
A
Because
it
does
seem
if
we
had
runtime
support
for
it,
I
guess
and
language
support,
then
the
natural
type
to
go
here
aside
from
emo's
hissing
microphone
would
be
a
read-only
span
of
spam.
A
A
So
it
seems
weird
that
we're
taking
like
the
thing
that
stands
out
to
me,
isn't
that
it's
read-only
memory
of
something
it's
it's
read-only
memory
of
memory,
and
I
just
wonder
if
that's
the
right
abstraction
for
the
synchronous
version
of
read,
scatter
and
write
gather.
D
But
unless
I
don't
given
the
limitations
around
span
and
refstrucks
today,
I'm
not
sure
what
the
alternative
is.
I
mean
I
think,
that
inner
parameter
speaking
of
the
the
inner
thing
there.
It
has
to
be
memory
of
bite
and
not
span
a
bite,
or
I
mean
it
could
be
something
else
like
array
segment,
but
it's
not
clear
why
we'd
use
anything
other
than
memory
there
I
mean:
what
else
would
we?
What
else?
Could
we
do?
That's
fair.
I
guess.
A
It's
just
it's
as
a
super
high
level
hand,
wavy
thing
we
have
that
you
know
for
a
synchronous
method.
That
is
not
like
a
synchronous
method
that
is
not
saving
the
buffer
use
a
span,
a
synchronous
method
that
is,
saving
the
buffer
uses
memory,
and
in
this
case
it's
not
saving
the
buffer.
It's
I
wasn't
allowed
to
accept
spam.
A
And
yeah,
so
especially
if
this
is
you
know,
on
safe
file,
handle
it's
sort
of
off
in
the
weeds,
and
if
this
is
the
place
that
we're
starting
and
we
come
up
with
a
better
solution
for
next
time-
and
we
can
do
something
better
than
a
read-only
memory
of
memory,
then
this
will
gain
an
overload
and
we'll
just
hope,
like
heck,
that
we
can
do
it
without
implicit,
conversions,
destroying
the
world.
So.
G
I
would
suggest
read
only
spam
of
memory
and
the
reason
that
I
suggest
that
is
say
that
you
have
a
list
of
tea
and
you're,
adding
a
bunch
of
memory
of
white
buffers
to
it.
We
have
helpers
that
can
expose
a
list
of
tea
or
that
can
project
it
as
a
span
of
t,
but
we
don't
have
helpers
that
can
project
it
as
a
memory.
G
D
Yeah,
although
in
practice
I
suspect
implementations
are
well
at
least
the
socket
implementation
would
copy
that
that
higher
array,
you
can't
copy
buffers
right,
because
you're
actually,
because
a
they're,
big
and
c
you
actually
are
b.
You
actually
want
to.
You
know,
use
them
for
the
I
o,
but
the
the
buffer
array
itself.
You
can
just
copy
the
pointers
if.
G
A
Maybe
I
mean
again
the
if
the
windows
one
is
actually
just
turning
into
a
loop.
It's
you
know,
probably
one
of
those
things
of
like
fine
color.
Beware,
if
you
start
this
async
operation
and
you
start
changing
what
the
memories
mean
in
the
middle,
like
good
luck,
reproducing
your
results.
G
I
agree
with
that.
I'm
looking
at
the
unix
implementation,
at
least
as
called
out
in
the
description,
and
it
says
it's
going
to
throw
that
memory
of
memory
across
the
frontal
boundary.
G
So
you
would
have
to
make
that
copy
before
going
across
the
front
pool
which
again
you
absolutely
could
it's
just
an
implementation
detail,
but
maybe
maybe
we
say
just
to
make
life
easier.
Maybe
right
now
we
take
span
of
memory,
force
the
implementation
of
copy
and
then,
if
we
figure
out
a
way
to
avoid
it
in
the
future
out
of
memory
of
memory
overlay,
because
we
control
all
these
overloads.
It's
not
like
someone
has
to
implement
virtuals
for
everything.
D
G
G
G
M
G
A
Yeah,
but
you
can
get
this
the
single
span,
usually
without
too
much
trouble
of
things,
but
that's
still
doing
a
lot
of
cheating
a
two.
A
two
span
is
more
complicated
okay,
so
I
think
we
got
these
worked
out
so
now,
single
buffer,
async.
A
A
A
But
again,
this
is
this
is
a
really
special
case,
though,
because
this
is
really
low
level
yeah,
the
so
like
we
have
it
in.
I
async,
dispose
and
steve
said
that
there
was
a
very,
very
good
reason
that
was
probably
invalidated
the
moment
that
we
wrote
what
the
correct
pattern
is
to
deal
with
the
fact
that
your
type
could
have
a
finalizer
involved
in
it.
A
A
G
A
G
A
G
K
It
wasn't
the
idea
of
value
task,
I
mean
originally,
we
didn't
have
video
tests
because
the
deal
was
you
can
just
you
know,
cache
the
task
instance,
so
you
don't
pay
for
the
allocation
most
of
the
time,
but
then
we
added
value
tasks
for
the
case
where
you
can
optimize
the
asynchronous
completion
going
for
your
own
infrastructure
and
that's
super
rare
yeah,
but
and
I
think
for
io.
We
ended
up
doing
it
in
some
cases
for
pipelines
and
others
yeah.
D
So
basically,
you
know
the
pattern
is
read:
wait
for
completion,
read,
wait
for
calculation,
we
read
wait
for
completion
and
therefore
we
reuse
the
same
effectively
async
state
like
task
state
for
each
read
and
we
we
actually
cache
it
on
the
on
the
socket
object
itself
and
same
for
right.
I
don't
know
if
that's
true
for
this
case.
L
So
we
have
recently
added
that
sorry,
we
have
recently
added
I
value
task,
source,
optimization
and
caching
of
it
to
five
stream,
and
it
works
only
when
you
have
a
single
read
or
write
at
the
same
time,
but
this
particular
api.
We
wanted
it
to
be
safe
and
to
make
it
possible
to
use
in
parallel.
However,
in
the
comments
even
suggested
that,
if
we
use
a
value
task,
we
can
always
add
caching
of
ivar
test
sources.
If
we
use
tasks,
we
cannot.
A
G
A
Oh,
that
too,
but,
like
you
said
it
not
me,
I
would
say
available
at
quality
bookstores,
but
that's
always
a
demeaning
thing,
because
it
means
the
one
that
doesn't
have
it's
not
quality
and
I
went
to
a
brick
and
mortar
bookstore
during
a
pandemic
and
was
disappointed
to
see
that
my
book
was
not
on
their
shelf.
A
A
Anyway,
all
right,
so
now
we've
done
this
pair,
so
now
reads
scatter
at
offset
async,
which
should
be
easy,
because
I
think
now
this
one's
right,
this
one's
a
memory,
because
it's
an
async
operation,
this
one's
a
memory
because
it
has
to
be.
G
So
does
this
well
one
of
the
scenarios
I
mentioned
earlier.
Is
you
have
a
list
of
memory
of
byte,
for
instance,
and
you're,
trying
to
populate
that
list
of
buffers
you
would
not
be
able
to
pass
such
a
thing
to
this
without
making
coffee
is
that
okay,
probably.
A
G
I
I
guess
I'm
I'm
thinking
back
to
what
I
think
it
was
justin
earlier
about.
Is
the
implementation
always
going
to
make
a
copy
anyway,
just
out
of
necessity,
and
if
so,
is
it
just
easier
to
have
span
of
memory
as
the
as
the
type
being
passed
in?
A
Let's
say
we
actually
write
something
correctly
on
stream
for
once,
and
we
use
the
template
pattern
to
deal
with
all
the
argument
or
the
the
sensible
argument,
validation
that
we
can
do
and
then
defer
to
a
core
method.
If
we
take
a
span
anywhere
in
that
method,
the
core
method
itself
can't
be
declared
async,
it
would
have.
Everyone
would
have
to
write
their
core
method
as
copy
it
into
something.
That's
not
a
refstruct
and
now
call
a
method
that
uses
the
async
keyword,
because
you.
D
A
A
J
D
Obviously
we
don't
want
to
use
the
array
segment
but-
and
I
think
I
list
I
read
only
this
is-
is
clearly
better
than
I
list
but-
and
I'm
not
sure
I
read
only.
This
is
all
that
great
either,
but
it
does
give
you
more
flexibility
in
what
you
can
pass.
L
A
A
A
A
G
A
But
we
are
trying
to
suggest
what
we
think
that
it
this
would
look
like
when
we
add
it
to.
What's
that
thing,
string
stream,
I
can
enunciate.
G
Its
own
type
and
extent,
like
extension
methods-
I
don't
know
like
that-
it
seems
weird
to
me
to
have
a
safe
handle
class
itself
responsible
for
anything
other
than
handle
management.
Normally,
operations
on
that
handle
are
the
concern
of
someone
else,
but
again
like
that's
just
maybe
me
being
too
much
of
a
viewer.
L
L
But
on
the
other
hand,
then
you
need
to
somehow
take
care
of
making
sure
that
people
can
find
out
that
these
methods
exist,
because
last
time
we
have
discussed
introducing
a
new
type.
There
was
a
lot
of
pushback
in
perfect
work.
We
would
have
two
separate
types.
One
would
be
for
synchronous,
another
for
asynchronous
yeah.
G
Well,
if,
if
you
have
scenarios
where
you
need
to
query
the
handle
and
then
store
that
information
such
as
was
my
handle
opened,
you
know
synchronously
or
asynchronously
blah
blah
blah,
but
you
don't
really
have
a
good
place
to
store
that
information
here
without
actually
expanding
safe
file
handle
itself.
Oh
and
now
what
happens?
If
someone
gave
you
their
own
save
file
handle
like
you're
mutating
the
instance
they
gave
you
like.
G
That
seems
like
a
violation
of
ownership
principles,
so
that
could
be
an
argument
for
just
making
a
brand
new
type
that
you
wrap
around
a
safe
file
handle
and
say
that
type
is
responsible
for
whatever
caching
needs
to
take
place.
A
A
None
of
them
are
modifying
the
the
file
handle,
at
least,
I
think
that's
supposed
to
be
the
intent.
The
the
underlying
like
if
you're
doing,
freed
or
fright,
the
the
seek
position
of
the
fp
won't
have
changed
right
right.
So
the
these
aren't
modifying
the
file
handle
they're.
Just
we're.
Simplifying
the
like
overlapped,
io
dot
read
at
offset
save
file
handle
comma
buffer
comma
offset.
It's
like.
G
L
I
A
Right,
but
if
it
sounds
like
you're
saying
you
just
have
a
lazy
property
on
say,
file
handle
that's
non-public
and
when
in
when
anything
needs
to
use
the
safe
file
handle
to
make
a
decision,
you
just
say,
oh
go,
ask
is
async,
and
now
you
do
the
you
do.
The
one
call
to
ask
windows
is
this
save
file
handle?
Was
it
opened
in
async
mode?
Save
that
answer
like
technically,
yes,
you've,
mutated
the
object,
but
you've
not
violated
any
publicly
accessible
state.
G
L
L
L
L
K
Awesome
I
mean
that's
why
so,
let's
go
back
to
the
discussion
of
types
like
I
mean
I
personally
don't
think
that
this
capability
of
these
apis
is
the
biggest
problem
we
need
to
solve,
because
they
are
not
like
mainline
iowa
apis
right.
They
are
more
advanced
low
level,
apis
right,
so
they're
kind
of
similar
to
let's
say
some
of
the
io
enumeration
types
that
we
added
to
make
enumeration
more
efficient
right.
K
So
in
that
sense
it's
not
the
most
important
thing
to
me
that
they
are
like
super
prominent,
but
also,
I
would
say,
even
if
you
put
them
on
sci-fi
handle,
I'm
not
sure
they
are
more
prominent
there,
because
people
like
today,
the
save
file
handles,
are
just
basically,
you
know
handles
you
pass
around.
You,
don't
really
do
anything
with
them
like
in
poke
methods
on
them.
So
I
personally
like
the
original
proposal
that
jeremy
you
know
had
from
the
last
api
review,
which
is
just
a
separate
type
but
they're
all
aesthetics.
K
I
mean
the
other
benefit.
Is
that
if
we
ever
need
some
other
argument
where
we
don't
want
to
pay
for
the
file?
And
we
want
to
have
it
in
ptr
or
something
we
can,
because
it's
just
a
static
overload
in
this
design,
it's
a
bit
weird
to
have
no
static
method.
That
would
take
an
in
ptr
right
like
so.
You
kind
of
tie
yourself
to
the
model
that
can
only
be
effectively
driven
off
of
say,
a
fire
handle,
but
maybe
that's
okay,
but
I
will
probably
still
put
them
on
a
separate
side.
L
Right
when
it
comes
to
that,
I
just
posted
a
link
to
api
that
we
have
already
approved
last
year
that
is
working
on
safe
handles
that
was
initially
proposed
as
a
list
of
extension
methods
for
setting
and
getting
creation,
time
last
access,
time,
etc
and
back
then
it
was
decided
to
extend
the
system.io
file
class.
With
this.
D
D
It
seems
like
we
could
create
a
a
new
class.
That's
like
random
access
file
that
just
you
create
one
in
a
similar
way
to
how
you
create
a
file
stream,
and
it
has
these
instance
methods
on
it
and
under
the
covers,
it's
got
a
save
file
handle
and
it's
kind
of
like
final
stream,
except
it's
random
access
and
if
people
care
about
random
access,
they
go
use.
That
class.
L
B
L
L
So
last
time
we
so
the
last
time
exactly
the
situation
was
that
me
and
tanner
wanted
to
introduce
new,
primitive
types.
The
rest
of
the
meeting
wanted
to
introduce
a
new
type
that
would
be
allowing
for
safe
to
handle
methods
like
static
type
that
accepts
safer,
handle
as
the
first
argument
and
back
then,
we.
K
D
I
mean
that
seems
like
the
most
natural
way
to
use
this
and
I
like
just
to
emo
just
to
push
back
a
little
bit.
I
don't
think
these
are
super
low
level
methods.
I
think
they
are
less
common
than
positional
read
and
write,
but
like
if
you
just
write
like
native
win32
code,
it's
very
common
to
just
do.
You
know
offset
based
io
instead
of
position
based
io,
it's
a
lot
more
convenient
in
a
lot
of
ways.
It's
thread
safe.
D
K
Yeah
yeah
so
like
so
the
I
don't
have
an
objection
necessarily
to
how
widely
it's
used
right,
it's
more
the!
So
if
you
have
a
static
method
like
if
you
have
static
methods
right
and
you
have
a
static
type,
it
doesn't
really
matter
whether
you
put
it
on
safe
handle
or
not
you.
Basically,
what
you
do
is
know.
You'd
say
you
have
a
random
access
file.
I
think
it
was
the
original
proposal
right
or
what
you're
proposing
right
now
the
problem
is
now:
what
does
it
mean
for
the
rest
of
the
ecosystem?
Does
it.
K
Who
takes
a
stream
should
also
take
this
other
thing.
Do
we
want
that
like,
as
soon
as
you
have
static
helper
methods,
it's
kind
of
you.
B
K
Safe
file
handle
or
you
don't
right,
and
then
you
know
you
can
use
these
methods
or
you
can't
right,
but
I
think
the
problem
is
when
you
introduce
a
new
thing,
like
you
know,
a
random
access
file,
like
you
know
the
concern
I
have
some
people
say
like
how
do
I
convert
this
to
a
stream?
How
can
I
wrap
a
stream
in
this
or
whatever
right?
And
then
it's
like?
Well,
that's
really
not
what
the
intent
for
this
api
is
right.
K
The
exchange
type
is
still
stream,
and
you
know
you
have
certain
scenarios
where
you
want
more
lightweight.
I
o
and
or
you
know
I
o-
that
is
maybe
more
convenient
for
your
particular
algorithm,
and
then
you
use
this
other
thing
over
there
right.
But
to
me
it's
kind
of
weird
to
say:
we
put
a
new
top-level
type
and
system
io
as
a
primitive
type,
because
then
it
does
compete
with
basically
stream
or
file
stream
and
and
then
you
might
constantly
just
create
a
mess
in
the
api
surface.
Some
people
now
only
take
the
new
one.
K
L
D
L
K
Yeah,
I'll
be
honest,
like
I
mean
to
me,
stream
is
kind
of
maybe
not
the
best
place
to
put
them
for
two
reasons.
One
stream
already
has
a
ton
of
methods
right,
so
it's
basically
like
a
drop
in
the
bucket
when
you
try
to
find
them
now
and
then
the
other
fall
in
the
stream
is
already
fairly
complicated
and
heavy
weight
to
begin
with.
So
I
and
then
also
stream,
is
not
the
most
efficient
type
to
begin
with
either
right.
So
I.
G
G
L
L
D
I
will
say
this
is
counter
to
to
sort
of
the
the
existing
state
of
net,
but
when
I
think
about
file
access,
I
think
random
access
is
actually
more
fundamental
and
positional
access
is
something
you
that
can
be
built
on
top
of
that.
So
if
we
were
starting
from
scratch,
I
would
actually
say
the
exchange
type
should
be
random
access
file
and
then
you
could
get
if
you
wanted
to
get
a
stream
from
that
that
has
positional.
I
o
there
would
be
like
a
get
stream
method.
D
K
K
Now
have
to
create
a
fake,
you
know,
file
that
is
basically
an
in-memory
buffer
like
now
you're,
basically
incurring
potentially
even
more
cost
right.
So
I
think,
like
I
think,
if
I
think
in
the
context
of
like
when
you
use
file
stream
as
an
exchange
type,
then
yes,
this
thing
could
be
the
exchange
replacement
right.
K
But
if,
if
the
exchange
type,
today's
stream-
which
is
I
don't
care
what
it's
backed
by
then
it's
probably
not
the
right
replacement,
but
it
would
probably
compete
with
let's
say
string
paths
right
where
you
say:
well,
you
don't
do
that
right.
You
just
basically
either
take
a
path
or
you
take
a
stream
or
you
take
whatever.
This
thing
is
right,
so
it's
a
trade-off
right,
so
the
in
in
in
the
sense
that
it
kind
of
depends
on
the
the
actual
api.
K
Where
you
talk
about
this,
but
I
don't
know
like
I
mean
if
we
really
think
like
I
mean
honestly
like
we
have
an
instance
type
for
enumeration
right,
you
just
put
it
in
its
own
namespace,
you
new
it
up.
You
walk
the
directory
structure
and
it's
fine.
It's
an
alternative
to
basically
the
I
o
directory
and
with
the
directory
info
objects
right,
but
they
are
not.
I
don't
know
they're
not
that
exchanging,
but
you
don't
really
pass
them
around
that
much
right
versus
streams
are
passed
around
a
lot.
K
D
I
I
hear
you,
this
is
just
a
random
question,
but
do
we
think
we
would
ever
want
positional
api
for
in-memory
buffers?
You
kind
of
mentioned
that,
as
you
were
saying,
would
I
want
like
the
equivalent
of
read
it
offset
for
memory
stream.
G
Well,
memory
streams
also
backed
by
a
single
contiguous
buffer,
so
you
can
always
just
get
the
vacuum
buffer
and
then
slice
it.
You
can't
always
get
the
buffer
in
in
99
percent
of
cases.
D
My
point
is
that
there
is
an
abstract
notion
of
of
random
access
here
that
do
we
ever
think
that
we
want
to
promote
that
as
an
abstraction
that
so
that
you
could,
for
example,
write
code
that
could
work
against
either
a
random
access
file,
io
or
a
random
access
memory.
Io
or
I
don't
know-
maybe
there's
another
instance
of
that
up
there
somewhere.
But
those
are
the
two
that
come
to
mind.
A
I
wasn't
part
of
net
in
the
1-0
or
in
the
cool
days,
which
is
probably
when
it
really
would
have
mattered,
but
the
and
for
those
who
don't
know
that
would
be
c
object-oriented
language
not
like
we're,
not
cool
anymore.
The,
like
of
do
you,
make
seekable
stream,
be
a
different
type,
that's
somewhere
in
the
hierarchy,
because
these
are
all
like,
basically
seekable
stream
notions,
and
then
you
know
when
we
start
when
we
look
at
what
we
have
now
when
we
say
well,
file
stream
is
a
seekable
stream.
A
It's
well
file
stream
is
usually
a
seekable
stream
pipes.
We
represent
as
file
streams
and
they're,
not
seekable,
and
so
we
we
do
have
this
notion
of.
Like
you
know
yes,
memory
stream
is
seekable
memory
stream.
You
can
get
usually
get
the
backing
memory
and
you
could
do
random
access
if
you
wanted,
but
really
it's
memory
stream
is
special
file.
Stream
is
sometimes
special,
because
file
is
different.
I
agree
with
your
point
jeff
that
we
would,
if
we
were
starting
over,
we
would
probably
make
random
access
file,
be
a
primitive
and
build
file
stream.
A
On
top
of
that,
but
honestly,
the
proposal,
as
is
currently
written
is
saying,
say:
file
handle,
is
random
access
file
and
if
we,
if
we
were
all
happy
with
saying
that
their
instance
methods,
that's
basically
what
it
says.
The
notion
since
emo
reminded
me
that
I
thought
of
it.
Apparently
that
sparked
the
thought,
with
the
file
operations
static
class,
the
the
benefit
there.
A
We
could
make
things
be
extension
methods
off
of
save
file
handle,
but
the
the
benefit
would
be.
We
could
overload
them
within
pitter.
So
if
you
have
the
handle
instead
of
the
safe
handle
that
you
could
call
those
there
and
then
that
would,
depending
on
what
you're
doing
and
whether
you
like,
knowing
that
you
already
have
a
handle,
that's
not
going
to
get
closed
out
from
under
you,
etc.
Then
you
get
to
avoid
the
ad
ref
and
release,
but.
L
Yeah,
but
within
ptr,
all
of
the
five
stream
constructors
are
obsolete,
that
accept
it,
and
also
we
don't
have
the
information
whether
given
handle
was
open
for
async,
io
or
not,
and
we
just
have
to
perform
a
cisco
to
find
out.
So
we
would
actually
always
have
to
perform
a
cisco
if
we
were
accepting
in
the
ptr
good
for
a
high
performance.
A
A
K
Yeah
I
mean
I
actually
like
the
proposal.
Like
I
mean,
I'm
not
sure
I
like
the
name
file
handle
operations,
but
I
do
like
the
idea
of
a
static
class
in
the
iowa
namespace.
I
think
that
would
probably
be
you
know:
decently
discoverable
and
still
you
know
fairly
lightweight
and
simple
to
work
with.
I
will
probably
try
to
have
a
shorter
name
because
the
otherwise
it
just
gets
long
long-winded,
but.
A
Yeah
so
before
we
quite
get
to
there,
I
noticed
you
have
some
exceptionally
things.
Personally,
I
disagree
with
your
exceptionally
things.
A
L
Yeah,
but
the
problem
is
that
currently
we
do
a
lot
of
workarounds
to
make
five
stream
support,
async
and
sync
methods,
no
matter
if
they
were
opened
for
async,
I
or
sync
io,
and
just
to
give
you
an
example.
If
you
open
five
stream
for
async
io,
and
you
call
synchronous
method,
then
what
we
do
internally
is
dot,
get
awaiter.get
result
which
kind
of
sucks,
and
here,
with
the
new
api
that
is
supposed
to
target.
L
You
know,
people
who
want
high
performance
think
they
know
how
to
use
low
level
apis
because
so
far
they
were
switching
to
lower
level
languages.
I
would
expect
that
they
will
be
fine
with
this
limitation.
You
have
to
play
with
the
rules
like
it's
open
for
async.
It
allows
only
for
async
it's
a
pipe.
We
cannot
provide
offset
operations,
withdraw.
D
Especially
because
it's
not
an
exchange
type
right,
I
mean
stream
is
an
exchange
type,
and
so
you,
you
can't
say,
oh
my
stream
just
doesn't
support
the
same
methods.
You
have
to
do
something
there,
because
somebody,
because
we've
told
people
that
streams
support
sync
methods,
but
if
it's
not
an
exchange
stack
then
does
it
matter.
B
K
And
the
only
the
only
thing
I
would
I
would
add
to
that-
is
I'm
okay
with
that
behavior?
The
only
thing
I
would
say
is:
whatever
property
you
have
on
safe
right
handle
that
will
tell
the
caller
whether
this
will
succeed
or
not
should
be
made
public,
so
the
caller
should
be
able
to
say
you
know.
Can
I
call
this
api?
It's
a
pretty
bad
experience.
If
you
have
to
take
a
file
handle
and
just
you
know,
call
the
method
and
hope
for
the
best
right.
K
I
mean
exposing
this
async
property
on
file.
Handle
to
me
makes
sense
because
it's
still
describing
the
handle
right.
So
logically,
it
is
part
of
the
handle
already
it's
just
you
know
you
have
to
basically
ask
the
os
to
figure
this
out
versus
working
methods
that
do
stuff
generally
don't
exist
on
handles
right,
like
handles,
are
usually
just
things
you
pass
around,
but
you
don't
actually
invoke
anything
on
them
like
like
in
a
like
in
in
a
weird
sense
like
handles.
H
I
H
Oriented
so
logically,
the
handle
is
just
the
this
pointer,
and
so
therefore,
if
you
map
that
back
to
an
object-oriented
language
like
c
or
c
or
like
c,
sharp
or
c
plus
plus,
then
logically,
you
have
a
struct
that
simply
wraps
that
handle
and
exposes
everything
passing
the
handle
field.
As
the
this
parameter.
K
Like
things
on
handles
right,
because
usually
what
you
do
is
when
you,
when
you
deal
with
handles,
is
like
you
wrap
the
handle
in
something
else
that
becomes
your
this
pointer
right,
like
I
mean
like,
like
a
form,
has
a
handle
right
or
or
a
file
stream,
has
a
handle
right,
but,
like
you,
don't
really
invoke
anything
on
that
handle
right.
So
that's
why
I
mean
it
seems
a
bit
weird
to
expose
operations
on
a
handle.
H
I
think
that
also
depends
on
if
you're
talking
about
the
higher
level
concepts
that
most
people
work
with
or
the
low
level
concepts.
It's
not
uncommon
in
interop
libraries
to
have
your
handle
expose
most
of
the
p
invokes
as
simple
extension
wrappers
that
ultimately
just
pass
in
the
the
this
parameter
as
the
handle
and
then
the
rest
of
the
parameters
that
way
it's
simpler
to
use.
H
G
Yeah
generally,
the
way
that
we've
treated
this
is
that
the
handle
is
the
unit
of
resource
management,
and
that's
it.
The
handle
doesn't
have
any
other
response,
like
literally
no
other
responsibilities.
Aside
from
that,
everything
else
is
built
on
top
of
it,
at
least
that's
traditionally
how
we've
approached
us,
I
mean
we
could
always
invent
a
new
system.
K
G
K
G
Yeah,
it's
the
the
reason
that
we
haven't
done.
That
is
that
they,
once
you
start,
including
actual
logic.
Now
you
have
policy
now
you
have
behaviors
that
might
need
to
change
over
time,
things
that
are
not
directly
related
to
resource
management,
which
is
fixed
for
all
time.
Generally
speaking,.
K
Yeah
so,
like
I
mean
I
don't
know
like
I
mean
given
that
this
is
still
somewhat
of
an
expert
api,
I
don't
expect
the
basketball
customers
to
use
them.
I
would
hopefully
expect
more
low-level
code
or
a
performance
yeah
cool.
That
really
cares
about
follow-up
to
use
it,
but
it's
kind
of
like
some
of
the
spanning
apis
in
the
sense
that
you
know
you
know
you
have
to
deal
with
memory
and-
and
you
know
span
so
it's
it's,
probably
not
the
vast
majority,
so
I
can
probably
live
with
any
design.
K
K
G
I'm
looking
through
some
existing
apis
and
the,
I
guess,
the
big
outlier
that
the
big
api
that's
an
example
of
where
the
handle
itself
actually
does
stuff
is
safe
buffer.
G
Buffer
is
itself
a
safe
handle
and
it
has
read,
write
whatever
methods
hanging
off
of
it.
But
beyond
that,
I
can't
really
think
of
any
examples
where
handles
expose
anything
other
than
like
acquire
and
release
methods.
A
K
K
A
Is
invalid
is,
should
the
ref
count
going
to
zero
call,
release
handle
or
not
is
closed
is
describing
whether
the
safe
handle
itself
is
no
longer
capable
of
being
passed
through
a
p
invoke
and
like
those
are
all
about
safe
handling,
the
marshaller
they're,
not
about
yeah
those.
K
A
Application,
the
yeah
so
the
worker
methods
being
on
safe
handle.
I
I
can
definitely
agree
with
the
we
haven't
done
it
before,
and
it
is
a
little
weird
because,
as
levi
pointed
out
generally
the
the
safe
handle.
What
it's
describing
is
like,
I'm
I'm
tracking
this
resource.
You
can
upref
me
you
can
down
ref
me,
you
can
pass
me
through
a
p
invoke
and
I'll
I'll
manage
that
for
you,
but
otherwise
I'm
an
art,
but
basically
I'm
just
an
argument.
Well
that
was.
G
A
A
Oh
all
credit
tanner
appropriately,
all
right,
sorry,
tanner
the,
and
so
you
know
that
means
move
these
somewhere
else
now,
if
we
move
them
as
static
methods
on
a
static
type,
there's
then
now
the
room
that
they
become
extension
methods.
I
don't
see
a
good
way
of
searching
anything
to
ask
if
there
are
extension
methods
that
are
operating
off
of
safe
handles
that
make
them
look
like
they
have
this
kind
of
thing.
A
So
I
don't
know
if
that
would
be
precedent
or
not,
certainly
making
it
be
a
static
method
that
you
have
to
pass
it
as
a
formal
parameter
solves
that
problem.
A
I
I
agree
with
emo
that
adding
something
like
random
access
file,
which
is
just
the
type
that
wraps
the
safe
handle
to
provide
these
operations,
does
start
to
create
an
api
bifurcation
thing,
and
that
really
we're
saying,
if
you're,
using
this
at
the
handle
level,
use
it
at
the
handle
level,
but
otherwise
take
a
stream
or
a
path
or
whatever.
So
I
don't
think
I'd
go
with
an
a
new
instance
type.
L
K
I
mean
it
depends
right.
Like
I
mean
the
question,
is:
do
you
dot
into
a
file
handler
right?
That's
kind
of
the
assumption
that
people
are
doing
that.
I'm
not
sure
that
is
always
the
case,
because
I
mean
like
today.
There
really
isn't
anything
useful
on
those
things
right.
It's
not
it's
not
a
place
where
you're
very
likely
to
look.
K
I
think
extension
methods
are
more
useful
on
times
people
already
got
into
right
because
that
you
basically
have
advertising.
You
know
air
time
right
versus.
K
If,
if
you
introduce
something
new-
and
I
would
argue
even
if
you
just
you
know,
went
through
you
know
the
trouble
of
like
finding
like
you
know
something
somewhere,
then
sure
it
makes
sense
but
like
if
you
I
don't
know
if
you,
if
you
write
code
today
and
you're,
not
actually
likely
to
like
look
into
a
save
file,
handle
you're,
probably
more
likely
to
look
in
the
name
spaces
around
you
like
what
other
operations
exist
right.
So
I
don't
know
I
I.
I
don't
think
that
many
people
will
try
to
go
into.
K
K
A
A
Random
access
that
read
it
offset
memory
stream,
comma
buffer,
come
off
that,
like
whatever
means
that
maybe
we
should.
L
A
L
L
K
G
L
K
A
Fair
enough,
it
just
means
that
the
memory,
if
we
overloaded
read
it,
offset
to
take
a
memory
stream
as
the
thing
it's
reading
from
then
it
would
then
rename
file
offset
to
something
else,
so
it
would
be.
Oh,
it's
a
group
overload
renames
a
parameter
to
match
the
context,
at
which
point
we
should
have
been
more
general
in
the
context.
L
D
G
A
Well,
I
mean
we
haven't
discussed
yet
whether
they're
extension
methods,
but
sure
I
mean
we
can
put
here
and
that
we
think
it's-
that
the
fileness
is
important,
that
really
we're
doing
the
same
concept,
but
slightly
renaming
the
parameter,
and
that's
probably
fine,
but
now
that
we're
like
do
we
want
do
we
feel
differently
about
you
long
now
that
we're
on
a
slightly
more
interface.
G
G
A
A
H
And
I,
I
honestly
think
that
we
should
have
done
on
span
extensions,
what
we
did
with
vector,
vector,
t,
vector,
128,
vector
128
of
t,
which
is
a
corresponding
type
without
the
generic
parameter.
That
lives
exactly
side
by
side
with.
G
Oh,
I
see
so
that
that's
talking
about
the
more
general
templating
rather
than
the
specific
issue,
yeah.
A
A
A
A
K
K
K
L
H
H
H
You
can't
actually
get
that
much
space,
but
the
if
the
underlying
native
apis
typically
take
you
long
and
so
at
some
point,
you're
having
to
convert
that
sign
type
to
an
unsigned
type,
anyways
right,
you're,
also
having
to
do
if
checks
for
negative
values
just
to
catch
the
case
of
a
negative
value
being
invalid
in
dot
net,
which
which
adds
overhead
and
it's
just
it's
consistent
using
signed,
is
consistent
with
the
rest
of
net
apis.
But
it's
also,
in
my
opinion,
terrible,
and
we
should
never
have
done
it
20
years
ago.
K
Yeah,
I
mean
I
mean
I
remember
like
the
winter
it
sort
of
the
win.
Rt
io
apis
do
yulongs
or,
I
should
say,
unsigned
types
I
think
some
of
the
stuff
is
also
in
based
and
it's
a
pain
because
of
the
way
doesn't
it
interrupt
tends
to
work
for
that
right
because
you
have
everything
as
ins
and
longs
today
and
now,
suddenly
you
have
to
call
someone
that
is,
you
know,
unsigned
into
unsigned
long
and
then
you,
you
know
end
up
costing
like
I
feel
like
the.
K
K
H
The
the
difference
tends
to
be
is
it
makes
the
life
of
low-level
and
perf
oriented
users
easier
and
with
this
being
a
low-level
and
perk
oriented
api
like
if
you
go
and
look
through
the
bcl,
almost
all
of
our
internal
algorithms,
take
the
take
array,
length
and
everything
else
and
immediately
convert
it
to
unsigned.
So
that
way
we
can
get
jit
optimizations.
That
can
only
happen
for
unsigned
types.
A
Yeah,
I
mean
again
the
the
the
other,
the
the
thing
that
usually
makes
it
weird
right
is
you've
taken
the
oh:
what's
the
you
know
length
of
the
span
that
I've
already
populated?
Well,
that's
an
end.
So
now
you
have
a
signed
end
and
now
you
need
to
move
up
into
now.
You
need
to
move
to
you
long,
so
it's
moving
from.
A
I
already
have
some
data,
which
was
probably
stored
as
a
signed
value
into
this
means
that
you're
you're
doing
the
conversion
there
again,
since
I
personally
don't
have
a
horse
in
the
cls
compliance
race,
I'm
fine
with
overloading,
and
if
you
have
the
yulong,
you
call
the
yulong
and
it
avoids
the
the
value
check
and
we
just
make
the
one
that
takes
a
long.
Do
the
if
negative,
throw
and
then
call
the
unsigned
one
like
whatever.
H
That
also
seems
fine
to
me.
I
know
that
if
we
ever
do
expose
native
span,
I
think
both
levi
and
myself
will
heavily
push
for
it
being
inuit
and
not
in
it
just
because
of.
L
Personally,
I'm
not
happy
about
adding
an
extra
overload
because
we
are
increasing
the
code
size
and
we
happen
to
care
about
it
recently.
So.
L
Yeah,
but
I
think
that
when
you're
dealing,
if
you're,
really
thinking
about
random
file
access,
you
should
be
thinking
about
unsigned
values,
because,
first
of
all,
you
want
to
obtain
the
length
of
the
file
if
you're
about
to
read,
and
then
you
know
divide
it
into
multiple
reads
and
just
do
a
simple
math
and
read
it
into
multiple
buffers.
The
same
goes
for
writing.
You
already
notice.
The
size
now
like
to
me
unsigned
is
the
natural
way,
but
I
get
the
point
of
you
know
having
cast
etc.
A
A
Just
because
we're
in
the
precedence-
and
you
know
we're
now
a
higher
level
thing
where
what
would
we
overload
it
for
for
memory
stream?
Well,
remember
if
we
had
an
overload
from
memory
stream,
it's
going
to
take
the
signed
value,
et
cetera,
in
fact,
for
memory
stream.
It'll,
probably
just
take
int
offset,
because
it
doesn't
make
sense
to
go
all
the
way
up
to
long,
but.
I
K
K
Yeah,
so
that's
funny,
so
when
you
subtract
an
in
from
a
yulong
c,
sharp
arrows
out
and
says
you
can't
do
that,
vb
actually
happily
accepts
it
and
converts
your
ulong
into
a
decimal
and
then
performs
the
operation
as
a
decimal
subtraction
and
gives
you
back
a
decimal.
So
I
mean
that's
kind
of
the
problem
with
unsigned
types.
K
Is
that
when
you
actually
use
them,
like
c,
has
a
different
kind
of
you
know:
conversion
rules
from
c
from
c,
sharp
and
v
b,
and
so
that
some
things
tend
to
work
quite
nicely
versus
other
things.
Just
really
get
people
surprised.
That's,
like
I
mean
that's,
usually
the
philosophical.
The
problem
with
the
you
long
debate
is
that,
like
are
you
in
it's
it's
not
wrong,
it's
just.
It
tends
to
not
work
super
great.
Like
I
mean
you
basically
end
up
very
often
with
like.
K
Oh,
you
have
to
cast
things
and
then
do
something
funky
right.
So
that's
that's
usually
where
the
problem
lies.
Now
will
I
fight
it?
No
do
I
think,
there's
a
problem
with
this
with
these
apis?
No,
it's
just
that!
That's
the
price
you
pay
for
this
right
and
right
I
mean
I
I
don't
know
whether
f-sharp
supports
them.
I
suppose
they
do.
Probably
they
just
you
know
they
have.
No,
they
have
no
implicit
conversions,
so
you
just
have
to
cost
more
or
even
more,
in
f
sharp.
H
That
that's
the
cost
that
almost
all
of
our
own
apis
pay
internally,
which
is
free
because
the
cast
from
inc
to
uint
is
free.
Any
time.
H
That's
right:
it's
perf
in
that.
If
you
don't
cast
unsigned,
then
the
jit
assumes
the
value
could
be
negative,
and
so
it
it
it
can't
do
certain
division
tricks.
It
can't
do
certain
shifting
tricks.
You
end
up
getting
sign
extensions
rather
than
zero
extensions.
H
Zero
extensions
are
free,
most
of
the
time
in
modern
cpus,
but
sign
extensions
aren't
right,
and
so
that's
why
all
of
our
own
code
internally
takes
all
of
our
sign
types
and
immediately
cast
them
to
unsigned,
and
so
I
I
don't
expect
most
public
code
does
that
external
to
us,
but
I'd
also
expect
that
most
external
code
to
us
wouldn't
be
using
these
apis
in.
H
H
Yeah
I'd
vote
for
I'd
vote
for
you
long
followed.
I
I'd
vote
for
both
followed
by
you
long
just
because
both
is
like
three
extra
lines
of
code
and
will
always
should
always
get
inlined
so.
L
A
K
K
K
L
A
Okay,
yeah
sure
that
would
I
had
taken
that
as
a
assumption
when
we
flew
past
it
previously.
Okay,
now.
L
E
A
K
H
I
think
that's
fine,
I
I
think
levi's
dropped
off,
but
he
was
the
one
that
pushed
back
against
the
handles,
exposing
anything
that
wasn't
really.
O
A
A
Typing
in
a
different
notepad:
okay,
I'm
I'm
typing
my
that
this
notepad
of
what
are
all
the
notes
about
the
things
that
we've
done.
O
A
H
I
would
prefer
them
to
be
extensions
because
I
think
it's
more
natural
to
just
do
handle
not
read
it
offset,
but
that
may
just
be
me
and
how
much
I
do
the
same
thing
with
interop
code
and
we
could
always
make
them
extension
methods
later.
If,
if
anyone
feels
strongly.
K
A
There
you
go,
the
single
operation
is
span
and
memory.
The
multi-operation
is,
I
read
only
list
of
memory
and
it
has
to
be.
I
read
only
list
of
memory
in
both
cases
because
span
can't
be
the
the
inner
generic,
but
we
concluded.
I
read
only
list
was
the
the
concept
of
the
multi-buffer
and
I
guess
there
is
technically
one
final
question
is:
do
we
care
at
all
about
the
other
thing?
What's
the
terrible
thing
sequence?
A
K
Would
add
is
that
I
just
realized,
get
length
returns
you
long,
so
I
think
we
just
have
to
make
our
mind
up,
because
offering
both
would
be
really
weird
like
get
length.
You
long
and
then
get
length.
Long
seems
like
a
weird
thing,
so
if
people
feel
super
strongly
that
we
only
should
have,
then
we
should
have
you
long,
then
that
would
just
keep
everything
you
long,
but
I
mean
offering
both
is
weird
when
length
can't
be
both
at
that
point,
it
seems,
like
you,
have
a
broken
api.
H
Yeah,
I
think
that's
more
odd
than
just
picking
one
or
the
other.
We
could
have
the
we
could
have
the
one
that
takes
you
long
return.
You
long.
K
Yeah,
I'm
talking
about
those,
I
think
the
ones
yeah
I
think
yeah.
I
think
it
was
copy
paste
mistake
on
on
jeremy
said.
I
would
expect
the
one
that
you
pass
in
the
year
long
you
get
back
too
long
on
the
one
you're
passing
along
and
get
back
along,
but
for
the
get
length
one
it's
weird,
because
you
have
to
pick
one
right.
K
A
K
K
Broken
api
no,
like
I
mean
I
think
we
should
make
up
our
minds
with
if
you
want
to
deal
with
unsigned
or
sign
but
like
it
seems
weird
if
we
accept
unsigned
but
then
return
signed
like
I
don't
know
like
that.
At
that
point
yeah,
maybe
I'm
missing
the
code,
but
it
seems
like
you
you're
very,
like
you
know,
because.
A
Because
if
you're
doing
like
so,
if
you
call
this
read
it
offset
right
right
and
you're
trying
to
fill
a
span
and
you
call
reed-
and
I
assume
that
this
is
allowed
to
do
partial,
because
that's
what
reads
are
always
allowed
to
do
the
value
you
get
back.
This
int
is
how
much
you're
going
to
slice
this
span.
A
H
Yeah,
the
the
the
other
thing
is
that
like
get
length
is
going
to
call
a
native
api.
That
native
api
is
going
to
return
a
year
long,
and
so,
if,
in
20
years
from
now,
we
actually
have
greater
than
64-bit
storage,
because
you
know
who
knows
maybe
or
maybe
maybe
we're
actually
doing
like
high
fidelity
game,
rendering
or
something.
H
Because
then
you
have
the
least
amount
of
concerns,
and
if
you
want
something,
that's
not
that
that
differs,
then
that
should
be
a
higher
level
abstraction
and
I
feel
like,
if
we're
taking
the
save
file
handle
directly.
That
is
not
a
higher
level
abstraction.
A
H
Right
and
that
would
be
required
to
account
for
the
fact
that
there
could
be
a
value.
That's
not
representable
returned
just
like
all
of
our
current
apis
that
return
int,
where
the
actual
underlying
native
type
is
unsigned.
They
have
to
account
for
that
today.
All
of
our
marshall
apis
have
to
account
for
that.
H
No,
I'm
I'm
saying
that
I'm
saying
that
the
high
level
abstractions
should
do
what
the
rest
of
net
does,
whereas
the
low
level
abstractions
should
more
closely
mirror
the
low-level
api.
So
low-level
abstraction
should
take
unsigned
types
where
the
native
side
takes
on
types,
and
so
therefore,
this
being
a
low-level
abstraction
should
take
unsigned.
K
L
I'm
currently
checking,
for
example,
then
the
method
that
obtains
length
on
windows
returns,
file,
underscore
standard
underscore
infrastructure,
and
here
the
end
of
file,
which
is
the
length,
is
defined
as
large
underscore
integer,
which
I
think
is
signed.
Yeah.
A
Signed
which
matches
more.neti
isms
and
then.
I
A
Makes
this
hard
like
basically
so
my
feeling
and
I'm
the
one
who
gets
to
highlight
things?
Is
this
the
the
end
the
signed
returning
signed
taking
thing
is
the
easiest
to
use
in.net
again,
if
you're,
if
you're
doing
a
multi-read
into
a
span,
you're
going
to
have
to
slice
the
span
based
off
a
signed,
integer
so
signed,
integers
are
gonna,
they're
gonna
be
in
your
loop.
A
Yes,
the
if
you
want
to
say,
but
I
know
that
I'm
calculating
the
final
offset
with
unsigned-
and
I
don't
expect
multi
reads
or
something:
why
am
I
paying
for
the
argument,
validation
and
that
it's
really
important
to
expose
the
you
long
one?
Then
we
can,
but
I
you're
still
gonna,
have
the
fact
that
this
return
value
is
more
to
me
is
more
closely
associated
with
slicing
this
span
than
it
is
with
moving
this
offset,
and
so
it
should
be
a
signed
return.
Even
if
the
api
is
inherently
returning
unsigned.
H
Because
looking
at
the
windows
apis
get
length
is
signed,
but
but
the
offsets
they
take
are
unsigned,
so
they
they
already
have
that
difference.
There.
M
A
So
my
preference
is,
we
get
rid
of
all
the
unsigned
things,
but
I
don't
care
a
whole.
K
K
K
Maybe
this
is
the
pick
one
right
yeah
I
mean
I
would
generally
probably
pick
what's
more
natural
in.net
because
it
seems
like
both
things
being
equal.
I
would
probably
then
pick
the
the
windows
one
out
of
habit,
but
it
seems
like
you
know
you
will
always
penalize
one
side.
You
might
as
well
penalize
the
the
side.
That
is,
you
know
the
more
odd
one
out.
K
A
K
I
mean
I
would
first
start
with
the
return
ones,
and
then
you
know
we
can
decide
that
we
say:
okay,
we
accept
the
mismatch
and
offer
evolve
or
just
one
and
because
it
seems
like
even
within
the
operating
systems,
there
is
mismatches
in
terms
of
return
and
what
what
they
take
right
windows
takes
unsigned
but
gives
you
back
signed.
H
Right
and
some
of
that
is
differences
in
the
philosophy
of
it-
is
it
always
from
the
beginning,
or
is
it
from
effectively
a
a
current
position.
F
O
A
A
Okay,
so
public
service
announcement
there's
a
pandemic
on
everyone
should
get
vaccinated
and
I'm
getting
mine
tomorrow
during
the
time
that
we
will
be
doing
an
api
review.
So
I
won't
see
you
at
10
a.m,
redmond
time,
but
other
people
will
no.
N
L
N
K
And
I
think
tomorrow
we
had
some
jason
stuff.
I
think
lomi
was
asking
me
whether
we
can
take
a
look
at
jason,
so
it's
unfortunately
not
marked
yet
here,
but
I
know
it's
blocking,
so
we
should
probably
take
a
look
at
it.
H
K
No,
I
know
it's
blocking,
because
people
keep
talking
to
me
about
it
so
like
it's
definitely
going
to
be
to
be
marked
one
way
or
the
other
so
and-
and
we
probably
need
the
rest
of
the
meeting
to
discuss
it
because
it's
super
complicated.
So
I
am
pretty
confident
that
that
will
just
fill
the
time
fair
enough.