►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
B
C
I
think
the
yeah,
the
next
step
I
mean,
I
think,
from
all
point
of
view.
I
don't
really
care
how
you're
doing
it.
So
I
think
you
don't
need
our
approval
for
any
of
that.
I
don't
know
what
we
do
normally
for
app
compat
switches,
but
also,
I
assume
I
don't
think
it's
called
appcompat
right.
It's
called
app
context,
I
think,
is
the
name.
D
B
D
E
Used
so
my
take
here
is
that
requires
assembly
files
has
a
decent
message
by
default,
like
if
you
don't
put
in
a
message,
the
the
tooling
gives
you
a
decent
message
saying
what
about
this
method
setter.
So,
basically,
though,
the
proposed
api,
well,
the
proposed
api
here
with
the
first
line
not
read.
E
F
G
F
E
F
F
Sure,
but
in
this
case
it's
you
can
specify
a
message
or
the
default
one
will
be
provided
for
you.
It's
not
really
changing
the
behavior
of
the
attribute,
so
probably
the
reason
that
this
one's
avoid
instead
of
do
not
right.
F
And
then
the
other
thing
is
about
a
third
of
the
important
attributes
are
interpreted
by
things
that
are
looking
at
the
il
and
it's
don't
make
them
have
to.
C
B
C
H
Name
to
distributed
context
propagator,
we
discussed
briefly
in
the
api
review
whether
we
want
more
control
in
the
h2b
client
stack
other
than
just
the
global
default.
H
We
decided
that
we
do
so
we're
proposing
exposing
a
property
and
sockets
hp
handler
to
let
you
control
that
the
name
we
came
up
with
for
socket
search,
beginner.
Yes,.
C
H
C
H
Be
all
of
them,
it's
just
that
sockets
hp
handler
would
be
the
only
one
where
we
see
the
need
to
have
it
actually
configurable
at
this
level,.
C
C
H
Commonly
enough,
but
as
you
said,
we
can
decide
in
the
future
that
to
add
it
there
as
well.
I
see.
C
H
C
C
H
C
C
F
C
H
C
C
C
So
then,
unbelievably
we
actually
done
with
the
red
stuff,
and
now
I
just
opened
the
the
wrong
one,
so
I
actually
have
some
time
left
to
walk
the
backlog.
Can
anybody
talk
to
this
one.
I
Sure
this
counts
here
we
got
a
request
to
basically
add
the
the
optional
name
that
can
be
pervas,
provided
to
some
of
the
various
derived
weight
handle
types
that's
provided
to
the
constructor
just
to
surface
it
on
the
as
a
property.
I
think
I
thought
it
got
edited.
I
thought
the
proposal
got
edited.
Is
there
an
update
from
account
somewhere.
I
C
I
I
Oh,
it's
it's
abstract.
So
there
are
things
like
event:
weight
handle
which
derives
from
weight,
handle.
C
I
The
same
way
it
does
today,
which
I
believe
is
internal
font.
Oh.
I
C
I
Trying
to
bring
up
the
source,
that's
actually
a
good
question.
I
thought
it
was
calling
an
internal
constructor,
but
it's
not
in
fact.
You
probably
can't
technically
make
it
abstract.
You'd
have
to
make
it
virtual.
J
Are
effectively
required
to
specify
additional
parameters
for
them
to
work
as
expected,
or
by
valve
array
in
particular,
you
need
to
specify
size,
cost
gotcha.
J
C
F
C
F
J
Oh
yeah,
so
there's
unmanaged
type.
Sorry
there,
there's
by
valerae
and
bival
t
str
for
string
I'll
just
post
it
in
chat
that
will
be
sweet
but
yeah,
but
both
of
those
are
effectively
the
same.
It's
just
the
t
string
is
characters
and
it
picks
ascii
versus
utf-16,
based
on
or.
F
F
Yeah,
I
feel
like
bivaltyster
would
be
the
same
diagnostic
id
because
it's
the
same
size
const
is
required,
so
it
would
just
be
a
that's,
probably
not
worth
the
code
it
would
take
to
do
it.
F
Value
I
mean,
is
it
only
two
or
does
it
will
it
treat
a
negative
number
as
an
unsigned
end.
I
I
All
the
argument,
all
the
argument-
exceptions
at
a
minimum
and
maybe
some
other
exception
types-
have
a
static,
throw
method
or
static,
throw
overload,
basically
one
for
each
constructor,
the
idea
being
that,
rather
than
just
constructing
an
instance,
it
would
also
throw
that
instance
that's
sort
of
the
original
proposal
from
martin.
I
I
suggest
that
we
constrain
it
to
just
being
for
argument
null
exception
in
particular,
because
there's
only
one
thing
it's
checking
for
and
it
can
easily
you
know,
do
the
check
for
you
so
rather
than
having
to
write,
if
condition
and
then
call
argument
all
exception,
throw
you
can
just
call
argument
null
exception,
throw
and
pass
in
the
argument
in
the
argument
name,
you
can
imagine
doing
something
similar
for
the
other
argument,
exceptions
as
well,
but
it
becomes
more
complicated
there.
So
well.
D
H
I
I'd
also
proposed
doing
this
as
something
that
the
c-sharp
compiler
could
then
target
for
its
null
checking
feature
that
may
or
may
not
make
it
into
c-sharp
10.
But
if
not
c-sharp
10,
almost
certainly
c
sharp
11,
which
is
you
can
say,
you
know,
parameter
bang,
bang
and
it'll
inject
the
check
for
you
and
the
original
idea
was
its
injected
check
could
simply
be
to
call
this
method.
I
However,
after
lots
of
discussion
of
all
the
various
you
know
possibilities,
the
current
plan
is
actually
that
it's
just
going
to
inject
a
helper,
almost
this
exact
helper
into
every
assembly.
That
needs
it
the
reason
being
that
for
r
to
r
code,
this
check
would
not
end
up
getting
inlined
because
of
the
cross
version
from
whatever
the
assembly
was
into
corlip,
and
so
it
could
actually
for
anyone
relying
on
r
and
not
using
tiered
compilation.
I
It
could
actually
be
a
de-optimization
for
the
compiler
to
end
up
using
this
method,
rather
than
one
that
was
in
the
same
assembly.
So
this
argument
null
exception.
Helper
would
purely
be
sort
of
back
in
the
original
spirit
of
what
martin
provided,
not
something
the
compiler
would
use,
but
at
least
not
for
the
foreseeable
future,
just
something
to
help
a
developer
clean
up
their
code
a
little
bit
if
they
wanted
to.
F
I
So
there
are
various
things
to
consider
here.
Would
we
want
something
specific
to
argument
null
exception?
Would
we
want
something,
for
you
know,
do
we
care
about
saving
just
the
throw
in
the
il
versus
the
more
complicated
thing?
If
you
do
it
on
all
the
argument,
exceptions
or
all
exceptions
in
general
there's
and
for
the
latter
it
certainly
hasn't
been
designed.
F
J
If
you're
tier,
zero
or
doing
debug,
then
it
may
result
in
potentially
worse
code
gen
and
it
it
may.
It
may
cause
the
jit
to
not
be
able
to
do
some
basic
flow
analysis.
It
might
otherwise
be
able
to
do
in
debug
programs
and
also
have
the
the
kind
of
throw
if
or
throw
four
type
methods
that
also
do
argument.
Validation
in
places
and
I've
got
them
for
standard
patterns
like
not
zero
null
negative
and
things
like
that.
J
I
would
yeah,
I
would
hope
that
c
sharp
could
ultimately
use
this,
and
so
it
would
just
be
a
central
api
and
that
there
would
be
no
ultimate
issue
with
marking
this
as
a
non-versionable
api.
Much
like
we
do
with
most
of
math
and
other
core
functions
sure,
but
I
think
that's
a
question
for
yon
and
if
yon
would
say
yes,
then
it's
a
no-brainer
to
expose
it,
because
then
c-sharp
doesn't
have
to
emit
a
stub
in
every
single
assembly,
and
especially
if
someone
wants
to
check
it
in
the
next
45
minutes.
F
So
that
we've
got
two
more
days
now
so
noon
became
noon
on
thursday.
D
F
J
I'd
say
the
same.
Another
question
on
my
end,
though,
is
with
the
with
4.9
in
particular,
and
with
the
advent
of
exception
and
but
more
generally
applicable
to
all
exceptions
via
a
small
core
type.
F
Maybe
like
I
don't
know
that
we
just
want
to
replace,
you
know,
throw
new
argument
null
exception
with
throw
argumentnolexception.create
right
or
sorry.
I
guess
argument
nullexception.throw
and
then
that
replaces
the
parameters
with
the
like,
invokes
the
constructor
and
throws
it
like
that.
I
J
J
But
for
you
my
general
point
was
that
for
applications
and
scenarios
that
do
use
throw
helpers,
they
chan,
they
tend
to
use
them
extensively,
and
so
therefore
they
do
end
up
doing
things.
Like
sum
class
dot,
throw
law,
and
if
there
was
a
pattern
to
make
that
simple,
then
we
can
not
expensively
support
them
without
necessarily
having
to
go
modify
all
of
our
own
types.
F
J
Like
the
keyboard
does
exist
and
that's
the
default
pattern
and
we
likely
want
to
encourage
users
to
continue
following
that
pattern
for
normal
code,
but
for
the
users
who
do
like
this
one
specifically
tagged
size
reduction,
because
if
you
look
at
our
own
libraries,
every
single
one
of
our
libraries
has
throw
helpers
internally,
sometimes
duplicated
from
assembly
to
assembly.
J
I
C
I
F
Yeah
yeah,
because
you
could
pass
to
this-
you
know
throw
if
null
foo,
dot
bar
and
then
the
caller
argument
expression
will
capture
the
string,
foo
dot
bar
and
it
will
throw
a
thing
that
kind
of
makes
sense,
but
isn't
actually
a
parameter
name,
so
you're
not
getting
a
good
mapping.
So
the
ideal
call
of
this
is
just
throw
if
null
through,
where.
I
I
F
Yeah,
so
for
me
that
there
would
be
some
utility
on
some
things
like
argument
out
of
range
exception
for
having
throws
that
better
use
the
standard
strings
right.
So
we
have
like
in
all
of
our
assemblies
we
copy
the
resource
for
non-negative
value,
etcetera,
and
so,
if
I.
I
F
F
Yeah
yeah,
if
we
say,
like
you
know,
throw
argument
out
of
range
exception,
throw
positive
required
or
like
whatever
then
now,
a
we've
clarified.
That
argument
out
of
range
exception
is
where
we
want
that
everywhere
and
b
that
that
now
everywhere
gets
the
same
message
and
we
can
stop
the
duplication
and
all
of
our
resource.
I.
I
I
Well,
increasing
the
scope
to
include
what.
I
That's
not
how
I
see
it.
In
fact,
like
I
we're
only
going
to
go
through
dotnet
runtime
once
changing
our
7000,
something
like
that.
You
know
if
null
throw
I'm
not
going
to
go
through
and
change
all
of
them
to
use
argument
null
exception,
throw
if
no
we'll
wait
for
the
language
feature
to
do
that.
This
will
end
up
being.
F
Used
but
speaking
of
now
that
we
have
more
runway,
I
I've
marked
a
an
obsolete
proposal
for
six.
F
Yep,
all
right
so
crypto
config,
which
is
one
of
my
least
favorite
types,
has
a
method
called
encode
owid,
which,
given
an
o
string,
returns
the
byte
array
that
represents
that
o
it.
F
If
you
give
it
a
string
that
is
in
the
range
of
things
that
it
does
correctly
and
is
valid,
then
it
will
give
you
a
right
answer,
but
it
supports
a
whole
lot
of
wrong
answers
that
it
returns
like
things
that
are
nonsense,
that
it
returns
answers
for
it
also
doesn't
correctly
handle
all
legal
inputs,
and
when
we
looked
at,
can
we
reconcile
these
things
to
make
it
produce
right.