►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello
friend
welcome
in
to
api
review
and
that's
as
much
german
as
I
know
we're
almost
out
of
the
red.
In
fact
we're
almost
done
with
issues
from
six.
If
these
are
all
easy,
we
might
actually
get
to
like
theoretical
future.
Today,
I'm
not
holding
my
breath
all
right,
we're
in
the
red.
I've
done
something
funny
that
no
one
laughed
at.
B
Good
morning,
everyone,
so
before
anything,
can
you
click
on
the
link
at
the
very
top?
It
will
take
you
to
the
updated
api
yeah
there
you
go
so
we
recently
got
some
apis
approved.
That
would
allow
us
to
create
symbolic
links
and
retrieve
linked
target,
and
we
had
a
very
interesting
discussion
after
this
approval
with
a
few
additional
requests
and
that's
what
we
would
like
to
propose
today.
B
B
The
was
mentioned
by
eric
sanjan,
where
we
would
not
have
an
easy
way
to
retrieve
the
relative
path
of
a
link
if
the
user
creates
a
link
with
a
relative
path,
if
we
use
whether,
if
we
use
full
name
or
tostring
well,
full
name
is
going
to
give
us
a
fully
formed
path,
fully
a
rooted
path
and
even
worse,
it's
going
to
return
it
with
the
pre,
with
the
prefix
of
the
location
where
the
assembly
of
the
app
is
located
and
tostring
doesn't
seem
to
be
reliable.
B
B
Those
are
the
two
main
requests.
There
was
a
third
one
where,
but
we
didn't
reach
enough
consensus.
We
wanted
to
try
to
expose
the
via
and
enum
all
the
different
types
of
symbolic
links.
B
So
not
not
sorry,
they're,
all
the
types
of
links
on
linux.
We
only
have
symbolic
links,
but
on
windows
we
have
repairs
points
which
then
are
subdivided
into
repair
stacks
and
we
were
suggesting
to
come
up
with
an
enum
that
lists
all
the
repairs
points
and,
coincidentally,
there's
one
called
symbolic
link
which.
B
I
mean
it
could
optionally
be
used
by
linux,
but
it
wouldn't
be
necessary,
but
it
will
resolve
the
problem
on
windows
where
it's
not
currently
possible
to
determine
what
kind
of
repair
stack
a
repo
reverse
point
has
so
yeah.
That
was
the
optional
one
and
it's
it's.
C
C
Right
and
so,
and
we
return
that
through
file
system
info
normally
and
you're
saying
the
way
people
would
then
get
you
know,
the
actual
absolute
path
is
normally
by
calling
to
string
of
the
file
system
info,
but
you're,
saying
that's
weird
and
not
really
what
people
would
expect.
That's.
Why
you're
proposing
the
string
based
api
right.
B
C
So
if
we're
like,
I
guess
my
question
is:
it
seems
a
bit
weird
that
when
I
say
get
link
target
and
then
the
result
is
not
null
and
there
and
I
get
full
name
that
I
get
a
different
answer
when
I
call
get
link
target
path.
It
gives
me
a
string
right
that
that
discrepancy
seems
odd,
why,
I
said,
say
a
full
path
right.
C
D
D
A
About
the
link-
and
I
imagine
get
link
target
is
always
if
you
do
get
link
target-
that
two
string
is
probably
always
going
to
be
a
rooted
path
because
you're
probably
just
going
to
do.
I
guess
it
would.
If
you
had
a
relative
path
to
the
original
sim
link.
You'd
have
a
relative
path
to
the
final
one,
but
like
you're,
just
going
to
pat
that
combine
it
so.
C
B
No
full
name
is
supposed
to
always
be
rooted.
The
workaround
was
to
see.
E
B
String
was
going
to
give
you
the
relative
path,
but
we
realized
it
wasn't
doing
that
all
the
time,
especially
during
enumeration.
F
B
G
E
G
Get
text
or
get
link
definition
where
get
link
value.
G
D
D
Yeah
well,
this
I
was,
we
were
thinking
originally
to
make
this
a
property,
so
it
will
be
called
link
target
path,
but
the
thing
with
that
is
that
I
think
there
was
some
expression
from
some
folks
in
the
thread
that
the
property
will
not
reflect.
I
mean
in
order
in
order
to
get
the
target
pad,
you
will
need
to
make
a
a
c
scout.
That's
gonna
need
the
pack,
and
you
also
have-
and
you
also
for
the
file
for
the
rest
of
the
info
on
the
file
system.
D
You
call
like
the
metadata
like
last
right
time
and
things
like
that.
You
also
need
to
do
another
cisco
with
the
same
path.
So
the
the
react
with
that
was
that
when
you
do
two
c
skills
using
path,
you
are
gonna
you
might
want.
You
might
end
up
like
returning
different
info
from
different
files.
If
the
file
like
change
between
the
between
the
two
calls,
so
we
wanted
to
make
this
like
a
method.
In
order
to
reflect
that
we
are,
we
are
actually
doing
the
cisco
like
to
make
it.
F
D
D
C
I
think
I
don't
know
like
when
you
enumerate
the
file
system,
given
that
virtually
nothing
we
have
is
snapshot
based,
like
things
can
change
all
the
time.
So
I
think
whether
you
have
methods
or
properties
does
not
make
a
huge
difference.
The
reason
why
I
suggest
the
property
is
more
like
because
then
we
can
come
up
with
a
naming
convention
that
puts
this
other
thing
kind
of
next
to
full
name
or
name.
So
it's
a
bit
more
obvious
that
you
know
it's
a
bit
more
discoverable.
If
you
have
a.
C
Just
shows
up
in
a
completely
different
spot
so,
like
I
guess
it
depends
on
how
important
it
is
for
people
to
actually
find
that
api
right.
D
Yeah
yeah
actually
reach
out
to
jeremy
and
to
other
places-
and
I
think
I
mean
this
concern
about
doing
multiple
cisco's
with
the
pad-
is
not
really
something
that
we
should
avoid
because
file
system
info
changes
like
I
mean
what,
whatever
you
get
from
a
fancy
to
me,
which
just
not
is
just
a
snapshot
of
the
file
system
at
that
point
in
time
to
where
you
call
it.
So
it
really
is
not
it's
not
really
a
problem.
C
I
mean
it
seems
to
me
like,
when
you
call
get
symbolic
link
target
at
the
first
place
or
get
linked
target
when
you
construct
the
file
system
info.
It
seems
like
you
can
retrieve
that
information
at
that
point
and
pass
it
to
the
file
system
and
for
your
returning
right,
so
you
so
it
will
be
fixed
for
the
you
know.
As
far
as
the
user
is
available
to
observe
it
right.
B
Right,
we
could
also
make
this
property
behave,
the
same
way
as
the
other
properties
like
attributes
where
we
have
to
call
refresh
if
we
want
to
get
the
latest
data
of
the
file
or
even
determine
if
it
still
exists
so
right,
yeah.
C
B
C
Yeah,
whether
it's
one
or
two
calls
in
my
opinion
does
not
make
a
huge
difference,
because
I
mean
none
of
these
operations
are
exactly
cheap
right,
I
mean
you
will
hit
the
disk,
so
yeah
it's
going
to
be
io
and
if
this
happens
to
be
very
slow,
you're,
probably
screwed,
no
matter
what
okay,
but
I
mean,
I
think
to
me
it's
more
like
the.
I
have
no
idea
how
important
some
people
to
get
the
actual
original
relative
path.
I
would
think
most
people
probably
don't
care,
but
if
you
actually
run
into
issues,
then
it's
nice.
B
It
was
a
big
request
to
be
able
to
access
the
relative
path.
It's
important,
especially
if
you
move
a
folder
containing
multiple
files
from
one
location
to
another.
You
want
to
preserve
the
relative
paths.
B
C
It's
I
see
so
when
you
want
to
create
basic
new
links,
you
want
to
take
the
value,
as
is
so
you
don't.
C
That
makes
sense,
yeah
yeah,
that's
a
good
point.
I
mean
at
that
point
and
it
is
a
bit
weird
you
should
I
mean
whether
you
make
the
method
or
not.
I
I
would
suggest
come
up
with
some
name
that
puts
it
somehow
next
to
full
name
or
name.
So
it's
I
don't
have
a
great
suggestion,
but
like
something
that
kind
of
conveys
the
relative
nature,
but
also
makes
it
clear
that
that
only
makes
sense
for
links
right
so.
H
A
Unresolved
link
target
like
there,
we
go,
that's
actually
what
it
is.
It's
if
we
stick
with
target
from
whatever
the
the
argument
name
is
from
make
link
or
ln
it's
it's
the
unresolved
link
target
yep,
that's
actually
a.
G
C
F
A
B
Target
if
it
stays
like
a
method,
I'm
in
favor
of
keeping
the
word
target
somewhere,
it
would
make
sense
both
on
windows
and
linux.
For
symbolic
links,
especially
the
word
link,
is
also
generic
enough
and
would
be
would
make
sense,
considering
the
other
method
is
going
to
preserve
the
word
link
as
well,
and
it's
not
symbolic.
B
D
B
C
C
C
Yeah,
I
think
the
idea
was
when
they
are
protected
in
their
past
case,
because
they're
visible
outside
of
the
type
right,
because
they're
visible
to
the
right
types
they're
effectively
like
public,
I
mean
it's
a
bad
design
right.
You
should
not
have
protected
fields
to
begin
with,
but
right
anyway,
so.
C
A
Was
then
going
to
ask
the
is
the
null
ability
correct
on
it.
B
If
the
current
file
system
info
is
representing
an
actual
file,
not
a
link
link
target
is
supposed
to
return.
No,
but
when
you
get
the
link
target
and
on
that
link
target,
I'm
talking
about
the
resolved
link
target
that
is
returned
by
the
method.
Above
then,
you
have
a
file
system
info
wrapping
an
actual
link,
and
if
you
call
link
target,
then
you
get
the
actual
string
where
it
where
it's
pointing
so
yeah
no
could
be
like
an
acceptable
way
to
address
this.
C
F
F
D
Mean
I
think,
we're
already
mostly
done,
but
most
most
most
folks,
where
else
is
present,
concerns
about
the
create
symbolic
link.
Name
like
it's
create
us
symbolic
link,
so
they
were
suggesting
if
we
could
drop
the
ass.
B
We
use
the
word
as
in
the
middle
so
because
we
are,
we
already
have
a
file
system
info
representing
a
file
that
has
not
been
created
yet
so,
whether
either
you
create
it
as
a
normal
file
or
you
create
it
as
a
symbolic
link
and
in
the
case
of
the
file
and
directory
static
methods,
well,
they're
static,
you
know,
have
a
an
object.
A
C
Yeah,
the
compiler
won't,
let
you
so.
I
think
it
will.
A
C
G
C
A
Oh
so,
since
these
are
the
static
classes,
do
we
think
that
having
the
target
path
only
from
the
file
system
info
instances,
instead
of
also
having
a
member
on
file
and
or
directory,
is,
is
good
enough?.
E
B
A
B
B
No,
we
thought
about
it,
but
since
it
wasn't
requested,
we
thought
the
same
that
you
just
described.
Well,
we
will
add
them
or
request
them
here.
If
someone
asks
for
them.
D
Just
just
one.
D
D
Yeah,
well,
it's
actually
a
little
bit
more
than
that
is
link
target,
not
equal.
No
and
since
since
you're
gonna
still
have
you're,
gonna
still
have
the
target
to
be
like
in
memory.
You
also
need
to
check
the
exist
property,
so
it's
like
one
extra
dot
exists.
B
So
and
one
last
question:
this
is
the
part
that
we
didn't
get
full
consensus
on
so
because
of
the
difference
between
linux
and
windows,
in
the
sense
that
linux
only
has
symbolic
links.
But
windows
has
three
parse
points
with
a
bunch
of
different
repair
stacks
and
one
of
them
happens
to
be
the
symbolic
link.
Another
one
is
junction.
Another
one
is
the
app
exec
link.
K
Don't
think
this
is
a
linux
versus
windows
question
as
much
as
it's
a
what
file
system
are
you
using
question?
If
you're
on
linux
and
using
ntfs,
then
you
have
all
of
the
junctions
and
and
other
reports
points
available.
K
I
believe
it
depends
on
depends
on
what
you're
using,
but
you
you
have
access
to
all
of
them
through
ntfs,
if
you're,
using
something.
That's
in
tfs,
aware.
K
Right
and
there's
there's
apis
that
you
can
get
to
to
fully
access
the
ntfs
specific
data
and
like
even
when
you
look
at
like
x4
versus
zfs
or
other
file
systems,
sometimes
the
features
they
they
expose
differ
and
so
different
file
systems
may
have
more
fundamental
support
for
things
than
others.
Do.
B
Okay,
this
is
thank
you
tanner
this.
This
is
going
to
help
continue
the
conversation
on
this
and
we'll
we'll.
We
will
come
up
with
an.
M
C
I
mean
I
mean
to
answer
your
broader
question
right
like
so.
Let's
say
you
have
a
type,
you
know
whatever.
It
is
right
and
you
have
linux
specific
apis
or
windows.
Specific
apis
on
it
right
is
that
bad
or
good?
I
think,
since
we
don't
have
an
analyzer,
I
don't
think
it
would
be
that
bad
if
we
have
windows
or
linux
specific
apis
on
a
common
type,
because
the
alternative
is
often
worse
right.
C
It's
more
like,
I
think
when
we
have
these
super,
you
know
you
know
expensive
apis
like
as
in
a
lot
of
api
servers
that
are
specific,
that
we
probably
wouldn't
do
so,
for
example,
all
the
echo
apis.
We
have.
Arguably
they
have
enough
api
surface
that
having
mixed
them
in
on
the
core
types
was
a
mistake.
C
I
think
in
the
api
design,
so
if
you
were
to
design
that
all
over,
I
would
probably
put
that
in
a
separate
namespace
and
you
know
just
take
them
separately,
but
if
it's
just
one
method
and
the
type
already
has
20
or
30
methods
and
that
one
method
happens
to
be
linux
or
windows
specific,
I
think
that's
totally
fine.
I
would
not
lose
sleep
over
there,
but.
A
In
this
case,
if
it's
you
know
a
property
on
file
system,
info
of
you
know,
link
type,
and
it
is
returning
an
enum
that
is
any
or
has
you
know
unknown
none
or
you
know
unknown,
is
or
file
whatever.
You
feel
like
calling
that
I'm
not
a
I'm
a
regular
file,
and
then
you
know
sim
link,
junction,
it
etc,
like
sure
add
all
the
things
it
doesn't
matter,
you're
returning
info
back.
Who
cares
how
many
things
are
in
the
enum
that
don't
get
returned
exactly.
K
And
yeah
in
particular,
windows
and
unix.
Both
support
sim
links,
windows,
support
windows
is
the
only
one
that
supports
junctions
and
that's
only
for
folders,
not
for
files
and
then
hard
links.
Both
windows
and
unix
support
it
for
files
windows
does
not
support
it.
For
folders
and
unix,
specifically,
posix
spec
says
that
hard
link,
support
for
directories
is
optional
and
most
modern
systems
don't
provide
it,
but
they
could,
and
so
you've
got
a
little
bit
of
mix
of
like
junctions
or
windows.
A
B
A
The
weird
question
would
then
be:
if
you
now
want
a
create
link
that
takes
a
takes
in
the
enum
and
whatever
then
now
emo
gets
to
figure
out
how
he
wants
to
paint
things
with
the
this
probably
won't
work
wherever
you
are,
but
again
back
to
tanner's
point.
That's
really
you
you
can't
say
create
junction
on
linux,
won't
work
if
an
ntfs
driver
supports
creating
a
junction
like,
and
we
figure
out
how
to
call
it.
It's
it's
not
a
linux
thing.
It's
a
currently
or
it's
the
not
the
target,
but
the
target
file
system.
A
Okay,
all
right!
So
the
notes
I
put,
we
had
some
concerns
about
get
link,
target
path
and
get
linked
target
being
too
close
to
name.
So
we
renamed
get
link,
target
path,
to
resolve,
link,
target
and
made
get
link,
target
path,
be
a
property
called
link
target
and
I
fixed
the
null
ability
silently
good.
Okay,.
A
A
G
So
this
one
has
gone
through
approval
once
and
then
it
was
realized
that
we
didn't
actually
like
where
we
felt
that
white
got
approved
was
missing
something
so
the
original
you
can
see
in
the
in
the
public
class
string
content.
Here
you
can
see
that
there's
the
the
the
two
added
apis,
the
first
one
is
the
one
that
was
approved
originally
and
the
second
one
is
the
one
that
we
are
proposing
to
also
add
the
issue
here.
Is
we
want
to
give
users
when
they
use
the
string
content
class?
G
G
The
problem
is
that
people
want
greater
finer
control
over
exactly
what
is
sent
in
the
in
the
content
type,
and
so
that's
why
the
original
proposal
had
well,
let's
give
them
a
media
type
header
value,
so
they
can
completely
control
the
the
the
content
type
header
that
is
sent
and
they
can
pass
whatever
they
want.
In
that
case,
and
there's
a
nice
strongly
typed
api
for
how
to
construct
that.
G
G
The
encoding,
try
and
parse
the
encoding
out
of
that
and
and
assume
that
that's
the
encoding
they
want
to
do,
but
we
decided
that
was
a
bad
idea,
and
so
we're
basically
saying
we
want
to
add
one
more
overload
here
that
lets
you
specify
both
an
encoding
and
a
media
type
header
value.
In
this
case
the
in
the
in
the
existing
cases.
The
encoding
is
used
both
to
determine
the
encoding
that
we
use
to
serialize
as
well
as
using
the
as
well
as
determining
the
encoding.
G
G
Yes-
and
there
is
there's
a
proposal
here,
which
is
to
add
a
constructor
overload
to
the
media
type
header
value,
media
type-
header
value-
is
a
it's
a.
We
butchered
this
class,
it
was
originally
immutable
and
then
we
now
it's
partly
immutable
and
partly
mutable,
and
so
you
there's
a
there's
a
center
for
there's
a
charset
property
today
and
a
center
for
it.
G
A
K
A
C
A
All
right,
yeah,
this
all
seems
fine
to
me
other
than.
A
Hey
you're
friends
with
most
of
the
compiler
devs
and
you
know,
go
for
it
while
you're
at
it.
Let
us
be
able
to
move
things
into
a
new
name
space
yeah
that
that
one
is
more
important
to
me.
C
G
C
A
A
M
A
Add
is
async
overload
for
create
open,
etc,
2,
4,
6,
nine
or
eight.
That
was
almost
a
cool
number.
I
feel
like
this
must
be
a
redo,
since
I
feel
like
we
already
did
it.
K
A
Moved
it
from
approved
to
review
now
that
there
was
this
diff
here
so.
C
C
G
Yep,
so
there
are,
we
have
two
types
today
that
that
are
related,
but
different.
One
is
cookie
collection,
which
is
a
very
standard,
old-school
collection
type.
It
implements
eye
collection
of
cookie
lets,
you
add
and
remove
and
manage
cookies
crap
like
that,
and
then
there's
this
other
type
called
cookie
container
cookie
container
is
optimized
to
be
effectively
the
run
time
store
for
your
cookies,
as
you
are
accessing
a
sites
through
hp,
client
or
some
other
api
that
might
want
to
do
some
other
kind
of
cooking
management.
It's
thread
safe.
G
G
What
cookie
container
and
the
other
thing
you're
doing
on
cookie
container
today
is
you
can
say,
get
cookies.
This
is
effectively
get
all
the
cookies
for
this
uri
for
this
uri
path,
and
it
gives
you
back
a
cookie
collection
which
is
not
thread
safe,
but
lets
you
gives
you
the
whole
and
it
effectively
takes
a
snapshot.
As
I
said,
this
is
a
thread
save
class,
so
this
may
be
mutating
in
the
background,
but
this
will
give
you
a
consistent
view
of
the
cookies
for
that
uri
at
any
given
moment.
G
What
you
can't
do
today,
with
cookie
container
very
easily,
is
just
enumerate
all
the
cookies
in
the
container
and
people.
This
is
a
in
fairly
high
demand.
As
you
can
see,
somebody
asked
about
it
on
stack
overflow,
so
it
must
be
important.
G
But
it
seems
like
a
reasonable
request,
particularly
for
just
like
debugging
and
diagnostic
scenarios
to
be
able
to
just
say:
hey,
I
just
want
to
see
all
the
cookies
that
are
in
my
cookie
container
right
now,
so
the
proposal
is
to
add
a
new
api
similar
to
the
existing
api.
The
existing
api
says
give
me
all
the
cookies
for
this
path.
G
The
new
api
would
just
be
get
all
cookies
and
it
would
give
you
all
the
cookies
in
the
would
take
a
snapshot.
So
we
don't
again.
We
don't
have
to
worry
about
thread
safety
issues
and
give
you
a
consistent
view
of
all
the
cookies
that
the
cookie
container
is
managing
at
the
moment,
and
then
you
can
go
iterate
on
that
print
them
out.
Do
whatever
you
want
to
do
with
that.
G
G
We
felt
that
that
you
know
raised
a
bunch
of
questions
about
thread,
safety
and
consistency
that
we
didn't
want
to
deal
with
so
and
especially
since
we
already
have
an
api
that
says,
get
cookies
for
this
path,
and
it
will
give
you
back.
However,
many
cookies
are
relevant
and
give
you
the
consistent
snapshot
of
it.
It'd
seem
like
get
all
cookies
and
give
you
the
consistent
snapshot
is
the
safest
and
most
obvious
way
to
kind
of
allow
people
to
see
what
cookies
are
in
their
cookie
container.
A
G
G
A
All
right,
more
aspen
overloads
to
string
segment,
50428.
K
I
was
going
to
say,
I
think
this
is
the
this:
is
the
pre-span
equivalent
to
to
array
segment
but
for
strings
and
is
only
for
the
di.
K
Yeah-
and
I
think
the
apis
here
make
sense,
they
they
avoid
needing
to
do
the
double
slicing
and
copying
and
they're.
Basically,
what
we
expose
elsewhere.
A
C
Yeah,
it
depends
on
what
you
want
to
be
consistent
with.
I
guess.
A
K
A
A
String
does
not
have
a
span
memory.
Extensions
has
an
as
span
that
extend
or
provides
extension
methods
for
string.
So
it's
this.
A
C
K
N
Does
anyone
yeah
I've
been
trying
to
read
ahead
on
this?
A
little
I
external
scope
provider
is
a
logging
concept.
I'm
not
exactly
sure
why
it's
not
registered
with
di
already,
like
the
proposal
to
me,
makes
sense.
What
I'm
trying
to
figure
out
is
why
it's
not
already
this
way.
I
guess
people
just
didn't
want
the
extensibility
to
this
point.
N
M
N
So
right
the
so
this
is
for
creating
like
logging
scopes
for
the
various
namespaces
right.
So
then
you
get
a
logger
from
a
logger
factory
for
the
various
name
spaces.
This
allows
you
to
intercept
that
generally.
This
is
done
internally
by
providers,
but
this
is
another
hook
to
do
that.
N
So
yeah
and
then
there's
like
discussions
of
like,
would
the
like
add
logger
service
collection,
extension
methods,
just
add
a
default
implementation
for
this
or
like
move
it
up
internally,
I
think
for
back
compat.
You
might
want
to
do
both
yeah.
As
far
as
like
the
use
case
for
where
the
scope
provider
has
to
be
external,
I
I
wish
I
could
help
you
out
more
without.
A
All
right
so
looking
at
it,
the
longest
constructor
currently
has
a
default
parameter,
and
this
is
adding
a
thing
with
that
is
longer
with
default
parameters,
so
we'd
have
to
remove
the
default
on
the
other
one,
but
if
it
otherwise,
if
this
is
all
that's
needed
for
the
scenario,
then.
A
C
C
G
A
Yeah
stefan
does
that
is
this
related
to
something
that
the
di
infrastructure
cares
about.
N
Yeah,
sorry,
I
I
might
have
to
double
check
with
sora
who
filed
this
issue.
I
also
have
another
meeting
at
10.,
so
I'm
not
going
to
be
able
to
which
is
or.
A
A
E
A
C
C
E
A
E
E
C
P
They
say
the
options
on
the
new
constructor.
Did
you
want
it
to
to
be
null
or
you
want
to
remove
that
as
well?.
A
A
Let's
both
yield
to
each
other
and
then
drive
again
all
right,
I'm
going
in
this
particular
case.
As
emo
pointed
out.
It
doesn't
matter
because
there
was
explicitly
a
two
argument:
constructor
so
that
will
have
better
binding
over
ever
using
any
of
these
defaults.
But
it's
the
pattern
for
when
that's
not
the
case,
so
we're
just
following
the
pattern:
email
you're
out.
C
Yeah
and
I
think
for
the
new
one
yeah,
I
think
for
the
new
one,
the
idea,
but
we
wanted
options
to
be
now
this
kind
of
the
di
issue
right
where
I
think
the
I
will
always
use
the
longest
constructor.
So
if
you
want
options
to
be
allowed
to
be
null
you
kind
of
want
to
have,
I
think
you
need
to
defaulted.
Otherwise
the
eye
will
fail
to
construct
it
or
something.
F
A
And
I
copied
the
signature
out
of
here
so
all
right,
this
type
obviously
doesn't
participate
in
nullability.
So
I'm
not
going
to
add
the
question
marks
all
right,
also
because
I
already
hit
send
all
right,
awesome
api
proposal,
array.clear
of
array,
so
we
have
the
existing
clear
which
takes
index
and
length,
and
so
I
think
that
the
proposal
is
just
to
add
one
that
you
don't
have
to
pass:
zero,
comma
or
rate
out
length.
H
Yeah,
if
you
look
at
the
vast
majority
of
our
radon
clear
sites,
they're
just
array,
zero
array.length,
which
is
both
clunkier
and
adds
a
little
bit
of
overhead.
C
C
A
P
K
K
Yep,
hopefully,
we'll
actually
get
through
them
relatively
quickly,
because
it's
fairly
straightforward,
but
so
for
for
this
one
we
for
net
six
we've
reviewed
and
approved
supporting
native
integers
for
vector
of
t.
Last
week
we
reviewed
and
approved
extending
vector,
64
128
256
to
support
the
same
helper
methods
that
are
on
vector
of
t.
K
Most
of
the
methods
will
be
supported
via
the
via
the
existing
generic
overloads
exposed,
but
there's
a
few
non-generic
overloads
that
will
also
be
exposed
and
that's
these
methods
here.
C
So,
which
one
should
we
look
at?
First,
the
so.
K
Though
yeah
this
one
first
in
the
actual
six
milestone,
so
it's
it's
relatively
straightforward
here.
I've
just
exposed
the
at
the
explicit
as
create,
create
scalar
and
create
scalar
unsafe
methods
for
vector
64
128
256..
So
I
understand.
A
This
one,
because
it's
just
a
reinterpret
cast
what
does
create
do
on
vector
64
on
x86.
K
A
C
K
K
A
K
A
K
A
A
K
Okay
and
these
next
two
follow
basically
the
same
thing
so
hardware
intrinsics
that
we
exposed
in
dot
net
3
and
dot
net
5,
depending
on,
if
you're
talking
about
x86
or
arm
only
supported
the
10,
the
10
primitive
type.
So
the
two
floats
and
the
eight
integrals
there's
opportunities
for
us
to
improve
the
experience
by
also
exposing
variants
that
deal
with
native
integers,
particularly
where
there
is
a
x64
versus
versus
baseline
split.
K
So,
for
example,
on
sse,
you
have
convert
to
n64,
which
is
under
the
x64
nested
class,
and
you
have
convert
to
int
32,
which
is
directly
under
sse
and
then
convert
to
inint
ends
up
existing
directly
under
sse,
because
it
will
do
it's
always
supported
regardless
of
32
versus
64-bit,
and
it
will
just
pick
the
right
variant
essentially.
A
A
Meta
question:
I
guess
I
feel
like
everything
that
is
on
one
of
these
thing,
like
every
method.
Here
is
just
an
op
code,
that's
determined
by
its
signature
and
that
we
don't
have
any
helpers
under
these
namespaces,
and
this
is
basically
a
helper,
because
it's
gonna
rewrite
the
instruction,
depending
on
what
architecture
you're
on.
Am
I
right
that
this
is
the
first
one
and
do
we
feel
that
it
belongs
here
versus
somewhere
else?
Because
of
the
we
can't
talk
about
what
this
is
without?
Knowing
where
you're
running.
K
Well,
so
the
the
ins,
the
actual
instruction,
ends
up
being
the
same.
It's
that
the
encoding
of
the
instruction
may
differ
slightly
so
you're
going
to
get
a
p
add,
regardless
of
whether
you're
32-bit
or
64-bit.
It's
just
a
question
of
am
I
natively
operating
on
int
on
a
32-bit
inter
integer
or
a
64-bit
integer.
So
in
that
effect,
it's
no
different
from
comparing
byte.
To
short
for,
for
the
two
add
methods.
A
K
A
A
K
K
All
same
generation,
the
only
difference
was
if
we
were
codifying
for
this
only
exists
on
64-bit,
because
long
support
is
only
on
64-bit.
So.
A
K
Correct
and
similar
for
the
unsigned
yeah
and
more
explicitly
where
there
was
an
int
and
a
long
overload
representing
the
same
functionality.
There
is
now
an
init
overload
there.
There
are
a
few
instructions
where
there
is
only
an
int
and
no
long
overload,
and
so
they
are
not
represented
here.
Likewise,
if
there
is
only
a
long,
there
is
no
in
invariant
because
it
only
supported
one
size.
A
Right,
the
yeah,
my
my
meta
question
here
is:
there's
nothing,
there's
no
words
that
we
haven't
seen.
There's
no
like
this
parameters;
name
something
different
because
of
a
complication.
This.
K
A
K
Yes,
the
the
hardware
instructions
return
the
same
size
as
they
are
input
which
differs
from
bit:
operations
which
returns
a
32-bit
integer,
always
right,
because.
A
K
Arms
is
smaller
because
they've
got
less
isas
and
they
expose
different
instruction
sets.
So
not
all
of
them
make
sense.
A
K
We've
got
the
same
thing
on
x86
as
well.
K
No,
that's
what
that's!
What
the
system
numerix
bit
operations
crc32c
that
we
approved
is
for,
but
we've
not
implemented
it
yet
yeah.
A
All
right,
I
feel
like
there
was
a
missing
close
brace
that
I
added
okay
or
it
wasn't
missing
all
right.
A
Yep
udp
client
ad
span
support
issue
number
eight,
six,
four,
that's
right.
Three
digits
jeff.
G
I
just
stuck
this
one
in
since
it
seemed
like
we
were
running
low
on
interesting
things
to
talk
about
one
of
the
things
we've
been
trying
to
do
with
sockets
and
networking
overall
is
fully
complete.
Spatification
memory
efficient
and
cancel
tokenification.
G
This
is
one
of
the
last
little
areas
that
we
haven't
done
it.
So
it's
simply
adding
new
overloads
that
take
span
memory
and
cancellation
token
for
udb
client,
which
is
a
rarely
used
class
that
you
can
do
udp
operations
with,
but
some
people
use
it
clearly
because
it
has
10
up
votes,
so
you
can
see
the
existing
apis.
G
There's
three
sync
send
overloads
that
we
simply
make
read
only
takes
read
only
span
instead
of
a
array
in
length.
There's
a
two
send
async
overloads
that
now
take
a
read-only
memory
and
a
cancellation
token,
and
then
there
is
one
receive
async
overload
that
takes
a
cancellation
token
receive
async
on
udb
client.
G
Has
this
weird
thing
where,
instead
of
passing
in
a
buffer
that
you
that
gets
filled
in
it,
actually
allocates
the
the
buffer
for
you
and
then
passes
it
back
as
part
of
this
udp
receive
result,
object
which
is
a
terrible
model,
and
I
hope
nobody
ever
actually
uses
that,
but
that's
how
it
works.
So
there's
no
need
to
like
memory.
If
I
a
buffer
for
that
overload,
that's
just
cancellation
token.
A
Okay,
what
is
the
bytes
argument
to
send?
Async
it's
bite
count.
Basically,
there's.
No!
So
that's
offset
zero
from
the
datagram
yeah.
That's.
A
Zero,
okay,
so
that
had
a
whole
lot
of
room
for
left
all
right.
The
these
two
yep
there's,
the
cursor
cancellation
token,
should
get
defaults,
because
if
somebody
has
a
read-only
memory,
yep
makes
sense.
Yeah
otherwise
looks
good
to
me.
A
G
A
G
A
A
C
A
A
Oh
is
value
task
appropriate
for
the
new
one,
because
you're
changing
this
you're
changing
the
value-ness
of
your
tasks.
A
H
That's
what
we've
done
elsewhere,
that
we
wanted?
Okay,
we
had
existing
existing
apis.
We
wanted
that
cancellation
support
and
these
are
hot
path
things.
So
we've
ended
up
using
value
task
and
it's
one
of
these
places
where
yeah
the
overload
does
change
from
fast
to
value
task,
but
it
was
considered
the
lesser
of
the
evils.
H
A
Well,
except
for
this
receive
async
thing
because
it's
udp
receive
result
seems
rel
local
to
this
type.
Is
it?
Is
that
really
anything
we
have
on
socket.
H
Oh,
I
guess
that
wouldn't
make
any
sense
if
it's
not
signing
yeah
sure
yeah.
Well,
in
that
case,
I
honestly
don't
care
here.
G
G
H
A
My
mine
is
the
like.
Yes,
if
we
go
back
to
the
you
can't
really
talk
about
what
the
api
should
do,
because
it's
really
about
the
usage
of
the
api,
but
it's
like
if
somebody
is
capturing
the
task
and
they're
you
know
being
var
and
then
the
analyzer
is
like
hey.
You
should
pass
the
cancellation
token,
because
you
have
one
then
now
the
varnish
changed,
even
though
all
they
did
was
pass.
The
cancellation
token
versus
the
others,
like
you,
had
to
get
rid
of
this
bytes
parameter
because
the
span
no
longer
takes
it.
A
So
that's
where
my
concern
comes
in,
but
my
answer
on
task
versus
value
task
is
use
task.
E
H
Weird
situation
with
all
these
networking
apis
because
we
actually
do
in
general,
we
expect
these
things
to
just
be
awaited
and
we
expect
them
to
use.
You
know
the
hotpath,
so
all
the
new
ones
we've
been
adding
have
all
been
valued
tasks,
so
they
were
creating
inconsistencies
with
the
existing
apis,
which
is
the
main
thing
we
wanted
to.
You
know
for
that
rule
was
anything
we
wanted
to
avoid.
I
don't
know
I
I
would
just
make
a
value
test
and
solve
the
other
one's
writing
or
value
tests.
I
don't
think
it
matters.
H
J
J
A
K
So
this
one
is
slightly
controversial
in
that
yawn
had
pushed
back
on
us
exposing
it.
I
ultimately
decided
to
bring
it
anyways,
as
I
think,
there's
still
benefit
for
this
being
an
explicit
intrinsic
rather
than
trying
to
retrofit
the
existing
system.math
apis.
K
In
particular
role,
we
can
accelerate
the
system.math
apis,
there's
a
quite
a
bit
of
functionality
that
is
specific
to
x86,
in
that
this
is
a
singular
instruction
and
with
how
and
with
everything
that
supports
that,
I
don't
think
trying
to
retrofit
everything
on
the
system.math
is
is
the
correct
thing,
in
particular
the
hardware,
the
hardware
instructions,
support,
signed
and
unsigned
variants.
K
K
K
G
in
it
another
h
right
and
I
think,
we're
actually
using
the
term
lower
and
upper
in
the
intrinsics,
not
high
and
low
okay,
we
ended
up
changing
this
proposal.
Is
I
think,
three
years
old
now,
and
so
we've
changed
a
few,
a
few
things
since
it
was
originally
written,
and
I
apparently
didn't
didn't
remember
to
update
them.
A
Okay,
so
assuming
that
the
top
part
here
is
the
thing,
that's
actually
being
proposed,
sorry
that
the
top
post-
this
has
both
add
the
intrinsics
and
add
complicated
things
on
or
and
add
these
on
math
do
we
also
want
them
on
math.
K
Yes,
I
believe
so
let
me
double
check,
though,
I'm
not
quite
sure
what
all
overloads
we
added.
K
And
then
it'd
be,
you
went
lower,
comma?
U
and
upper
based
on
the
ordering
we
use
in
other
places.
M
K
So
technically,
technically
there
is
no
ordering
here.
It's
actually
that
the
upper
bits
go
into
a
specific
into
one
specific
register
and
the
lower
bits
go
into
a
specific
other
register,
fair
enough.
K
It's
a
formerly
edx
colon
eax
and
then,
given
we
just
reviewed
the
inning,
there
should
likely
be
an
inte
inuit
under
x86
base
as
well.
M
A
K
K
Original
proposal
here
with
right,
but
we
swapped
high
and
low
and
the
type
didn't
get
swapped
with
it
right,
because
I
thought
they
were
the
same
so
yeah
all
right.
So
what's
the
order,
so
it
should
be
unsigned.
Lower,
signed
upper
for
the
signed
variance,
since
the
sign
on
the
lower
doesn't
make
sense.
Since
it's
the
extracted
bits.
A
K
A
K
K
And
if,
if
yawn
does
have
significant
pushback
after
we
approve
this
again,
then
I'll
talk
with
him
and
determine
if
he,
if
there's
a
right
path,
that
right
path
forward.
That
covers
the
the
space
that
I
think
this
is
filling.
K
Oh
I
his
his
viewpoint
above
was
that
we
we
should
be
able
to
expose
all
this
functionality
on
math
and
my
pushback
against.
That
was
that
there's
some
functionality
here,
that's
very
hardware
specific
on
x86
and
where,
knowing
that
it
is
accelerated,
is
beneficial,
because
the
performance
implications
of
a
128-bit
by
64-bit
division
are
drastically
different
between
x86
and
arm.
In
this
case,
for
example,.
A
C
Oh
yeah,
no,
I
remember
no
okay,
so
basically,
so
I
think
we
may
want
to
reject
that
so,
but
basically
it
has
come
up
a
few
times
before.
So
we
have
this
generic
attribute
that
we
added
to
effectively
store
arbitrary
key
value
pairs
into
the
assembly,
so
we're
using
it,
for
example,
for
our
group
servicing,
so
we
have
a
key
called
serviceable
or
something,
and
then
it's
set
to
true,
and
so
in
other
parts
we
wanted
something
similar
for
types
or
members,
and
so
I
think
I
don't
know
who
suggested
it.
C
I
might
have
been
christopher
somebody
else
who
said
like.
Why
can't
we
just
change
this
attribute
to
remove
the
restriction
to
assembly,
so
you
can
literally
apply
it
on
anything.
So
if
you
just
want
some
key
radio
pairs
attached
with
anything,
you
could
do
that.
The
pushback
that
that
has
come
to
this
api
is
basically
like.
Well,
everything
that
starts
with
assembly.
C
You
know
is
literally
always
restricted
to
the
to
assembly
right,
so
you
can't
apply
assembly
xxx
attribute
to
something
other
than
assembly,
so
I
think
that's
fairly
reasonable
and
yeah.
I
mean
the
the
other
pushback
as
well.
It's
already
bad
enough
that
we
have
it
on
the
assembly
level,
but
if
you
now
have
this,
you
know
attribute
applicable
to
everything.
Now
you
have
this
super
loosely
typed
world,
where
just
arbitrary
key
value
pairs
are
attached
to
things
and
then
people
act
on
that
and
that
seems
like
a
bad
plan.
C
So
I'm
not
super
gung-ho
about
this.
I
mean
I've
mostly
filed
it
back
then,
because
people
asked
for
that
and
I'm
actually
ready
for
you
to
just
that.
We
make
a
decision.
A
I
think
if
we
I
mean
we
can
weasel
out
of
it
by
saying
it's,
not
assembly
metadata,
it's
simply
metadata,
but
I
yeah
I'm
fine
with
saying
the
name
already
has
the
implied
target
of
assembly.
If
we
need
it
elsewhere,
we
should
make
a
more
generically
named
thing
right.
K
So
for
the
next
set
of
issues
in
the
list,
most
of
them
are
analyzer
issues.
There
is
one
there's
actually
a
couple
about
halfway
down
that
look
like
they're
smallish
completable
in
the
dot
net
six
time
frame
issues.
If
we
wanted
to
look
at
those
in
the
next
10
minutes
before
we
wrap
up
time,
and
maybe
we
could
do
a
dedicated
analyzer
session
on
tuesday,
assuming
no
backlog
issues
come
in.
I
K
K
K
K
M
K
No,
you
can,
however,
using
this
you
could
create
a
span
or
or
just
grabbing
the
ref
from
zero.
You
could
grab
the
span.
K
I
it
might
be
also
looking
further
down,
it
looks
like
the
top
post
was
not
updated
or
actually
levi
did,
and
he
left
a
comment
at
the
very
top
linking
to
it
after
input
from
yawn
they
decided
to
take
in
system.array.
Instead,
I
was
misremembering,
and
someone
pointed
that
out
to
me.
K
Yeah
yeah,
so
it's
I
think
you
scrolled
past
it
jeremy.
There
was
a
link
at
the
very,
very
top
that
took
you
right
to
it.
A
A
A
A
Yet
yeah
so
tensor
has.
I
only
looked
for
open
bracket
comma
closed
bracket,
so
it
was
yeah
three
things
on
tensor
popped
up
and
then
one
thing
in
bb
core.
So
got
it
all
right.
H
K
H
A
A
Okay,
so
the
problem
is,
there's
two
implicit
things
going
on
and
I
don't
know
which
order
they
happen
in
the
in
method
resolution,
because
this
is
all
arrays
are
array
and
the
other
one
is
generic
inference.
So
will
this
be
a
recompile?
You
would
actually
get
the
array
one
or
will
the
generic
inference
version
win,
because.
A
K
Non-Generic:
okay,
it
looks
to
bind
to
the
generic
version.
Okay,
the
the
generic
t
array
ends
up
being
more
exact
than
a
than
a
pseudo
base
type.
A
H
K
Git
array
data
reference
matching
the
existing
name,
taking
array
returning
ref
byte
since
ref
void,
doesn't
work
and
then
with
a
comment
that
if,
if
the
runtime
says
that
this
only
works
with
multi-dimensional
arrays,
then
just
call
it
git
get
md
array
data
reference.
M
K
A
What
if
it's
a
reference
type
like
if
you
pass
object
array
in
here?
What
did
you
just
get.
K
K
N
A
Yes,
okay
I'll
talk
to
miriam
about
it.
Sorry,
if
you're
still
here
mariam,
I
forgot
yes,
that
that
there
was
some
other
meeting
that
was
discussing
something
and
so
it
it
may
have
interaction
with
another
meeting,
and
so
it's
not
ready
today,
okay,
I
apologize
for
not
being
able
to
remember
five
minutes
ago.
A
A
It'll,
do
something
probably
tear
a
hole
in
the
universe,
but
if
that
causes
it
to
come
back,
then.
L
A
All
right,
technically,
there
are
three
minutes
to
go.
I
move
that
we
adjourn.
C
Awesome
works
for
me,
so
that
means
then,
given
that
we
are
not
pretty
much
done
with
6o
stuff.
I
guess
we
are
okay
with
now
moving
to
one
time
a
week
again
right.
K
A
A
Jeff
marked
at
least
one
thing
at
6-0
during
the
meeting
just
so
it
would
jump
to
the
top
of
the
list,
or
maybe
he
marked
it
ready,
and
it
was
already
six,
though
I
don't
know
all
right
so
for
for
once
we're
ending
on
time
and
that's
exciting.
I'm
glad
that
I
remembered
a
thing
about
parliamentary
procedures
so
see
you
all
or
anyone
who
wants
to
join
us.
10
a.m,
tuesday,
as
always,
it's
redmond
time
and.