►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello
friends
good
morning,
good
evening
or
good
afternoon,
depending
on
where
in
the
world
you
live
right
now,
so
today
we're
looking
at
two
blocking
issues
and
then
the
rest
is
just
backlog.
So,
first
one.
Yes,
all
the
way
to
the
bottom.
There
was
basically
the
we
reviewed
this
the
first
time.
A
Is
it
actually
the
one
yeah?
Let's
go.
A
A
Basically
we
said
we
wanted
to
have
two
different
properties
and
there
was
lots
of
discussion
and
in
the
meeting
we
said
it
would
be
nice
if
they
would
be
the
same,
and
then
there
was
some
concerns
that
this
couldn't
be
made
the
same
and
then
after
further
discussion,
they
realized
that
actually
they
can
be
the
same
and
now
they're,
basically
asking
to
change
it
to
basically
be
what
we
already
wanted
to
have
in
the
first
place.
So
I
think
that
looks
fine.
A
C
C
C
Oh,
I
see
well,
the
http
message
handler
is
actually
an
open
api,
so
anyone
can
implement
it.
It
wouldn't
make
sense
to
have
this
api
there,
because
then
third-party
implementations
would
just
have
something
that
does
nothing.
A
I
see
well
then
yeah.
The
only
question
is
at
some
point.
Like
you
know,
let's
say
we
had
three
or
four
more
properties
that
end
up
being
in
the
same
bucket.
Would
we
ever
find
ourselves
in
a
world
where
somebody
wants
to
do
this
generically,
or
I
mean
if
we
ever
do
this,
then
we
could
potentially
still
extract
it
as
an
interface
if
we
really
wanted
to,
but.
C
Yeah,
we
kind
of
already
have
that
situation
today,
there's
not
a
good
story
for
it,
and
the
problem
exists
for
several
other
properties
as
well.
I
think
we
need
to
think
about
it
in
a
broader
sense,.
A
C
C
A
And
the
only
oh
never
mind.
No,
I
was
just
opening
my
mouth
to
say
something
about
it,
but
there
was
a
delay.
A
A
C
If
someone
wants
some
behavior
that
is
specific
to
win
http
or
if,
for
some
reason
we
have
a
broken
implementation
in
sockets
http,
that's
kind
of
the
option
for
them,
but
people
it's
really
more
of
an
opt-in
choice.
Most
people
would
not
be
using
http
handler.
I.
D
See
I
don't
remember
if
we
painted
that
one
with
the
minimum
os
attribute
emo.
A
C
This
one
does
exist
as
a
nuget
package.
It's
not
built
in.
Maybe
that's
why
it
wasn't
included
there.
A
A
No
sorry,
I'm
not
sure
what
I'm
doing
what
I'm
doing
is.
I'm
I'm
restoring
a
self-contained
app
targeting
net
5
with
a
reference
to
the
windows,
compat
pack,
and
so
this
will
generally
catch
most
of
our
autobahn
nougat
packages,
but
clearly
not
all
of
them.
So
that's
probably
why
yep
so
in
fact
yeah.
I
should
probably
rerun
this
thing
and
make
sure
that
I
have
all
packages
from
that
runtime
reference.
A
Do
is
we
maybe
it
doesn't
have
to
be
an
interface.
We
could
also
say
you
know
if
there
is
commonality
between
the
handlers
and
we
can
actually
wait
until
we
actually
see
them.
We
should
just
be
mindful
when
we
add
properties
that
we
align
them,
then
we
introduce
the
base
type
later
right,
like
you
don't
like
by
introducing
a
bass
type
after
the
effect
is
not
a
breaking
change.
C
C
A
And
to
me
it's
more
like
you
know,
if
you
have
a
base
type,
you
kind
of
like
also
avoid
the
fact
that
you
know
we
slightly
spelt
it
differently
right.
It's
just
these.
You
know
mild
annoyances
when
people
didn't
actually
think
of.
Oh
there's
a
feature
already
exist
elsewhere,
kind
of
thing
right,
it's
kind
of
like
predicated
on
us
just
manually,
carefully,
aligning
them
right,
yeah
and
sometimes.
C
You
have
to
thought
about
it,
but
yeah
because,
like
with
win
http
handler
we're
we're.
Basically
we
have
our
hands
tied
with
what
http
supports.
So
if
we
implement
something
differently
in
sockets,
then
it
may
not
make
sense
to
have
the
same.
A
A
And
that's
ironically,
the
general
theme
that
I
see
across
the
bcl
right.
Every
time
you
have
like
some
sort
of
abstraction
or
provider
model.
It's
very
often
the
case
that
the
actual
party
happens
on
the
on
the
concrete
things.
A
Well,
oh
by
the
way
in
case,
you
didn't
notice,
github
added
a
new
feature
that
is
called
activity
feed
and
by
default
it
hides
all
events,
so
you
only
see
the
conversations.
So
if
you're
confused,
you
don't
see
events
anymore,
that's
you
know
changing
labels
and
stuff.
That's
probably
why
you
can
toggle
this.
So
this
is
right.
Another
top
issue
description,
there's
a
little
drop
down
thing
where
you
can
change
to
show
all
all
right,
so
next,
one
then
or
previous
one.
I
guess.
C
So
this
one
essentially,
we
have
this
problem,
grpc
shows
it,
but
it
can
happen
elsewhere,
where
you
have
you've
made
a
request
to
a
remote
server,
but
the
response
isn't
expected
to
come
back
with
anything.
For
you
know,
maybe
minutes
and
firewalls
just
decide.
Oh
hey
this
connection,
I
haven't
seen
any
packets
for
it
in
the
last
five
minutes,
I'm
gonna
drop
it
and
from
the
grpc
client
side
that
just
looks
like
the
server
hasn't
sent
anything
there's,
no
there's
no
sort
of
connection
reset
or
anything
like
that.
That
happens.
C
So
this
keep
alive
setting
it
essentially
just
sends
a
ping
packet.
Occasionally,
if
we
haven't
received
something
to
make
sure
the
connection
stays
alive
and
also
to
check
that
it
is
alive.
C
D
So,
what's
the
relationship
of
these
two
it
like
it
feels
like
the
time
out
should
really
be
a
multiple
of
the
number
of
pings.
C
So
what
will
happen
is
if
we
have
not
read
any
bytes
since
the
interval,
we
will
send
a
ping
frame
and
if
the
server
does
not
reply
with
the
pong
frame
within
the
timeout,
then
we
assume
the
connection
is
dead
and
close.
It.
C
D
C
It's
it's
how
long
the
server
has
to
reply
before
we
close
the
connection
and
then
what
is
the
interval
again?
The
interval
is
if
no
bytes
have
been
read
from
the
connection.
Once
that
interval
elapses,
we
will
send
a
ping.
C
D
No
semantic
meaning
protocols
older
than
http2;
no,
no,
it
has
no
meaning
or
yes,
it
has
no
meaning.
C
There
is
an
http
or
sorry,
there
is
a
tcp
keep
alive
setting
actually
which
is
kind
of
similar,
but
that
only
handles
your
specific
hop
and,
if
you're
going
through
something
like
a
proxy,
then
it's
possible
for
the
connection
to
get
zombified
on
the
proxy
side
and
not
your
side.
So
this
is
kind
of
we
need
this
solution,
rather
than
just
relying
on
the
tcp
option.
F
D
D
Tcp
ack,
but
I
don't
know.
C
If
you
can
measure
that
we
could
potentially
use
this
setting
to
configure
just
the
tcp
keep
alive
like
it
wouldn't
be
perfect,
but
it
would
be
better
than
nothing.
There's
really
no
other
option
for
http
one.
F
C
No,
we
already
have
a
setting
right
now
for
connection
idle
timeout.
So
that's
that's
handled
already.
D
Okay,
because
just
wondering
if
effectively,
if
you
want
a
a
period
between
ping,
an
interval
and
between
ping
and
timeout
of
that,
you
make
a
keep
alive
ping
policy
property.
And
but
if
it's
the
two
that
feels
over
engineered.
C
E
Oh
he
he
just
wants
to
be
social.
I
I
think
I
think,
honestly,
the
names
are
fine,
as
proposed
here,
a
lot
of
it's
going
to
be
reading
the
documentation
anyway
right,
because
it's
it's
not
really
an
interval
because
you're
not
doing
it
periodically,
you're
doing
it
as
in
response
to
a
delay.
We
would.
E
C
E
A
A
D
I
mean
like
looking
at
ping
interval
it
with
keep
alive.
It
makes
sense
to
me
that
it's,
I
don't
know
if
it's
rising
edge
to
rising
edge
or
falling
edge
to
rising
edge
of
what
the
interval's
measuring,
but
it
hardly
matters
though
the
confusing
one
to
me
is
is
timeout.
That's
the
one
that
I
would
end
up
in
documentation
of
like
oh,
it's,
the
timeout
on
the
ping,
not
how
long
to
keep
pinging
and
so,
but
I
guess
how
long
to
keep
pinging
you
expressed
is
already
on
the
maximum
receive
wait
time
or
whatever.
E
A
A
A
D
C
A
D
A
No,
it's
it's
leave
it
indeed
yeah!
Okay,
I
know
german
is
hard.
Where
the
is
it
here's
the
window
all
right.
So
then
I
guess
we
are
now
done
with.
D
Blocking
blocking
making
sure
nobody
refreshed
it
or
nobody
added
one:
okay,.
A
So
what
do
you
want
to
talk
about
information,
or
should
we
just
leave
that
aside.
E
A
A
All
right
so
then
I
guess
the
sockets
flaggy
thingy,
whatever
it
is.
C
Yeah,
so
we
have
a
problem
now
with
blazer,
where
the
socket
http
handler
api
exists
there,
but
it
just
doesn't
work.
So
james
is
asking
if
we
can
add
a
is
supported
pool.
C
I
called
out
that
I
know
that
we're
dealing
with
these
windows
specific
apis
and
flagging
them
in
some
way
we're-
probably
I
imagine
we
have
a
similar
like
feature
check
thing
that
needs
to
happen
across
a
lot
of
those
apis.
So
I
wonder
if
this
is
part
of
a
sort
of
broader
problem,
maybe
we
need
another
api
to
check
if
things
are
supported
on
your
current
os.
C
Otherwise
this
is
supported.
Api
would
be
fine.
A
C
You
can
do
it
up,
but
if
you
access
anything
on
it,
it
gives
you
a
platform,
not
supported
exception
cool.
I
mean.
A
Maybe
the
constructor
has
it
too?
I
I
I
don't
think
I
saw
it
there,
but
it
might
be
there.
Yeah
I
mean
like
if,
but
I
mean
regardless
of
the
constructor
throws
or
not,
but
it
sounds
like
effectively.
The
whole
type
is
unsupported
then,
and
I
think
in
that
case
it's
supported
makes
sense.
To
me
I
mean
I
mean
generally
speaking,
this
is
the
pattern
that
we
have
pushed
for,
which
is
aesthetic
bool
is
supported
on
the
type
if
it's
for
type
granularity.
A
If
it's
for
you
know,
features
on
the
type,
then
I
would
probably
still
go
with
public
static.
Bool
is
feature
name
supported
and
then
for
anything
that
is
configuration
based
yeah.
It
would
be
an
instance
method
right
if
it
depends
on
actual
state,
like
you
know,
or
can
you
actually
write
to
the
stream?
What
depends
did
you
open
the
file
with
you
know,
write
mode
or
not,
so
that
seems
reasonable.
A
I
think
the
only
bigger
thing
that
we
may
want
to
consider
is
like
we
just
talked
about
the
win
http
handler.
We
should
probably
do
the
same
thing
there
and
then
just
say
well,
the
you
know.
Well,
what
we
just
say
screw
it
that's
what
we
have
the
analyzer
for
right.
If
it's
literally
an
os
platform
thing,
we
would
just
say
yep
be
marketed.
Click
on
specific,
the
analyzer
will
tell
you
and
then
you
know
you
basically
surround
this
thing
with.
However,
perfect
west
check
right.
D
This
is
gonna
be
similar
because
it's
I
was
gonna
say
you
should
write
this
down
on
your
list
of
things
that
you
need
to
paint.
It
doesn't
work
on
wasm.
A
Right
so
the
so
the
western
thing
is
kind
of
the
same
right.
It's
just
would
be.
We
would
mark
the
apis.
This
won't
work
in
blazer,
and
so
it
would
be
the
same
thing
right,
but
instead
of
saying,
if
it's
windows
and
youtube
http
works,
you
would
say:
if
not
blazer,
then
new
socket
center
would
work
right.
D
Right
to
to
throw
complications
into
your
into
your
spec
once
we
already
have
in
a
supported
check.
Presumably
we
want
that
to
bypass
the
os
checks,
because
that
was
on
the
specific
api
set.
So
now
the
analyzer
gets
hard.
A
Well,
sort
of
like
I
mean
that's
something
we
need
to
consider
what
that
means,
but
like
I
would,
I
would
generally
say
so.
There
is
a
spec
that
I
have
for
capability
apis.
What
the
idea
is.
You
can
actually
mark
things
as
this
requires
a
capability
check
and
that
would
work
very
similar
to
the
os
check
where,
basically,
we
would
you.
C
C
What's
our
strategy
for
all
of
the
other
apis
that
don't
work
if
you're
not
on
windows
like,
are
we
adding
an
is
supported
flag
to
them,
or
are
we
expecting
an
analyzer
to
take
care
of
it.
A
Well,
we
would
say
everything,
that's
platform,
specific
or
as
specific,
would
generally
mark
as
an
os
specific
api
and
then
the
capability
api
is
the
os
check.
That's
it
and
the
analyzer
makes
sure
that
you're
consistent
there.
Then
there
is
this
thing
like
reflection,
emit
where.
Well,
it's
not
really.
You
know
a
specific
api
clearly,
but
there
are
cases
where
it
works
in
their
cases
where
it
doesn't
work
right
and
then
there
are
cases
where
it
works,
but
not
quite
the
way
you
want
it
to
right,
which
is
yeah.
A
The
code
is
interpreted
not
actually
executed,
and
so
for
those
cases
we
really
want
capability
apis,
because
it's
the
only
thing
that
makes
sense,
and
then
the
question
is
okay.
How
do
people
discover
the
fact
that
there's
a
capability
api
they're
supposed
to
check
and
that's
what
analyzer
would
help,
but
the
feature
would
work
very
differently,
so
I
would
generally
say
if,
if
the
primary
selector
is
the
os,
I
would
not
make
a
capability
capability
api.
A
C
Yeah
I
mean
this
is
more
like
it.
If
you
can
open
a
socket
than
it
is
supported.
So
currently,
webassembly
is
the
the
only
one
it's
not
supported
in,
and
actually
we're
probably
going
to
have
the
same
problem
using
xamarin
on
ios.
D
D
Because
if
it
was
really
just
expressing
status
here
of
whether
or
not
it
thought
sockets
were
supported
as
an
as
a
lower
level
thing,
then
that
would
make
sense
to
me.
But
if
it's
that
we're
building
a
variant
of
the
library
and
our
variants
are
always
keyed
off
of
os,
then
that
feels
like
we've
called
it.
An
os
problem
right.
A
It
seems,
generally
speaking,
the
the
other
question
is
so
for
blazer
right
we
doing
capability
apis
for
blazer
also
doesn't
make
sense,
because
some
of
the
things
are
so
fundamental
that
we
really
don't
want
to
push
it
on
people
to
say.
Please
check
this
capability
api,
like
you
know,
do
you
have
a
file
system?
Do
you
actually
have
threading
support,
and
so
I
think
that's.
A
The
other
reason
why,
for
for
most
of
the
blazer
api
is
just
saying
this
will
blow
up
in
blazer
makes
more
sense
so
because
then
also
we
will
not
force
it
on
everybody,
but
we
basically
say
it
depends
on
the
project
configuration
whether
an
analyzer
checks
for
unsupported
apis
in
blazer
and
the
default
would
be
no
versus
this
one
sounds
more
like
a
you
know,
it's
not
supported
in
in
all
the
handlers
we
care
about,
but
then
the
question
is
like
what
are
the
conditions
where
this
actually
doesn't
work.
E
D
D
C
Yeah,
I
think
what
we're
telling
people
is
use
the
default,
which
is
to
not
specify
any
handler
if
you
can
otherwise
use
http
client
handler,
which
does
abstract
it
for
you,
and
it
does
not
provide
the
same
level
of
same
granularity
of
settings
because
not
everything
can
be
obstructed,
sure
and
use
the
actual
implementation,
sockets
hd
http
handler.
If
you
have
you
know
one
of
those
specific
settings,
you
need
yeah.
D
There
is,
there
is
a
thing
that
the
the
is
supported
would
help
with
that,
the
not
supported
on
certain
configurations
attribute,
wouldn't,
which
is
library
code
that
wants
to
do
the
best
it
can
based
on
its
runtime
environment,
like
certainly
they
could
write
the
if
I'm
not
blazer
do
whatever,
but
the
I
don't
know
if
the
supported
flag
makes
it
easier
for
them
to
detect
that
there
may
be
configurations
where
the
code
that
they're
about
to
write
is
not
correct
or
or
what
so.
A
A
A
A
Oh
well.
D
A
Because
I
mean
I
like
the
idea
that
that
basically
the
default,
is
you
just
new
up
the
root
type
and
you
get
the
best
thing
and
then
I
think
it
makes
sense
for
people
that
want
more
advanced
stuff.
Well,
then
they
knew
of
the
handler,
but
they
cannot
really
say
the
type
right.
We
ideally
want
them
to
say.
D
Yeah
I
mean
creating
the
creating
the
factory
and
already
having
a
configuration
where
it
returns.
Something
other
than
socket's
http
handler
will
mean
that
we
already
have
the
punishment
in
place
for
the
people
that
do
the
hard
casts.
So
we
won't
end
up
with
the
problems
we
had
with
cryptoconfig,
but
but
it
it
does
seem
like.
That,
may
be
a
a
better
answer
of
once.
The
factory
has
like
you
really
do
need
to
use
as
instead
of
a
hard
cast
or
if
you
were
gonna,
do
a
hard
cast
just
say
new
yourself.
D
Then
then
it
has
value.
A
D
C
A
A
Yeah,
so
you
effectively
get
the
sockets
hp
handler,
but
it's
wrapped
yeah.
So
if
you,
if
you,
if
you
would
have
had
a
factory,
there
would
have
actually
would
have
been
able
to
actually
expose
it
as
such,
as
it
should
be
handler
instance
wise,
which
be
the
only
reason
we
can't
do.
It
is
because
of
the
constructor.
A
C
Bit
of
a
complicated
beast,
because
we
we
wrap
the
sockets
http
handler
in
in
a
few
different
layers
for
some
added
features
that
aren't
and
those
those
layers
are
not
public.
Apis.
Okay,.
D
So
yeah
it's
it
sounds
a
little
bit
like
a
factory
could
be
good.
That
is
supported,
doesn't
hurt,
but
it
it
still
seems
like
like
there
should
be
a
nice
pattern.
Like
imagine
we
end
up
with
you,
know
an
ios
specific
tuning
model,
a
wasm
specific
tuning
model
and
and
whatever.
D
People
who
want
to
do
light
up
enhancement,
doing
an
as
feels
better
to
me
than
doing
this
big
waterfall
of
if
this
is
supported
right
this
new
else
right
or
else
if
some
other
thing
supported
right,
that
new,
like
it,
gives
them
easier
code
to
reason
about,
and
if
they
only
care
about
tweaking
soccer's
http
handler
than
they
can.
C
Yeah,
why
don't
we?
Why
don't
we
postpone
this
issue?
For
now,
I
will
I'll
bring
up
with
the
networking
team
if
we
want
to
expose
the
handler
directly
from
the
http
client
handler.
I
think
that
that
might
be
a
better
solution.
F
F
C
Yeah
well,
we
have
a
browser
http
handler,
but
it's
a
private
api
right
now
so
for
for
this
as
cast
thing
to
work,
we'll
have
to
expose
that
as
a
as
an
actual
handler,
people
can
instantiate.
D
C
Something
more
defined
more
likely
for
net
five
yeah.
So
maybe
it's
okay
to
just
add
that
now
and
worry
about
the
the
larger
api
later.
A
Yeah,
let's
do
this,
let's,
actually
I
have
a
write-out
now
what
we
just
talked
about
with
the
factory
method,
let's
approve
the
the
the
supported
one
as
well
and
then
just
leave
this
comment
in
as
a
consider
doing.
This
sounds
good,
like
I
hate
when
we
basically
make
the
perfect
enemy
of
the
good
or
something
like
this.
D
Well,
I
think
if
we
were
talking
about
this
for
six,
we
would
say
there's
a
lot
of
things
to
think
about
here.
Let's
not
add
anything
until
we're
sure
what
we
want,
but
I
I
do
think
that
this
is
even
if
this
ends
up
being
a
one-off
pattern
in
this
space.
It's
not
terribly
bad,
so
getting
something
in
for
this
releases
is
better
than
depending
on
the
catch
model.
D
I
mean
it's
really
just
a
question
of
anybody:
who's
writing
a
library
that
might
get
pulled
into
blazer
of
what's
there
what's
their
good
fix
and
it
seems
like
right
now.
It's
either
right
embed
into
your
program,
an
understanding
of
what
things
look
like
of.
C
Yeah,
let's,
let's
do
this
supported,
I
liked
what
emo
said
approve
this
and
I'll
talk
with
the
networking
team.
If
we
do
want
to
do
the
big
thing
we
probably
won't,
but
if
we
do
want
to
then
we'll
come
back
with
a
larger
api.
A
A
C
Well
hold
on
you
added
is
supported
to
http
message
handler,
not
sockets
http
handler.
Yes,.
A
A
A
E
A
D
D
E
Yeah
so
there,
so,
the
the
larger
discussion
is
like
what
kind
of
mock
ability
support
we
should
have
throughout
the
framework.
Like
I
file
system,
I
clock
stuff
like
that
right,
but
there's
if,
if
types
like
this
are
already
used
widely
amongst
applications
like
why,
wouldn't
we
add
them
to
an
assembly
that
already
serves
as
a
repository
for
much
of
this
stuff.
A
D
A
D
A
D
Possibly
just
as
a
straw
man,
in
fact,
it
seems
probably
just
as
a
strong
man
suggested
going
to
system
instead
of
the
microsoft
extensions,
primitives
yeah.
D
And,
and
so
the
the
ques
like,
because
one
of
the
meta
questions
is
at
the
for
the
bcl
or
let's
call
it
for
the
shared
time,
though
all
this
might
actually
be
in
the
shared
run
time
now,
but
what
level
of
mock
ability
do
we
want?
And
I
think
we,
the
current
state,
is
we're
not
mockable
and
being
mockable
is
rewriting
everything,
and
I
I
think
that
we
aren't
going
to
do
that
right,
but.
A
D
That,
as
as
the
owners
of
a
mock
or
of
a
di
system
that
this
seems
like
a
primitive
that
should
go
along
with
that
di
system,
that
makes
sense
to
me
so
and
I
system
clock,
because
that
was
one
of
the
later
comments,
because
I
I
talked
about
it
in
the
context
of
system
in
a
comment
where
it
was
like
well,
we
would
then
end
up
wanting
the
singleton
and
now
we're
just
going
to
reference
the
singleton.
D
So
we
avoid
object,
instantiation
and
then
now
we're
effectively
back
to
the
api
we
have,
which
is
just
give
me
the
current
time
without
creating
objects,
and
but
we
added
a
lot
more
layers
in
the
middle
and
someone
followed
up
of
like
oh
well,
you
just
inject
one
at
the
beginning,
but
it's
like
well
right.
That
assumes
you
have
a
di
system
so.
E
D
E
Think
it
would
be
useful
that
this
aside,
it
might
be
useful
to
create
a
bunch
of
di-friendly
wrappers
around
our
existing
apis.
In
fact,
system.
Web
full
framework
did
that
around
the
40
time
frame
where
they
they
had
their
god
object,
http
context,
but
they
also
provided
an
abstract
base
class
for
mock
ability
purposes,
and
then
they
provided
a
wrapper
around
that
which
literally
just
forwarded
everything
to
the
god,
object,
static,
apis
and,
and
those
were
all
provided
inbox.
Basically.
E
So
if
we-
and
as
as
a
concrete
example
here
say
that
we
had
ifile,
I
file
would
be
an
interface
that
defined
a
bunch
of
the
apis
like
file.open
file.writealtext,
blah
blah
blah,
and
there
would
be
a
concrete
implementation
which
literally
just
forwarded
to
all
of
that
stuff.
But
we
wouldn't
actually
change
any
of
the
types
in
the
bcl.
We
would
simply
introduce
these
two
new
types
in
some
package
somewhere.
D
A
Means
much
more
you
want
so
that
we
have
analysis
but
yeah,
I
would
see
even
an
asp.net
doesn't
require
an
eye
right,
like
I
said
it
before,
but
to
me
the
eye
and
extensions
in
asp.net
is
largely
a
fashion,
not
a
hard
requirement
right.
There
are
cases
where
you
need
an
eye
because
you
actually
expect
implementations
on
existing
types,
but
by
and
large
I
mean
the
asp.net
already
has
cases
where
they
inject
effectively
concrete
types
or
abstract
types
right.
A
Http
client
is
a
prime
example
for
that,
so
I
I
don't
think
that
that
would
be
a
deal
breaker
like
I
mean
we
could
put
it
in
system
and
make
it
literally.
You
know
system
clock,
not
I
system
clock,
and
that
would
be
fine
too.
I
think
it
would
largely
have
the
same
problems
as
extensions
in
the
sense
that
what
are
the
existing
features
will
actually
take
a
system
clock
to
begin
with.
But
you
know
you
don't
have
to
have
it's
technically
an
ioc
framework
for
that
or
a
di
for
that.
A
E
D
A
No,
I
agree
with
that.
I
mean
that's.
Why
that's
why
I'm
saying
to
me
the
the
end
to
end
for
these
things,
if
you
actually
want
to
have
it
for
the
entire
framework
will
be
hard,
but
even
even
if
you
put
it
in
system-
and
we
say
we
only
support
certain
areas
for
that.
That
might
still
be
good
enough
as
a
starting
point,
because
the
areas
we
supported
in
might
grow
over
time
right
and,
for
example,.
B
A
D
The
yeah,
but
for
things
like
you,
know,
file.readall
text
or
file.open,
which
is
returning
the
file
stream
like.
Yes,
there
are
places
where
we
have
statics
that
that,
in
order
to
be
more
di-friendly,
we
could
have
non-statics,
but
that's
just
sort
of
like
we
would
have
static
file
and
then
an
file
opener
class
that
the
default
like
that
exposes
all
these
same
things.
And
we
provide
no
implementation
of
right
and
right.
E
No,
I
don't.
I
don't
think
we
can
do
that
like
when,
when
you're
talking
about
di
like
you,
have
to
be
prepared
to
to
add
apps,
to
add
abstract
members
to
a
class
or
to
add
members
to
an
interface
like
this
is
di.
We
don't
expect
people
to
to
actually
like
in
to
to
create
subclassed
instances
of
these
within
their
libraries
and
then
ship
them,
because
if
they
did
that
they
should
expect
to
be
broken
from
version
diversion.
Well,
that's
just
how
gi
works.
A
E
No,
no,
you
don't
have
to
do
that,
so
the
the
way
that
these
would
be.
You
basically
have
to
throw
out
all
of
the
design
guidelines
and
consider
how
these
things
are
going
to
be
consumed
from
the
perspective
of
testing.
So
from
from
someone
writing
from
someone
writing
an
application,
they're
only
ever
going
to
see
the
interface
they're
never
going
to
instantiate
the
concrete
class
they're
going
to
let
their
devices
do.
B
E
Yeah,
but
let
me
finish
that,
from
from
the
fact
of
someone
testing
this
they're
going
to
be
using
a
framework
like
mock
you
to
test
this
they're,
not
going
to
be
broken
by
the
fact
that
we
added
members
to
the
interface
or
added
abstract
methods
to
the
base
class
like
they
expect
us
to
do
that
from
version
to
version.
That's
just
how
these
things
work
right,.
A
E
E
A
E
D
E
D
E
D
E
D
A
But
like,
let
me
just
go
back,
we
still.
We
just
spent
30
minutes
on
this,
like
I
don't
think
we
will
approve
it
or
reject
it
today.
So
like
what?
What
would
we
do?
I
mean
I
would
say
I
would
leave
that
out
and
I
would
say,
let's
have
a
broader
discussion
around
how
to
do
these
things,
but
this
particular
issue.
E
E
A
Well,
I
would
say
yes,
I
mean,
because
we
we
own
extensions
and
by
extensions,
has
a
lot
of
stuff
that
is
di-friendly
today.
Right
logging
is,
I
mean,
because
the
the
I
container
itself
is
the
eye,
and
we
own
all
of
that
too.
Right
so
like
that.
So
to
me
to
me
it's
just
a
continuation
of
like
where
the
framework
stack
do.
A
We
think
it
belongs,
but,
like
our
team
would
own
it
so
like
we
would
have
to
deal
with
it
right,
no
matter
what
we
decide
here,
I
mean
to
me
it's
more
like
the
this
particular
feature
to
me.
If,
let's
say
even
we
say,
we
only
put
it
in
extensions
right,
it's
still,
I
would
only
do
it
if
we
reconcile
the
other
existing
instances
of
our
system
clock.
I
think
it
defeats
the
purpose.
If
you
have
three
four
different
types,
all
called
I
system
clock
and
oh.
E
D
I
mean
yeah,
there's
the
there's,
there's
a
couple
aspects:
there's
what
layer
should
be
mockable
and
if
we
say
no
layers
ever
should
be
mockable.
Well,
the
fact
that
we
own
a
di
system
now
means
we
can't
say
that
if
we
say
that
the
stuff
classically
referred
to
as
the
bcl
we
continue
with,
we
have
the
design
guidelines,
they
effectively
exclude
mockability,
and
that
applies
there.
And
now
we
say
in
the
context
of
the
di
system
that
we
currently
own.
D
I
mean
imagine
that
the
ownership
changes
again
and
there's
a
new
team
dedicated
to
owning
the
di
system
that
never
talks
to
us
like
what
would
the
right
thing
for
people
using
that
system
be
saying
that
they
have
mockable
now
is
reasonable,
and
so
we
can
try
shaping
that
in
and
then
we
get
the
specific
problem
that
for
this
particular
concept,
there
are
already
two
existing
public
definitions
of
this.
That
the
whole
proposal
is
it's
terrible
that
we
have
at
least
two
public
implementations
of
this
can't
we
have
the
one
or
sorry
declarations.
D
Interface
and
so
the
question.
D
A
E
D
Super
care
at
the
level
of
things
in
system
right-
this
is
probably
within
the
tolerance
of
I
mean
asp.net
two
to
three
was
a
go
completely
rewrite
how
your
app
launches.
So
this
is
within
their
realm
of
acceptable,
breaking
change.
A
D
Right
well,
the
reason
for
doing
the
subclassing
there
would
be
so
if
you
were
already
referencing.
I
guess
I
don't
know
how
well
it
would
work
with
the
di
system.
If
you're
registering
against
the
wrong
eye
system
clock
it,
would
you
would
get
a?
I
couldn't
find
a
thing
that
implemented,
I
system
clock
and,
if
you,
but
if
you
registered
the
root
one,
it
would
show
up
for
both
derived
ones
with
the.
If
you
did.
B
D
Make
it
so
that
you
didn't
ever
talk
about
those
other
names,
because
if
you
do
the
two
usings
you'll
get
an
ambiguous
symbol
reference
right,
you
would
probably.
A
A
A
Yeah
so
yeah,
so
if
you're
in
the
authentication
code
right,
you
say
if
you're
using
statement
against
authentication,
because
you're
deriving
from
the
authentication
handler
and
the
constructor
takes
an
I
system
clock
that
happens
to
be
in
the
authentication
name
space,
and
you
also
have
a
using
for
let's
say
microsoft:
extensions
that
we
put
it
well
now.
The
question
is
which
which
I
system
clock
did
you
mean
right?
So
how.
D
There's
one
inside
a
namespace
named
internal,
which
is
the
pubternal
problem
and
then
there's
the
one,
microsoft
asp.net
core
authentication,
I
system
clock
and
I
don't
I
assume
that's
a
real
name
space
that
people
really
use
and
right.
I
guess
there
are
buttons
here
for
that.
D
Right,
but
it's
it's,
would
you
have
a
using
for
the
namespace,
because
if
so
now
I
system
clock
is
defined
in
microsoft,
extensions
primitives
in
some
namespace
and
microsoft,
extensions
or
microsoft,
asp.net,
core
authentication.
I
system
clock
as
a
bear
type
word
resolves
at
both
of
your
global
usings
and
you
need
to
disambiguate
it
with
a
fully
qualified,
namespace
or
using
alias.
A
No
like,
in
my
case
it
was
my.
It
was
the
actual
app
code
because
I
extended
authentication
handler
and
I
basically
had
to
define
the
constructor
and
the
constructor
just
does
forwarding
right.
I
take
12
arguments
and
I
pass
them
to
the
base
type
and
one
of
those
arguments
ends
up
being.
Yeah
basically
ends
up
being
a
system
clock.
E
D
D
A
Yeah,
I
was
about
to
say
it
seems
within
the
realm
of
what
we
have
done
in
the
past.
I
think
in
this
case
to
me
the
gymnastics
of
making
it
work
or
worse,
because
we
can't
hide
it
right.
I
mean
we
can
hide
it
from
intellisense,
but,
as
jeremy
just
explained
like
there's
still
a
long
tale
of
like
issues
around
having
all
these
three
types.
Now
so
I'd
be
actually
in
favor
of
saying
either
we
delete
the
types
or
we
don't
do
the
feature.
I
would
not
have
like
three
conflicting
eye
system
clocks.
That
seems.
E
E
A
D
Right
while
it
won't
break
apps,
because
there's
no
major
major
role
forward
is
off
by
default
right,
any
any
nuget
component
that
is
consuming
or
extending
the
existing
I
system
clocks
would
get
broken
right.
A
Well,
that's
why
that's
what
that
was.
My
scenario
is
right,
I'm
pretty
sure
if
you
go
to
asp.net
core
contrib,
which
basically
defines
a
bunch
of
authentication
handlers
right
for
google-
and
you
know
facebook
and
twitter,
I
guarantee
you.
If
you
search
for
a
system
clock
they
have
it
all
over
the
place,
because
the
constructors
take
it,
they
don't
actually
care
they
just
have
to
forward
it.
A
D
Yep
right
here,
if
you
extend
or
so
authentication
handler
of
t
options,
so
any
nuget
package
that
provides
an
authentication
handler.
D
A
And
again,
maybe
that's
okay,
because,
as
you
said,
you
can
trivially,
because
you
have
a
tfm
boundary.
You
can
trivially
like
do
an
if
diff
in
your
code,
I
mean
triple
right
but,
like
you
can
do
a
a
change
in
your
copays,
dual
publish
and
well.
D
Amusingly,
if
we
get
rid
of
the
old
one,
which
is
the
the
candidate
proposal
or
the
straw
man
we're
discussing
if
we
get
rid
of
the
old
one,
then
you
just
need
to
change
target
platform
to
target
platforms,
put
the
semicolon
and
put
net
five
and
when
it
rebuilds
the
net
five
package,
there's
only
one.
I
system
clock,
which
is
a
different.
I
system,
clock
and
everything
just
rebinds
the
trouble.
D
Yeah,
the
source
code,
it's
a
non-source
breaking
change,
assuming
you
have
all
the
correct
usings,
but
it
is
a
binary
breaking
change
and
yeah.
B
D
If
that's
the
realm
of
stuff
that
is
acceptable
in
in
the
domain,
we're
in
which
is
not
a
domain,
I'm
used
to
thinking
about
because
you
know
bcl,
the
answer
is
no
breaking
changes
ever.
I
know
we've
we've
moved
slightly
beyond
it
never,
but
we
would
never.
A
A
Yeah,
the
leading
types
is
pretty
much
a
non-starter
right
but,
like
I
think,
that's
that's
what
I'm
saying
to
me.
The
feature
is
like
the
the
discussion
really
is
like
for
I
system
clock
is
like.
Are
we
willing
to
do
that?
Breaking
change?
If
the
answer
is
no,
then
I
would
just
close
the
feature
I
think
having
three
types
with
the
same
names
makes
no
sense
to
me.
D
Well,
so
there's
so
one
option.
I
guess
one
way
that
we
could
do
this,
which
is
weird,
is
to
say
that
this
this
namespace
is
the
one
that
matters
and
it's
weird
that
it's
defined
in
this
name
space,
but
we
delete
the
other
one
and
we
move
it
to
the
primitives
library.
E
An
answer:
it's
not
a
great
answer
right!
I'm
I'm
not
terribly
sold
on
trying
to
keep
this
particular
api
stable
anyway,
because
when,
when
you're
talking
di,
you
don't
normally
have
an
abstract
class
with
a
protected
constructor
that
takes
injected
components
because
it
means
you
can
never
make
changes
to
this
in
the
future.
Without
breaking
your
subclass
types
right.
D
All
right,
so
I
guess
really.
The
answer
is,
if
you
can
get,
whoever
would
need
to
sign
off
on
the
asp.net
side.
So
I'll
just
say
fowler
if
you
can
get
fowler
to
buy
in
then
sounds
like
we're
just
good
to
go
and
whoever
you
means
in
this
case.
E
D
The
problem
is
the
name,
people
want
already
exists
and
the
reason
it's
the
name
they
want
is
because
it
already
exists,
so
we're
solving
a
circular
complexity,
problem
and-
and
so
that
has
a
unique
breaking
change
aspect.
If
someone
gave
the
proposal
of,
I
want
the
you
know:
file
opener,
whether
we
design
it
as
an
abstract
class
or
interface
or
whatever,
and
that
they
wanted
that
to
go
with
the
di
system.
I
think
that
we
would
be
okay.
Just
this
one
has
yeah
complexity.
D
Okay,
because
clearly
the
di
system
and
mock
ability
go
hand
in
hand,
but
the
the
other
issue
of
how
mockable
should
the
framework
be.
I
think
that
our
current
position
is
di-based
things.
Yes,
things
below
a
di-based
thing.
No,
so
I
agree
yeah,
that
seems
reasonable
system
packages
are
not
mock-up
or
system
packages
may
do
some
things
to
help
with
mock
ability,
but
they
are
not
themselves
designed
to
be
mockable
and
anything
that
talks
about
the
current
time
isn't
going
to
accept
a
time
provider.
A
D
All
right,
the
problem
with,
I
guess
the
execution
context
thing
is
six,
so
we
can
wait
until
steve
comes
back.
A
D
Levi
you're
here
and
I'm
sure
we
can
spend
the
rest
of
the
time
talking
about
this
one
thing.
So
do
you
want
to
talk
about
this
one
or
do
you
want
to
skip
it.
E
Public,
no,
that's,
I
think,
amo
does
that
enough
for
all
of
us.
Instead
of
looking
at
this.
A
A
E
Actually
that
one,
I'm
just
going
to
close
it
and
and
redirect
all
conversation
to
the
designs,
one
cool
21.
A
E
A
E
Yeah,
what
it
would
it
would
be
really
nice
if
we
had
like
c
sharp
language
support
for
dealing
with
gc
refs,
rather
than
just
straight
up
pointers.
But
until
that
comes
online,
we
we
have
to
do
hijinks
in
the
unsafe
class.
D
B
B
D
To
they
are
on
the
class
named
unsafe,
we're
back
to
my.
I
would
really
love
a
way
that
we
could
make
the
compiler
only
allow
this
in
unsafe
blocks,
not
not
because
any
particular
reason
other
than
there's
the
project
level.
Setting
of
should.
I
allow
unsafe
code-
and
this
is
a
you-
get
to
write
the
word
unsafe
without
checking
that
box
and-
and
it
would
be
nice
to
make
people
think.
E
More
funny
thing
these
two
apis
are
actually
fully
verifiable
and
type
safe.
It
is,
it
is
absolutely
valid
to
have
a
reft
that
points
to
null
the
the
type
safety
system
understands
it
and
supports
it
and
is
safe.
D
E
Yes,
it
does
actually
it
does
the
if
you
look
at
the
actual
code
gen.
All
of
it
is
guarded
against
the
fact
that
someone
might
be
passing
a
null
in
there.
A
It's
exactly
as
unsafe
as
an
unchecked
argument,
which
we
have
all
been
guilty
of
at
some
point
in
our
careers
right
and
the
world
hasn't
ended.
I
think
to
mean
yes,
it's
true
that
nobody
will
write
in
if,
if
ref
t
is
null
today,
because
you
can't
express
it
in
c
sharp
about
this
api
to
begin
with,
but
like
I
don't
think,
that's
terrible.
That
just
means
you
get
another
reference
exception
as
soon
as
somebody
does
something
with
that.
D
E
Yeah,
it's
an
argument,
no
exception
or
sorry,
no
ref.
A
D
You
know
two
overloads
one
that
takes
a
ref
whatever
and
another
that
takes
int
pitter,
so
I
can
pass
null
and
it
has
been
frustrating
that
I
can't
just
write
the
word
null
and
make
the
compiler
write
the
right
thing.
So
I've
I've
seen
places
that
I
would
use
this.
I
just
worry
about
the.
D
D
B
It's
worth
calling
out
that
we
had
the
debate
on
whether
it
should
be
refer
in
because
in
is
technically
more
appropriate,
but
vlad
and
yawn
pushed
back
against
that
on
the
basis
that
it's
very
easy
to
get
in
wrong
with
semantics.
That
c
sharp
set
up
for
it.
E
B
And
then
I
proposed
also
exposing
is
null
read
only
ref.
That
way
you
wouldn't
have
to
do
is
null
ref
unsafe,
as
in
t
to
get
it
to
work,
but
both
levi
and
yon
push
back
on.
It
doesn't
look
like
there's
necessarily
necessarily
clear
value
on
that.
E
Yeah
and
an
ideal
world
like
we
would
just
have
compiler
support
for
gcrefs,
but
actually
tanner
do
you?
Do
you
think
that's
something
that's
ever
likely
to
happen,
for
which
sorry
could
you
repeat
for
for
doing,
arithmetic
on
gc
reps,
as
opposed
to
regular
pointers.
B
B
Yeah,
so
we
we
approved
the
shaw
extensions
for
arm.
We
never
actually
reviewed
and
approved
them
for
x86.
So
this
is
doing
the
parody
thing
that
we
talked
about
when
we
reviewed
the
arm
intrinsics
of
let's
just
expose
them
like
we
did
with
aes.
B
B
B
D
Fair
enough,
I
see
that
it's
called
shaw
one
rounds
four
and
we
don't
have.
The
four
is
that
is
that
four
semantic.
E
While
tanner's
checking
that
we
do
have
a
work
item
to
create
an
analyzer
to
flag
uses
of
the
existing
aes
intrinsics,
I
would
imagine
that
we
would
want
to
flag
these
as
well.
From
that
same
analyzer,
saying
hey,
you
probably
should
be
using
the
built-in
class.
Unless
you
really
know
what
you're
doing.
B
D
Yeah
I
mean
the
if
there,
if
intel
assembly
suggests
that
it's
called
sha-1
next
d,
then
sha-1
dot.
Next
d
looks.
D
Reasonable
so
yeah,
my
only
like
all
right,
so
message
schedules
one
and
two,
the
c
plus
plus
intrinsic
or
I
guess
the
c
intrinsic
says
a
and
b
and
we
said
a
and
b
and
then
when
we
get
to
next
or
to
rounds
four,
it
says
a
and
b
and
we
said
state
one
state:
two,
our
names
are
probably
better,
but
I
note
that
they're
different
and
then
ask.
Is
there
a
a
better
name
for
a
and
b
in
the
previous
ones?.
D
D
I
mean
if
we're
gonna
put
it
as
a
suffix,
then
we
can
write
it
as
round
four.
If
we
want
it
as
a
prefix,
then
it
would
be
rounds
since
we
can't
start
with
a
number.
B
So
for
for
arm,
we
named
the
variables
w0
underscore
3,
w
4
underscore
7
w
8
underscore
11..
However,
we
we
don't
have
three
variables
here,
because
the
functionality
is
slightly
different.
D
Right
so
it
really
it's
yeah
it's
in
rounds.
They
were
called
state
one
and
state
two,
even
though
the
the
c
intrinsic
for
it
just
called
them
a
and
b,
and
if
we
found
better
names
for
the
one
in
rounds,
can
we
find
better
names
for
the
other
functions
and
that's
just
a
feedback
suggestion
for
them.
I
don't
know
that
we
need
to
actually
discuss
and
decide
the
names.
B
A
B
Yeah
and
then,
of
course,
the
thing
missing
here
that
would
be
included
is
the
get
is
supported
property.
I
just
noticed
they
were
missing.
B
D
Yeah
and
then
because,
if
nothing
else,
we
said
we
wanted
them
on
all
the
the
sub
classes,
I
guess
do
we
need
to.
We
don't
need
to
split
this
for
32
and
64.
B
So,
based
on
the
last
discussion,
they
would
now
have
x64
classes
that
that
report
nothing
and
expose
nothing.
They
are
leaf
nodes.
However,
so
we
don't
have
the
same
concern
that
some
of
the
other
isas
had.
D
Okay,
oh
right,
it's
the
yeah!
Okay!
I
got
you
yeah,
so
follow
the
pattern
with
all
the
types
and
so
what
name
do
we
want
for
the
rounds?
Are
we
just
going
to
call
it
we're
going
to
expand
the
word
rounds
like
we
have
and
then
put
a
four
on
the
end.
B
A
D
A
D
B
So
we
could
call
it
perform
four
rounds
of
the
shaw
one
hash
function.
B
D
B
I
actually
think
they
were
introduced
simultaneously,
but
x86
is
very
good
about
actually
splitting
into
logical
isas
without
requiring
all
of
them
to
be
implemented.
D
They'll
drop
the
the
sha-1
instructions
and
maybe
probably
not.
B
B
B
B
A
D
A
E
A
So
params
wouldn't
work
necessarily
because
the
there's
already
an
existing
second
argument
of
type
string
and
that
would
be
the
entire
command
line.
So
that
would
not
be
the
same
as
a
list
with
just
one
argument,
because.
E
D
E
B
Well-
and
I
honestly
don't
think
it's
easier
it
like
if
you're
having
to
when
you
have
something
that's
an
innumerable
or
a
collection
rather
than
like
params,
I
don't
think
there's
really
much
saved
over.
I
have
to
construct
it
and
then
pass
it
in
versus.
B
I
do
the
construction
and
then
I
call
item
dot
collection,
dot,
ad
range,
yeah.
D
I
mean
it
seems
like
they're
just
trying
to
they
want
this
code,
but
without
needing
to
say
the
word
argument
list
and
I,
if
we're
not
actually
helping
them
with
functionality,
we're
just
taking
an
existing,
I
mean
I
guess
we
would
because
it's
already
broken
apart.
So
we
would
just
be
copying
it
into
the
collection,
but
it
doesn't.
I
don't
see
where
it's.
D
A
B
D
A
A
D
Right
so
we
have
what
to
start
and
then
what
to
start
with
all
the
arguments
and
then
we
and
then
that
parses
the
arguments
to
populate
this
collection
and
then
the
request
is
overload.
This
constructor
with
the
enumerable
string
of
arguments
already
broken
out
in
the
segmentation.
You
want
them
to
be.
A
D
It's
probably
the
common
thing
you
want,
if
you're
doing
this,
maybe
yeah.
So
the
original
proposals
read
only
collection
somewhere
along
the
line,
adam
suggested
collection
so
that
it
didn't
have
to
new
up
a
new
one.
But
I
think
that
we
would
do
it
as
just
innumerable
of
string
and
if
we
get
params
I
enumerable
later,
we
could
consider
that.
But
we
probably
wouldn't
do
it,
because
it
would
be
ambiguous
against
the
string
string.
A
Yeah,
I
think
it
would
take
any
mobile
that
would
just
do
an
ad
range
on
the
on
the
inner
one.
I
mean
I'm
still
kind
of
questioning
the
wisdom
of
having
the
constructor
argument
at
all
yeah
to
me,
the
to
me,
the
the
real
kicker
here
would
be
the
static
method
that
would
actually
save
your
characters.
A
Because
that's
by
far
the
most
common
case,
like
I
mean
if
you're
new
at
the
startup
info,
you
might
as
well.
Like
that's
true
push.
D
D
D
A
A
Because
it
was
just
was
the
other
thing
like
we
should
make
our
lives
easier
with
proposing
api
changes,
because
the
number
one
thing
I
keep
doing
in
these
reviews
is
that
look
up
the
type
on
apisof.net
and
I
will
find
basically
the
existing
overloads,
because
you
kind
of
need
to
see
that
in
order
to
determine
whether
the
new
overload
makes
any
sense,
all
right.
So.
A
A
A
E
The
ones
that
don't
work
are
the
ones
that
take
credentials
and
I
think
those
still
work
on
windows.
Jeremy.
Do
you?
Are
you
familiar
with
those.
D
I'm
I'm
not,
but
I
I
think
that
we
brought
the
apis
back
just
for
net
standard.
Two
yeah,
like
we
probably
intentionally
left
them
out
of
core,
because
we
got
rid
of
secure
string
and
then
with
type
unification,
where
we
said
any
member
that
was
already
in.net
framework
on
a
type
that's
already
in
net
core
gets
brought
back
and
the
default
behavior
was
make
them
work
instead
of
just
like
it
exists.
Pnse.
A
So
here's
what
I
have
like,
if
you
just
refresh
the
thing
at
the
very
bottom
so
to
me,
it
seems
like
I
would
probably
remove
the
startup
info
thing,
and
I
would
just
approve
this
one
method,
because
that
one
seems
reasonable
to
me.
An
implementation
will
be
trivial
already
just
new
upper
process.
Startup
info
set
file,
name
initialize,
argument
listing
called
start
process
start
with
the
start
info
yeah
I
mean
that
will
be
a
trip
with
accelerator
and
I
think
that
will
probably
remove.
D
D
Yeah
I
mean
I,
I
don't
know
what
order
the
of
all
the
overloads
call
each
other,
but
but
yes,
that
that
would
be
a
functional
implementation
is
yeah.
I
would
I
I
mean.
I
think
you
convinced
me
emo,
that
the
process
start
info
constructor
doesn't
have
enough
value,
because
you
can
just
use
the
ad
range
on
the
existing
collection,
which
you
can
use
with
the
object,
initializer
and
collection
initialize
your
patterns
and
then
but
the
one
on
start
seems.
D
D
Fair
enough,
if
you
have
the,
if
you
have
literals,
you
can
do
it
with
a
collection
initializer
here,
if
you
are
wanting
to
add
one
collection,
add
the
enumerable
into
the
collection.
Then
you
would
need
to
make
it
a
two
statement
thing,
because
you
need
to
call
that
range
yourself.
D
D
Looks
good
to
me
it
is.
It
is
a
slightly
complex
overload
between
the
single
string
and
the
enumerable
of
string.
But
if
you
only
passed
one
thing
that
had
no
spaces,
then
it
would
be
equivalent.
D
D
A
B
D
F
D
Can't
do
that
as
a
single
expression,
new,
with
doing
the
add
range,
if
you
receive
the
thing
as
a
variable,
instead
of
a
list
of
literals
or
a
list
of
single
arguments
like
it's
still
doable
we're
just,
we
would
be
making
it
easier
to
do
massively
long
statements
and
that's
not
a
thing.
We
generally
optimize
for
right.
D
A
A
D
Right,
I
mean
you
certainly
should
never
call
process
dot
start
with
new
process.
Start
info
string,
string,
close
paren,
close
paren,
because
right
because
that.
A
A
All
right,
then,
let's
see
where
this
lands
and
then
let's
go
to
the
next
one.
D
B
So
this
one
is
basically,
let's
expose
cpuid
we'd
return,
a
value
tuple,
and
we
would
explicitly
use
the
names
eax
ebx,
ecx
and
edx
matching
the
register
names,
because
there's
a
variant
of
functions,
basically
that
it
can
return
and
there
is
no
better
meaningful
name
for
it.
B
It's
always
the
32-bit
register.
Okay,.
D
E
So
if
I
remember
correctly
tanner
one
of
the
reasons
that
we
were
looking
at
this
is
because
we
were
trying
to
figure
out
if,
if
we
were
able
to
call
some
of
the
bmi
2
functions
on
our
current
processor.
B
So
we-
yes,
that's
one
thing
you
could
use
it
for
we
likely
wouldn't
use
that
ourselves
in
the
run
time,
just
because
there
wasn't
big
enough
of
a
perf
gain
and
because
it
increases
our
test
complexity,
the
the
actual
test
matrix
to
make
sure
we're
covering
everything,
but
other
developers
could
do
things
like
create
a
static
read-only
field
that
performs
the
is
authentic
amd
check,
cache
it
and
then
use
that
which
the
jit
will
then
convert
to
a
constant
to
perform
their
own
optimizations
like
that.
E
B
Yeah,
most
of
the
other
ones
are
covered
by
the
existing
is
supported
methods
I
listed
some
possibilities
in
the
proposal
here,
for
example,
is
authentic.
Amd
is
genuine
intel,
the
caching,
the
max
function,
id
getting
the
tl
b
sizes
or
the
cache
line
sizes
yawn
is
currently
pushing
back
against
exposing
those
and
just
indicating
he
thinks
devs
can
cache
them
in
a
static
read-only
field
where
they
need,
depending
on
what
request
we
get
that
may
change
in
the
future,
and
we
may
expose
additional
properties
for
that
stuff.
B
B
B
B
So
well
not
an
object.
The
proposal
so
technically
speaking,
cpu
id,
is
not
considered
a
baseline
instruction
right.
It
is
so
the
way
you
you
the
way
you
query
for
cpu
id
support
is
you
have
to
write
to
the
id
bit
of
the
flags
register,
which
is,
if
I
remember
correctly,
it's
immutable
on
older
processors
and
it's
mute
mutable
on
ones
that
support
it.
Maybe
I've
got
the
reverse,
though,
and
once
you've
done
that,
then
you
can
use
cpu
id
for
all
the
remaining
purposes,
but
yawn's
pushback
was.
B
He
doesn't
think
that
it
warrants
an
individual
class
just
for
cpu
id,
even
if
we
decide
to
expand
in
the
future
with
additional
cash
properties
and
such
and
with
it
being
a
20
year
old,
well,
20,
26
year
old
function,
that's
been
on
everything
since
basically
the
second
iteration
of
32-bit
x86
processors,
it's
not
worth
separating
it
out.
We
should
just
treat
it
as
baseline.
E
Does
this
mean
that
all
of
the
other
x86
intrinsic
types
would
now
subclass
x86
base.
B
Yes,
we
actually
already
have
x86
base,
but
it's
internal
and
we
expose
the
explicit
some
of
the
explicit
lz
count.
Alternatives,
for
example,.
E
E
B
B
While
we
have
the
big
mole
and
divrem
on
system.math,
there
is
explicit
special
functionality
exposed
by
the
cpu
specific
instructions
that
you
can't
necessarily
expose,
for
example,
taking
a
128
taking
a
128-bit
integer
split
into
two
registers
and
dividing
it
by
a
64-bit
dividend.
E
Okay,
yeah,
I
I
didn't
mean
to
imply
that
we
need
to
enumerate
all
of
them
right
now.
I
was
just
thinking
that,
if,
if
you
did
have
some
that
you
wanted
to
add
in
the
future,
then
putting
it
on
x86
base,
you
know
sets
the
nice
foundation
for
all
of
that
right.
D
So
if
we
wanted
to
add
the
utility
type
for
cpuid
semantics,
where
would
we
put
that
if
we
take
this
proposal,
as
is.
D
B
Oh,
I
would,
I
would
just
suggest
exposing
them
on
the
same
isa
that
exposes
cpu
id
itself.
D
Okay,
so
you
would
just
make
them
be
static,
properties
on
x86
base,
yeah,
okay,
like
because
the
my
question
here
is
really
just
are
we
by
taking
this?
Are
we
blocking
a
thing
that
you
think
might
we
might
want
to
do
in
the
future?
But
if
you
haven't
known.
D
And
then
I'm
gonna,
I
don't
actually
care,
but
I'm
gonna
ask
because
it
would
be
cute
is.
Is
the
jet
going
to
understand
that
the
best
assignment
of
the
register
return
from
this
is
in
fact
to
not
assign
them?
If
somebody
deconstructs
it.
B
It
is
the
fully
serializing
instruction,
the
only
fully
serializing
instruction
and
we're
not
going
to
worry
about
the
semantics
or
mess
with
the
register.
Allocator
we're
just
going
to
treat
it
as
a
cue
call
to
the
c
plus
intrinsic
and
let
them.
E
D
Depends
on
whether
you're
afraid
of
spectre,
if
so,
call
it
a
lot
the
yeah
I
I'm
torn
on
the
casing
of
the
names
of
standard
pascal
or
go
full
caps
or
or
go
full
flat.
D
All
of
them
seem
justified
I'll
I'll
do
whatever
or
I'll
agree
with
whatever
emo
says,
emo.
A
Yeah
I
mean
it
breaks
me
on
the
one
hand,
side,
on
the
other
hand,
though,
like
basically
when
people
call
this,
they
would
probably
immediately
deconstruct
it
anyways
into
locals,
in
which
case
they
will
be
all
lowercase,
so
I
don't
think
it
matters.
I
would
probably
just
stick
to
the
naming
convention
too.
We
just
don't
have
oddity.
B
E
B
E
D
What
does
it
looks
like
the
cpu,
ide,
x,
c,
plus
or
c
c,
plus
plus
version
of
it
calls
it
function?
Underscore
id
and
sub
function
underscore
id
so
yeah
yeah
we're
matching
the
names
that
they
would
understand
already.
B
D
E
A
All
right,
so
it's
it's
approved.
A
D
B
B
A
A
B
A
D
B
A
B
Well,
no
just
it
looks
like
several
of
the
upcoming
issues
are
mined
so.
A
Yeah
so
like
we'll
be
so
the
so
the
nice
thing
is,
I
think
we
we're
now
down
to
18
issues.
A
The
oldest
one
we
now
have
is
one
that
I
just
looked
at,
which
is
the
start
process.start,
which
is
six
years
ago,
and
then
everything
else
is
14
months
or
younger,
so
like
we
are
now
actually
so,
ideally,
when
we're
done
tomorrow,
we
should
be
everything
is
younger
than
six
months.
I
mean.
D
D
A
E
D
I
mean
it's
reasonable.
It's.
B
I
can
talk
to
jeff
in
my
one-on-one
today
and
see
what
he
thinks.
I
don't
think
there's
a
particularly
strong
need,
because
they're
largely
just
helper
apis
for
things
that
you
could
all
that
you
can
do
using
other
apis
already
or
manually
right.
D
Okay,
what
I
did
for
crypto
just
to
make
sure
we're
all
on
the
same
page
as
anything
that
I
thought
that
somebody
might
go
want
to
open
a
pr
for
while
five's
still
open.
I
I
let
them
be
five
for
review
and
then,
as
soon
as
we
reviewed
them,
I
moved
them
back
to
future
for
implementation.
B
C
D
If
someone
might
want
to
implement
it
now
from
the
community,
then
we
should
get
the
api
shape
approved,
so
they
have
the
option
and
otherwise
just
let
it
let
it
float
the
future.
A
And
it's
just
marketing
for
500,
because
I
mean
the
approval
I
mean
like
the
backlog
is
so
short
right
now,
there's
nothing
more
important
anyway.
So
right,
if
we
get
it
approved
good,
if
we
don't
implement
them,
also
good
right
like
it's
just
when
do
we
want
to
review
it
yeah,
so
I
just
marked
it
and
now
it
will
show
up
at
the
top.
B
A
Yeah
I
stay
on
the
call
with
you
and
then
we
just
publish
the
notes.
Yep.