►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Because
I'm
a
goof,
I
didn't
switch
to
the
intro
screen,
so
we're
live
all
right,
great,
so
hello,
everyone!
It
is
thursday,
so
we're
on
an
overflow
session
and
I've
been
going
fast,
so
my
brain
hasn't
caught
up.
A
Yet
we
have
an
awful
lot
of
red
and
I
am
in
a
strange
place
today,
so
instead
of
my
wonderful
4x3
monitor
that
we
generally
get
to
host
in
the
stream
here,
I
have
this
weird
1080p
monitor
that
I
can't
convince
to
go
4x3
so
we're
a
little
wider
than
normal,
but
in
other
news
I
finally
have
something
that
can
do
syntax,
highlighting
so
no
more
notepad.
For
me,
you're
welcome
all
right
with
that
out
of
the
way
and
a
camera
that
can
see
me.
Presumably,
can
I
see
me
I
can
see
me.
A
I
call
this
meeting
to
order
there.
We
go.
A
A
All
right,
I
think
we
had
a
agenda
in
addition
to
the
thing
oh,
and
we
have
a
a
guest
today
for
the
first
issue,
so
that
makes
sense
that
monitors
to
the
right,
okay,.
A
It's
going
I'm
in
a
breakout
room
on
campus
today
and
that's
throwing
everything
off.
A
Yes,
you
can
see
the
industrial
concrete
behind
me
all
right
that
ability
to
detect
if
a
service
is
registered
in
the
di
container
issue.
Five:
three
niner
one
niner.
D
So
I
can
give
the
motivation
for
this
kind
of
the
quick
summary
if
you
want
in
asp.net
we're
looking
at
better
inferences
for
action
parameters.
Basically
that
go
into
like
controller
actions
more
or
less
and
right
now
is
an
attribute.
D
Sorry
did
someone
say
something:
okay,
so
right
now,
you
would
use
an
attribute
like
from
services
to
indicate
that
you
want
this
parameter
to
be
to
come
out
of
the
bi
container
and
recently
4.06
we've
been
looking
at
better
ways
to
kind
of
infer
this.
So
right
now
for
some
of
our
new
apis
right
now.
We're
just
assuming
that,
like
any
interface,
is
probably
a
service,
and
we
don't
like
that.
D
You
can
always
use
attributes
if
you
want
to
be
very
explicit,
but
this
is
kind
of
a
best
effort
kind
of
thing,
and
we
want
containers
to
basically
tell
us
whether
a
type
that
we
might
try
to
resolve
from
the
container
in
fact
can
be
resolved.
But
we
don't
want
there
to
be
any
side
effects.
We
don't
want
to
actually
like
call
the
constructor,
because
that
could
cause
problems,
so
we're
really
asking
if
there's
a
registration
but
then
there's
the
whole
debate
in
the
comments
about
the
naming.
D
So
his
service
is
what
like
is
our
best
proposal.
I
think
right
now,
as
far
as
the
name
goes.
D
So
another
question
comes
that
came
up
in
the
discussion
is
how
you
use
this
interface.
There
have
been
two
patterns
that
we've
already
used
for
di
one
is
to
have
the
I
service
provider
also
implement
another
interface
that
was
proposed
in
the
comments
I
think
by
eric
there's
another
pattern.
That's
used
by,
like
I
service
scope
factory,
which
is
you
resolve
the
interface
out
of
the
container.
D
This
is
more
flexible.
It
can
help
with
layering.
For
some
third-party
libraries,
like
I
said,
there's
precedent
both
ways.
I
could
see
someone
like
mocking
up
this
kind
of
service
and
it
being
somewhat
useful
and
that's
another
reason
I
like
it
being
in
the
container.
D
Because
that
could
end
up
doing
I
o
and
things
of
that
nature
as
it
tries
to
construct
the
the
service
and
we'd
rather
not,
especially
during
just
like
kind
of
build
time
like
our
initialization
time,
like
startup,
when
we're
basically
determining
what
each
like
action
parameter
means.
D
F
G
I
think
I
think,
that's,
I
think,
that's
cool
and
I'm
all
over
this.
I
I
like
the
naming
is
service.
That
kind
of
thing.
The
challenge
I
ran
into
with
some
of
the
naming
was
it's
really
difficult.
When
I
see
an
api-
and
I
say,
can
I
do
this
and
it
says
yes
and
then
I
try
to
do
this
and
it
says
no
and
it's
like
wait
a
minute.
You
just
told
me
I
can
and
I
feel
like
it's
the
difference
between
your
mom
saying.
You
know
you
say:
hey
mom.
G
F
But
if,
if
this
api
returns
true
and
your
actual
get
service,
api
returns
null,
wouldn't
that
ostensibly
be
a
bug
in
the
di
system.
G
Well-
and
that's
that's
that's-
the
big
question
here
is
is:
is
service
implies
that
I
it's
registered
in
the
container.
You
can
query
for
it,
but
it
may
not
necessarily
resolve
correctly
for
reasons
like
a
dependency
of
that
thing.
That
you're
asking
for
is
also
is
not
registered.
It
doesn't
actually
walk
the
tree
and
verify
that
everything
is
perfect
and
set
to
go.
It's
just.
Is
it
even
present
and
able
to
be
queried
for.
F
D
Okay,
so,
to
give
a
little
bit
of
background,
as
far
as
the
naming
thing,
the
original
proposal
was
can
get
service
which
more
implied
what
like
travis
was
talking
about,
like
that
it
would
just
work
and
then
there's
the
suggestion
that
we
changed
it
to
is
registered,
which
I
didn't
like,
because
you
might
be
able
to
get
a
service
that
isn't
like
explicitly
registered
like
with
interval
and
stuff
like
that.
So
I
think
is
service
is
the
best
name
that
we
come
up
with
so
far.
C
D
Right
so
during
startup,
when
we're
basically
figuring
out
what
controller
actions
in
mvc
are
right
so
like
what
the
parameter
sources
are
so
like,
is
it
coming
from,
like
the
request
body,
a
parameter
right
like
versus?
Is
it
coming
from
a
di
container?
We
would
use
this
potentially
for
inference.
Now,
if
you
don't
like
what
the
inference
is,
you
can
explicitly
use
an
attribute
to
tell
you
what
the
source
of
the
parameter
is,
but
this
is
trying
to
reduce
kind
of
that
attribute
noise.
D
D
We'd
fall
back
to
another
source,
so
in
that
case,
like
you
might
look
at
like
the
record,
because
the
request
body
makes
sense
or
something
this
is
the
current
thinking
yeah.
I
guess
my
question
is.
C
So,
basically,
would
you
would
you
have
code
along
the
lines
of
like?
If
not
a
service
then
add
a
service?
Basically
so
or
is
this
is
the
assumption
that
if
you
call
this
service
that
the
I
system
is
effectively
already
frozen
or
will
be
frozen
by
calling
the
method
or
is
the
expectation
you
can
call
it
it
gives
you
an
answer,
then
you
can
register
more
types
and
then
you
get
back
a
different
answer.
D
G
C
C
F
There
are
existing
interfaces
that
are,
I
support.
I
support
required
service.
D
D
Okay,
so
these
are
things
as
far
as
the
I
interval
string
right
now
we
with
some
of
our
new
action
apis,
we
infer
that's
a
service
already,
because
it's
an
interface
in
the
future.
D
H
Instead
of
I
support
service
query,
would
it
make
sense
to
have
this
be
like
an
abstract
base
class
of
service
metadata
to
describe
the
container.
H
G
You
did
expand
it,
I
wouldn't
want
it
to
be
like
okay.
Now
I
not
only
want
to
query
this,
but
I
also
want
to
be
able
to
list
everything
at
least
from
an
again
from
an
auto
fact
perspective,
that's
kind
of
expensive
and
it
doesn't
account
for
a
lot
of
the
dynamic
stuff
that
happens
underneath
the
covers.
So
I
can
answer
this
question
very
easily.
I
couldn't
answer
necessarily
all
the
questions
you
might
want
to
put
into
a
metadata
about
container
sort
of
thing.
C
Yeah,
I
also
think
that,
normally,
when
we
say
we
prefer
abstract
based
classes,
it's
really
because
people
pass
one
instance
of
something
around
right
and
then
adding
new
things
to
it
isn't
isn't
simple
right
if
you
pass
an
ifu
around
it
and
we
want
to
have
an
iphone
2
now
people
always
have
to
try
cast
the
ifu
right,
but
with
this
whole
pattern
of
services,
well
you!
Basically,
if
you
pass
around
anything,
you
possibly
want
a
service
provider
or
you
import
the
things
so
like
it
really
doesn't
make
a
difference.
C
Whether
you
have-
and
I
support
service
query
one-
and
I
support
service-
query
too,
because
you
just
ask
for
the
one
that
you
care
about
and
now
they
become
all
independent
features
right.
So
it's
yeah,
it's
kind
of
clear
where
this
is
going
yeah.
It's
called
com.
D
H
If
having
one
interface
per
method,
is
you
know
more
di
appropriate
than
I
think
it's
fine
to
keep
it
that
way.
C
The
naming
kind
of
my
question
was,
when
you
have
an
eye
support
to
me.
It
kind
of
implies
a
tricar,
so
I
would
have
expected
that
you
would
cast
the
service
provider
to
an
I
support
service.
Query
like
it
seems
a
bit
odd
to
have
something
that
is
a
service
to
basically
say
I
support
service
query
rather
than
you
know
something
that
ends
in
service.
Basically,
there
was,
there
was
more
than
going
with
the
naming
question.
D
C
B
I
just
wanted
to
confirm
this.
I
support
service.
Query
is
optional
right,
it's
not
and
who,
who
registers
it,
who
implements
this?
Is
it
do
we
have
it
built
in.
D
So
it
will
be
optional
because
it
wasn't
in
version
one
out
right,
but
yeah
it'll
be
like
I
service
scope,
factory,
it
will
be
implemented
by
the
container.
D
I
D
It
so
it
should
return
false
if
git
service
would
return
null
for
the
same
type.
It
should
return
true.
Otherwise,
so
that
means
it
could
throw,
and
it
would
still
like
this
is
service
thing
would
still
return
true,
but
the
idea
being
you
just
can't
possibly
know
whether
or
not
actually
instantiating
the
service
would
throw
until
you
do
it.
D
E
On
the
name,
just
oh,
it's
one
question,
it's
one
question,
so
I
can
understand
the
semantics.
So
what
what
are
the
decisions
that
one
makes
so
this
returns
true?
What
are
the
decision?
One
makes
on
that
without
query.
Actually
then
querying
for
the
interface,
because,
as
you
say,
it
could
fail
to
query
what
what
can
you
do
without
actually
trying
to
get
it.
D
So,
let's
start
up
right
when
we're
building
like
our
open
api
like
swagger
stuff,
we'll
say
that
hey
this
parameter,
we
expect
to
come
from
a
service
and
because
there
are
no
attributes
right,
but
the
container
told
us
that
it
can
give
us
that
and
it
and
it
won't
change
right.
So
then
we
don't
dynamically
change
like
where
a
parameter
comes
from
at
run
time,
based
on
like
what
git
service
is
doing
like
this
is
a
static
thing
for
the
lifetime
of
the
application,
at
least
that
we
can
determine.
D
B
E
D
So
it's
a
different
error
today,
like
if,
if
something
has
like
the
from
so
we're
changing
the
behavior
as
far
as
inference
to
use
this
right,
but
today
we
assume
that
any
interface
is
a
service
in
this
api.
We're
talking
about.
So
if
git
service
returns
and
all
there's
an
exception,
that's
thrown
and
logged
that
will
be
like
the
service
wasn't
found.
D
I
I
think
the
really
good
use
case
is
the
first
one
listed
in
the
issue
for
activator
utilities
trying
to
pick
which
constructor
it's
above
this
actually
for
activator
utilities,
trying
to
pick
which
constructor
because
like
say
you
have
a
class
and
it
has
10
constructors
on
it
all
with
different
overloads.
Trying
to
find
out
does
this
parameter
have
a
service
right.
If
you
have
one
a
b
and
c
parameters,
or
is
there
services
for
each
one
of
those
and
today
it
can't
do
that
without
they
just
can't
do
that
today,.
A
But
that's
not
necessarily
going
to
go
deep
right
like
it
would
just
it
would
get
you
one
level
closer,
because
if
each
of
a
b
and
c
itself
depended
on
ten
things,
I
don't
think
the
expectation
is
this
is
going
to
ask.
Could
I
then
also
figure
out
how
to
construct
those?
So
that's
the
difference
between
get
throwing
and
or
when
it
returns.
True,
someone
called
the
register
singleton,
but
no
one
actually
proved
that
it
could
be
instantiated.
I
It
lets
you
skip
over
the
ones
that
you
know
just
aren't
going
to
work
right
right
that
that's
the
scenario
it's
like,
there's
there's
just
two
of
them,
one
with
three
args
and
one
with
four
args.
It's
like
well,
which
one
should
I
pick
the
one
with
four
args
doesn't
have
a
registered
service,
so
I
shouldn't
pick
that
one
right.
J
H
Yeah,
maybe
the
new
one
has
additional
services
attached
to
it.
That
you'd
want
to
pull
into
so
it
seems
like
you,
could
you
could
end
up
over
instantiating
things
that
you
may
not
need,
and
this
could
help
solve
that
it
seems
like
a
bit
of
an
maybe
a
rare
case,
but
it
seems
like
the
the
usage
of
this
is
kind
of
for
a
rare
case.
E
I
mean,
I
honestly,
don't
fully
understand
it,
but
smart
people
on
the
call
do
so.
I
just
I'm
struggling
to
understand.
There
are
three
possible
answers.
Right
there's
this
is
not
supported.
This
is
definitely
supported
and
we're
not
sure-
and
this
api
can
tell
you
two
of
the
three
but
you
you
could
absolutely
like.
So
let's
you
know
that
situation
we
discussed
where
there
were
two
possible
things
you
might
want
to
use
right.
B
So
related
to
this,
may
I
ask
in
so
basically
the
true
false
thing
here:
if
it's
registered,
then
it
would
return
true,
regardless
of
even
if
it
will
be
able
to
be
resolved.
Is
that
or
is
this
a
so
if
I
have
a
bunch
of
like
if
I
have
a
b
and
c
registered
in
the
container,
but
not
necessarily
all
of
their
dependencies
are
so
if
I
were
to
resolve
it
today,
it
would
throw
and
say
this
is
not
properly
registered
in
this
case
right
yeah.
This
will
be
returning
false.
K
D
Oh
yeah,
so
I
mean
that
is
the
old
conversation,
so
the
problem
is
with
that
is
there
are
things
that
aren't
explicitly
registered
that
you
could
resolve,
so
we
were
talking
about
like
is
resolvable
and
stuff,
but
yeah
we
landed
on
his
service.
D
Like
the
point
you
make
is
interesting,
and
that
was
even
worse
when,
like
this
api
was
called
like
can
get
service
because
there
you
really
would
think
that,
like
it
shouldn't
throw
if
it
returns
true
is
registered
is
interesting,
but
again
I
think
it
muddies
the
water,
because
you
can
resolve
some
things
that
you
might
not
have
registered
or
might
not
have
feel
you
registered
like
the
container
just
provides
it
or
whatever.
B
You
mean
like,
like
breaks.
D
D
E
Can
you
can
you
give
me
a
stephen
stephan?
Can
you
like
just
put
my
mind
to
these?
Give
me
a
concrete
example
where
the,
where
this
helps
in
some
meaningful
way
over,
what's
currently
there
so
right
now,
you
would
query
you
when
you
to
do
the
check.
You
would
actually
instantiate
the
thing
here.
You
would
access
the
boolean
and
it
returns.
True
is
the
savings
that
you're
just
avoiding
you're
you're,
delaying
the
I
o
is
it
that
you're
worried
about
the.
D
E
This
is
not
intended
and
should
not
be
used
in
a
situation
where
you're
trying
to
decide
which
way
to
go
a
or
b.
This
should
only
be
used
in
a
situation
where
you
only
want
to
know.
Can
I
use
a
or
not
it's
a
light
up
feature,
and
you
just
want
to
avoid
having
to
do
that
initial
query
earlier
on,
but
there's
always
a
possible
fallback
later.
Is
that
a
correct
summary.
D
I'm
not
sure,
so
let
me
try
to
rephrase
what
I
understand
it
stood
back
to
you,
okay,
so
in
so,
I
honestly
wonder
if
eric
isn't
right
and
the
activator
utilities
example
isn't
better
than
like
the
mvc
action
scenario.
But
since
I've
been
talking
about
that,
a
lot
right
now
like
with
what
we're
doing
we're
assuming
any
interface,
is
a
service
so
like
the
idea
that
it
could
fail
at
like
request.
D
A
The
you're
saying
the
default
provider
will
return
true
for
if
someone
asks
what's
the
thing
that
should
never
really
exist,
I
had
one
I
custom.
Formatter
right
get
service
is
service.
I
custom
formatter,
it's
gonna,
say
true,
because
it's
an
interface
and
it's
not
to
look
and
see
that
no
one
has
actually
bound
a
type
against
that
interface
for
di.
So
that's
the
terrible
behavior.
D
D
A
A
A
D
D
A
A
D
Answer
whether
or
not
like
the
container
will
will
try
to
give
you
that
service
right
and
that's
important,
because
if
you
try
to
get
a
service
that
the
container
thinks
you
can
get
and
then
it
throws
like
that's
misconfiguration,
usually
like
always,
I
don't
know
so
like
yeah.
I
just
I
don't
see
it
being
a
problem
like
yes,
if
it
says
it's
a
service
and
it
throws
it
should
throw
you
want
to
see
that
exception.
You
just
don't
want
to
like.
Do
it
greedily,
so,
basically,.
K
It's
the
two-layer
check
like
first,
you
have
a
lightweight
check,
checked
for
each
service,
and
then
you
decided
okay,
you're
proceeding
to
get
service,
and
basically
I
think
you.
You
believe
that
if
you
checking
for
his
service
first
and
it
returns
true,
then
it's
very
big
likability
or
probability
that
I
get
serious
will
return
something
meaningful
and
if
you
think
the
return
is
usually
some
misconfiguration
or
user
error.
Even
the
accessibility
is
right.
K
E
K
E
To
these
as
usage,
so
we
often
refer
to
these
as
usage
errors
versus
non
it's
like.
If
this
is
a
usage
error,
you
return
true,
but
then
it
fails
to
work,
and
you
know
you-
you
discover
this
development
time
because
you're
being
silly
in
your
your
development,
fine,
that's
like
passing
the
incorrect
value
to
an
ex
to
an
art
to
a
function
and
then
having
to
fix
your
code.
If
it's
you
deploy
this
to
production,
it
returns
true,
but
something
transient
in
your
environment
network
goes
down.
K
E
I
do
let
me
just
finish
my
thought,
and
so,
if
I,
if
I
change
today,
I
try
and
get
a
and
if
it
either
returns
null
or
throws.
I
do
b
tomorrow
with
this
api,
and
I
rewrite
my
logic
at
startup
to
change
my
behavior
such
that
I
query
is
a
available
else
use
b
and
then
in
my
actual
implementation,
I
just
whichever
thing
I
know
I'm
supposed
to
use.
I
just
always
use
a
or
I
always
use
b.
I've
now
changed
my
fallback
behavior
in
those
transient
error
cases.
That's
my
primary
concern.
E
C
Was
was
actually
useful
right
if
you
think
about
file
stream,
you
know
we
say
can
can
write
is
true,
but
then,
when
you
write
four
gigabytes
and
you
only
have
one
gigabyte
left,
it
will
still
fail
right,
so
it
just
basically
the
partial
definition
only
allows
you
to
reason
about
one
side
of
it
that
you
know
for
sure
won't
happen
right.
It's
not
that
the
thing
will
throw,
because
the
underlying
stream
fundamentally
can't
be
written
to
that
doesn't
mean
that
it
will
guarantee
it
to
work
right.
B
E
C
D
D
E
D
Right,
okay,
cool.
I
actually
agree
about
the
I
support
service,
query
being
weird,
if
you
tool
it
out
the
container
so
before
we
like,
assuming
that
we're
getting
closer
to
approving
this,
do
we
want
to
change
it
to
like?
I
query
services?
I
don't
know.
K
But
maybe
something
like
more
phasing
on
the
registration
of
the
presence
of
the
registered
service
in
the
service
collection,
something
like
is
in
service
collection
or
I
don't
know
I
was
at
dpc
yeah.
D
B
K
Yeah
yeah
yeah.
I
know
I
know
that
some
registration
are
implicit
or
provided
by
other
sources.
Like
example
the
containers,
but
just
justifies
that
it
is
something
like
present
or
not
present,
in
a
collection
of
services
and
indirectly,
but
we
do
not
have
anything
like
we
do
not
have
word
registry
here
so
maybe
invent
something
similar
to.
K
D
K
D
A
D
A
I
mean
so,
I
know
nothing
about
the
di
system
so
start
with.
That
is
there
something
that
you
use
in
the
same
hold
on?
I
got
to
get
a
cursor
on
the
right
screen
up
is
right,
which
is
weird,
so
is
there
something
that
you
would
use
in
the
same
spot?
That
is
a
asking
capability
about
your
provider
itself
already.
D
The
service
scope
factory
does
right
because
the
containers
need
to
provide
a
way
that
isn't
I
service
provider
right,
because
that
just
gives
you
git
service.
That's
the
entire
interface
to
create
scopes
right
for,
like
you
know,
asp.net,
requests
and
other
things
so,
and
that
controls
the
lifetime
of
your
scope,
services
and
transients
for
that
matter.
So
this
is
similar
right,
like
the
container
is
giving
you
kind
of
extra
functionality
on
top
of
what
I
service
provider
gives
you,
so
is
you
know
the
required
service
thing
too?
I'm
not
claiming
it's.
D
The
only
thing,
that's
like
that,
but
this
pattern
is
more
flexible
and
if
you
read
some
of
the
comments,
it
allows
the
core
container
to
not
take
a
dependency
on
our
dependency
rdi
like
abstraction
class
right
and
not
everyone
wants
to
in
their
core
like
container
class.
Sometimes
that's
like
a
a
package.
That's
you
know
additional.
B
D
Like
not
use
their
actual
container
as
an
I-service
provider
and
they
have
to
put
their
like
iservice
provider
in
this
like
third
package,
so
I
mean
yeah.
G
C
Yeah
that
was
kind
of
my
question
like
because,
if
the
thing
is
implemented
versus
resolved,
I
think
that
might
be
a
rough
differentiation
similar
to
eye
service
go
effect,
I
mean
you
could
call
this
literally.
You
know
I
is
service
provider
right
like
as
boring
as
it
gets,
because
it
just
provides
you
this
one
method
right
but
yeah.
I
think
it's
a
that
might
be
a
worthwhile
distinction,
just
things
that
the
provider
implements
versus
things
that
get
resolved
through
the
eye
right
or
as
a
service.
I
guess,
is
there.
I.
C
A
Like
yeah,
so
personally,
I
think
the
name
is
fine
for
di
how
how's
that
oh
come
on
no
like
this
is.
This
is
not
a
line
of
code
that
I
would
ever
architect
in
my
life.
A
Well,
it
says
the
guy
that
works
from
crypto
right,
but,
like
the
the
the
notion
like
I,
if
this
was
from
scratch,
you
know,
then
this
would
really
not
be
a
get
service,
it
would
be
a
good
capability,
and
now
you
would
be
describing
a
capabilities
thing,
even
if
you
wanted
it
to
be
thing
like
it
would
be
a
different
universe
than
like,
because
this
is
weird
it's
just
using
a
hook
for
this
is
the
only
way
we
have
of
asking
you
a
question:
it's
basically
an
abusive
of
the
function
and
fine,
but
like
once
we're
doing
that
now
kind
of
nothing
matters
and
it's
just
whatever
it's
called.
A
It's
called.
This
is
the
line
of
code
people
write
and
I
don't
think
anyone
cares
yeah
I
mean
I
wouldn't
go
quite
that
far.
I
think
that
di
is
kind
of,
but
having
a
having
a
pattern,
for
you
know,
interfaces
whose
names
kind
of
look
like
blank
are
expected
to
be
that
the
service
provider
is
using
that
as
a
question
about
itself,
and
no
one
should
really
register
them.
A
It's
supposed
to
be
a
self-descriptive
thing,
then,
like
fine
come
up
with
that
naming
proposal,
but
I
don't
think
that
you
know
the
majority
of
the
people
in
this
meeting
use
di
and
therefore
have
opinions.
But
that's
that's
really,
my
only
like.
That's
why
it's!
The
is
I
support
right
and
you
said,
is
service
scope.
Factory
is
the
right
model,
but
that
doesn't
have
a
name
that
we
can
work
off
of
unless
we
say
it's,
I
service
something
something
which
is
why
I
move
support
to
the
end,
but.
C
D
D
I
A
A
I
C
I
think
my
buddy
rt
started
the
the
root
interface
was
called,
I
known,
and
then
they
said
they
can't
do
that.
That
would
be
too
much
on
the
nose
but
yeah.
I
think
the
idea
is
like
if
you,
if
I
mean
if
you
actually
go
down
that
pattern,
it
would
be
worthwhile
to
think
about
a
pattern
for
this
particular
case
that
you
have.
You
may
want
to
add
one
method
that
is
resolved
by
idi
right.
A
D
D
D
A
A
D
Correctly,
I
picked
that
up
for
max
one
of
my
first
suggestions
was
I
query
services
or
something
like
that.
C
G
I
mean
you
could
just
do
I
service
query
provider
or
something
like
that
and
call
it
a
day
because
it's
it's
it's
a
provider
of
the
query
support
I
think
below
some
folks
actually
did
suggest
that
the
iservice
provider
should
just
implement
the
thing
and
jury
was
sort
of
out
on
that.
I
don't
feel
terribly
strongly
about
it,
but
it
does
seem
odd
to
have
some
of
it
implemented,
like
I
support
required
services
on
the
service
provider,
but
then
this
new
thing
not
on
the
service
provider.
That
seems
kind
of
weird
to
me.
Yeah.
D
Yeah,
like
eric's
in
the
chat-
and
I
think
he
was
one
of
the
first
to
suggest
that
and
like
again
I'll
push
back
in
that.
Yes,
that's
a
pattern,
but
the
older
pattern.
The
more
flexible
pattern
is
the
eye
service
scope
pattern
factory
so
like
there
are
two.
We
definitely
shouldn't
introduce
a
third
one,
but
I
prefer
resolving
it
out
of
the
service
provider.
I
mean.
C
C
It
depends
on
on
the
scenario
whether
they
are
casted
or
whether
they
are
actually
just
resolved
by
a
di
right,
and
it
might
even
differ
based
on
bi
systems.
Right
I
mean
you
could
argue
that
this
is
plumbing
and
people
shouldn't
use
it.
They
should
call
this,
you
know,
have
service
type
of
t
or
has
service
type
extension
method
instead,
and
that
thing
does
the
right
thing
right
like
that
you
can.
C
C
That's
also
fine,
I
mean
my
concern
is
more
along
the
lines
of
you
have
two
different.
They
basically
have
one
naming
convention
that
has
two
different
usage
patterns.
If
you
I
mean
one
option
is
to
have
a
different
naming
convention
or
just
unify
the
usage
pattern,
and
so
you
could
just
unify
the
usage
better.
D
Oh,
you
can't
really
unify
the
usage
pattern.
This
case,
like
there's
the
usage
patterns,
are
what
they
are.
It's
not
worth
breaking
for
the
two
existing
things
well,.
A
D
I
get
it
like
you,
you
ask,
ask
the
I
service
provider,
it's
just
less
flexible
and
I
don't
think
that,
like
I
think
we
should
come
up
with
a
better
name
than
just
like
switch
the
pattern,
because
the
name
we
first
came
up
with
is
more
similar
to
the
other
pattern.
C
D
The
weird
thing
is
that
sounds
a
lot
like
a
marker
interface.
Like
you
know,
I
am
a
service.
Another
thing
I
noticed
is
you
were
calling
this
haz
service
instead
of
is
service,
which
I
honestly
don't
mind.
That
is
a
method
name
either.
I
don't
know,
is
hash
service
better
than
his
service.
C
D
I
think
I
prefer
is,
I
would
just
bring
it
up
right,
especially
with
the
you're
resolving
another
thing
out
of
the
service
brighter
thing.
B
B
Also
in
the
usage
examples
there's
no,
so
I
was
wondering
if
there's
any
usage
sample,
that
shows
what
the
developer
needs
to
do
to
make
sure
the
iso
support
service
query
is
registered,
so
it's
going
to
be
on
the
developer
to
do
that,
or
is
it
going
to
be
built
in
in
our
own
di
container?
We
so
like
every
time
we
like
set
up
di
then
we
expect
this
not
to
be
null.
D
Like
service
scope
factory,
in
that
it
will
be
implemented
by
the
container
because
it
wasn't
in
1-0,
the
consumers
of
the
code
cannot
just
expect
it
to
be
there
right
because
it
hasn't
been
in
like
the
conformance
test
since,
like
the
beginning
of
like
project
k,
like
our
container
will
have
it
and
you
know
we're
involving
the
bi
council,
we're
hoping
the
other
containers.
Add
it
quickly.
You
could
add
a
polyfill
if
you
really
wanted
to.
D
You
can
also
use
attributes
right
for
your,
like
action
parameters
and
stuff
potentially,
but
like
the
common
users
of
this,
would
be
like
the
asp.net
framework,
perhaps
activator
utilities.
It
is
fair
to
say
that
I
don't
expect
many
like
web
applications
or
console
applications
to
be
calling
this
directly.
This
is
more
of
a
framework
level
concern.
B
A
A
G
G
Or
returns
true,
knowing
the
container
doesn't
know
about
it
like
I
could
see
so,
at
least
at
the
artifact
level.
We
have
a
lot
of
folks
who
want
to
unit
test
the
dependency
injection
itself
and
they
try
to
mock
the
container
and
they
try
to
mock
like
way
too
much
stuff
and-
and
I
can
see
folks
going-
oh
I'm
going
to
unit
test
this
thing
and
mock
my.
I
support
service,
query
and
everything
unit
tests
out
great,
except
in
real
life,
in
whatever
edge
case
they
run
into
it,
doesn't
and
they're
wondering
you
know.
G
Then
it's
a
support
issue
where
I
have
to
explain
hey.
You
know
you
registered
an
override,
for
I
support
service,
query
that
isn't
actually
the
one
that
matches
what's
actually
in
the
container,
I'm
wondering
if
the.
If
that's
like
a
foot
gun
waiting
to
happen
for
folks.
You
know
in
inadvertently
seeing
this
not
really
understanding
and
then
stumbling
into
a
problem.
C
C
Just
you
just
say:
you're
holding
it
wrong,
I
mean
like
that's
generally.
The
problem
with
many
features
is
just
because
something
can
be
abused,
doesn't
necessarily
mean
that
we
don't
do
it
it's
more.
For
me,
the
question
of
like
how
likely
is
it
like,
if
you
think,
there's
some
hardcore
people
that
will
do
that
and
they
hang
themselves.
I
think
that's
fine,
if
you
think
it's
very
common,
because
it's
basically
you
lead
pogba
down
the
wrong
path
with
the
naming
or
the
shape
of
a
of
an
api.
D
D
Not
going
to
put
that
scenario
in
the
conformance
test,
so
it's
like
artifact,
you
could
choose
just
to
ignore
registration
to
this.
I'm
not
saying
you
should,
but
I'm
just
saying
like
you,
wouldn't
be
non-compliant
if
you
decided
that
was
going
to
be
too
much
of
a
problem
to
support.
G
Sure
I
I'm
just
I'm
just
trying
to
think
like
you
know
when
when
there's
like,
you
know,
10
20
30
questions
about
that
for
a
larger
team
to
answer.
That's
not
as
big
of
a
deal
as
when
there's
like
you
know,
two
guys
trying
to
handle
auto
fat
questions
and
it's
the
same
question
over
and
over.
So
I'm
I'm
trying
to
balance
the
pit
of
success
with.
Maybe
the
better
pattern
is
all
so.
I.
G
D
C
A
Yeah,
which
honestly
is
a
like-
I
had
that
thought
earlier
and
I
wasn't
going
to
express
it,
but
someone
did
I
had
the
same.
It's
weird
that
it's
a
good
service,
because
someone
could
register
it
or
you're
going
to
block
the
registration
of
it
or
ignore
it
when
this
is
really
asking
about
the
provider
itself.
So,
as
is
really
the
the
c-sharp
natural
usage
of
this
like
that
is
like
it's
named
the
right
thing,
you're
just
using
it
wrong.
D
So
it
breaks
the
polyfill
for
containers.
You
might
be
late
to
adopt
this.
It
removes
yeah.
So
so
that's
one
thing.
I
honestly
don't
think
it's
that
useless
we're
not
to
provide
like
a
default
implementation
of
I
support
service
query,
but
I
could
see
it
being
handy.
How
could
you
polyfill
this?
D
There
are
a
couple
ways
if
you
don't
care
about
the
side
effects
you
could
just
like
try
to
resolve
it
right
like
for
your
particular
application
and
check
if
it's
null-
and
you
know
catch
exceptions
like
not,
everyone
does
care
about
the
side
effects,
but
that
would
be
an
application
decision.
You
can
also
just
do
something
based
on
the
service,
collection
and
you'd
have
to
have
some
smarts
around
open
generics
and
how
innervals
are
handled
and
we're
not
going
to
write
that,
but
it's
theoretically
possible.
C
D
C
D
C
No,
I'm
not
trying
to
make
a
statement.
I
was
just
asking
like
basically
are
you
saying
that
so
there
will
be
an
implementation
but
like
basically,
what
I'd
understand
is
to
pull
you
through?
Like
is
basically
the
question
is
I
use
let's
say
artifact
from
yesterday
that
doesn't
have
support
files
so
about
service
query,
with.net
six
and
then
I
provide
an
implementation
for
artifact
by
registering
this
interface
myself.
Is
that
what
you
mean
by
polyfill.
D
Right
because,
right
now,
if
you
use
an
old
version
of
auto
pack
right-
and
I
assume
like
auto
pack-
will
probably
have
this
pretty
quickly-
you
guys
are
pretty
usually
pretty
responsive.
So
that's
great,
but
let's
say
that,
like
you
know
it
wasn't
there
for
whatever
reason
someone's
trying
to
use
the
previews
they
would
have
to
put
like
from
service.
You
know
post
this
change
on,
like
all
their
service
attributes,
which
is
fine,
that's
actually
probably
the
better
workaround
than
the
polyfill
but
like.
D
If
someone
wants
to
do
a
polyfill
and
says,
like
you
know
what
I
know
which
services
I
want
to
infer
coming
in
to
my
actions,
then
I
I
don't
really
see
the
problem
like.
It
could
literally
be
a
switch
statement
right
like
again
like
use
at
your
own
risk,
we're
not
going
to
ship
it,
but,
like
these
things
are
pretty
static.
C
A
A
C
D
If
it
starts
with
that
no
difference
in
service
scope,
factory
and
like
ours
won't
implement
it.
So
I
mean
yeah,
it's
just
it's
not
a
different
problem
and
it
does
give
you
that
flexibility.
C
C
I
think
the
one
thing
that
we
can't
seem
to
you
know
conclude
is
basically
the
name
of
the
the
interface,
but
I
also
don't
think
it's
necessarily
useful
to
do
this
with
30
people
on
a
call,
so
maybe
just
go
back,
try
to
come
up
with
a
name
that
you
like
more
than
what
we
have
right
now
and
then
we
can
just
wave
it
through
because
I
think,
like
nobody
really
pushes
back
on
the
scenario
at
this
point,
it's
just
that
we
don't
like
the
name.
I
think
that's
the
predominant.
D
Accepted
like
many
of
the
alternatives,
because
I
do
agree
like
that,
starting
with
I
support
is
whatever
and
then
we
can
take
it
and
get
it
like
tentatively
approved
and
if
we
change
it
again,
we'll
just
take
it
back
to
api.
Just
for
the
name.
C
C
Kind
of
in
chat
is
kind
of
you,
you
suffix,
I
service
provider.
I'm
not
sure
I
like
the
the
actual
suggestion
here.
If
I
service
provider
contains
service
and
then
a
method
is
contained
service,
but
you
could
have,
I
service
provider
is
service
and
that
has
a
service
method
on
it
right.
That's
one
pattern,
the
other
pattern
that
I
think
I
suggested
was
just
method
name
plus
and
I
in
front
of
it.
C
So
I
is
service
I
think
eric
suggested
I
serve
as
query
provider,
but
I
think
you
don't
like
period
so
I
think
we
have.
D
G
I'll
probably
comment
this
just
just
something
to
keep
in
the
back
your
mind,
I
recall
that
the
usage
was
mentioned,
that
you
can
query
it
and
then,
like
maybe
cache
the
result
or
something
be
careful
with
over
eager
querying,
simply
because
on
at
least
in
auto
fact,
you
can
add
new
registrations
on
creation
of
a
lifetime
scope.
So
the
answer
may
change
based
on
whether
you're
in
a
request
versus
it
application
start
time
sorts
of
things
so
don't
go
too
crazy.
Caching.
G
Well,
no,
no,
I
I'm
saying
like
if
you
were
trying
to
resolve
middleware
dependencies
to
pass
into
invoke
or
whatever
the
ability
to
resolve
those
things
may
change
based
on
somebody
adding
or
changing
registrations.
G
Put
it
in
the
there
or
whatever,
but
naming
good
usage
pattern.
Good
I'll,
see
you
guys
on
the
on
the
issue
here.
A
A
All
right,
the
second
promised
thing
is
nullability
from
reflection,
and
so
I
will
introduce
the
issue
and
then
you
guys
will
get
to
look
at
an
empty
chair
for
a
minute.
While
I
run
the
restroom
all
right
top
level,
nullability
information,
exposing
it
from
reflection,
two
niner,
seven,
two
three:
where
should
I
scroll
to
before
I
disappear
for
a
minute.
A
C
I
can
see
the
base
for
the
gavel
all
right,
yeah
that
works
a
scroll
kind
of
down,
I
think,
to
the
actual
api
proposal,
because
I
think
we
so
we
talked
about
this
before
so.
The
basic
idea
is,
we
want
to
be
able
to
surface
nullability
annotations
through
reflection
and
the
the
general
scenarios.
C
Are
anybody
who
basically
tried
to
reasons
about
the
type
system
to
do
something
interesting
one
example
is
ef
where
you
basically
create
tables
out
of
you
know
net
type,
so
you
have
a
customer
type
and
you
may
make
middle
name
nullable,
and
then
you
would
expect
when
the
table
is
created,
that
the
middle
name
column
is
basically
also
marked
as
nullable
right
and
today
you
would
have
to
use
custom
attributes
for
that,
because
we
don't
really
have
a
way
to
do
that,
but
it
seems
you
know,
given
that
c
sharp
has
the
ability
to
entertain
nulls
that
you
would-
and
you
know,
expect
ef
to
honor.
C
That
indicated
in
the
underlying
database
and
same
thing
happens
to
like
civilization.
You
could
imagine
if
things
are
marked
as
non-nullable
that
you
know
you
know,
civilizations
might
reject
types
that
you
know
we're.
Not
all
properties
are
initialized
from
the
payload,
for
example,
or
you
might
expect
you
know,
have
something
like
you
know:
model
binders
where
if
things
are
not
initialized,
you
know
instead
of
rejecting
the
whole
thing.
C
You
just
mark
the
the
resulting
model,
as
is
invalid,
and
then
you
know
maybe
there's
detailed
errors
in
the
model
binder
that
you
can
ask
and
say
yep,
you
know,
first
name
was
supposed
to
be
non-null
or
something,
and
so
the
question
is.
How
would
you
do
that?
Because
if
you
want
to
read
custom
like
if
you
want
to
read
another
annotations
today,
that's
fairly
involved
because
they're
not
just
simple
custom
attributes,
they
are
kind
of
you
know
specially
encoded
to
keep
the
metadata
somewhat
compact.
C
The
compiler
has
written
a
very
lengthy
specs,
so
it
is,
you
know
something
you
can
definitely
do
it's
just
not
trivial
to
do
that,
and
so
what
this
basically
represents
is
a
reflection
based
approach
where
we
just
effectively
expose
an
api
where
you
can
ask
that
the
reason
we
have
this
on
a
different
type
called
modability
info
context
is
because
we
want
to
do
some
caching
and
we
want
to
be
able
to
say
the
user
creates
the
duration
or
the
lifetime
of
that
cache.
C
C
The
actual
availability
info
that
you
get
back
looks
very
similar
to
an
instance
of
type,
so
it
mirrors,
basically
the
properties,
type
element
type
and
generic
type
arguments
from
type.
So,
if
you
think
about
how
a
signature
works,
let's
say
you
have
a
method,
for
example,
that
returns
an
innumerable
of
string.
You
know
the
the
instance
of
system
type.
Will
have
generic
type
arguments
because
it's
an
instance
of
innumerable,
and
so
when
you
ask
for
the
generic
type
arguments
there
you
get
back.
C
You
know
the
the
string
instance
and
the
same
recursion
is
basically
expressed
here,
except
that
you
don't
use
types
you
basically
recurse
over
itself
right,
so
the
element
type
is
now
another
availability
info
that
tells
you
what
that
is
to
make
it
a
bit
more
convenient.
We
basically
don't
expect
users
to
walk
the
type
and
notability
info
at
the
same
time,
which
is
why
we
expose
the
underlying
system
type
directly
on
the
notability
info
itself.
So
you
can
see
that
you
know
you
have
an
innumerable.
C
You
know
that
will
be
the
type
and
then
the
the
read
state
might
be.
You
know
you,
you
know
another
null
or
not
null
depending
on
what
the
annotations
are,
and
so
the
actual
enum
just
reflects
the
three
states
that
c
sharp
has
like
things
that
are
that
are
not
annotated,
are
considered
unknown.
And
then,
if
you
don't
put
a
question
mark,
then
it's
not
null.
C
If
you
put
a
question
mark,
then
it's
maybe
now
so
we
can
talk
about
the
naming
here,
because
the
unfortunate
thing
is
that
the
way
the
compiler
api
is
exposed
is
not
very
friendly.
I
think
they
have
annotated,
not
annotated
and.
C
I
forgot
some
some
other
states,
so
it's
like
the
naming
convention
that
they
have
in
the
compiler
apis
doesn't
really
flow
or
gel
with
how
we
publicly
talk
about
nullability
information.
So
that's
why
we
ended
up
with
the
ones
that
we
have
on
on
on
screen
here,
but
booyah
suggested
instead
of
using.
Maybe
now
we
should
just
use
not
null.
I'm
sorry
a
null
or
it
can
be
like
is
null
or
whatever,
but
I
think
the
the
idea
of
oh
I'm
sorry
nullable
yeah.
C
That
was
the
suggestion
right
yeah,
which
I
think
is
also
fine.
I
think
for
the
for
the
user.
I
know
not.
Another
ball
makes
sense.
I
don't
have
strong
opinions
on
that
one.
C
C
Basically
that
describes
the
return
itself,
and
so
you
would
basically
pass
that
in.
If
you
want
to
know
the
return
type
of
a
method
that
might
not
be
super
discoverable,
so
c
suggested,
maybe
you
should
have
a
create
method.
It
just
takes
a
method
info
and
it
gives
you
back
not
a
method
info,
probably
a
method
base,
so
you
can
do
it.
I
guess
for
constructors
it
doesn't
really
make
sense,
but
you
know
you
would
basically
be
able
to
get
it
from
there.
C
The
only
concern
that
I
have
of
doing
that
is
that
we
split
the
nullability
information
in
read
state
and
write
state.
So
the
there
was
a
suggestion
from
last
time,
because
we
have
custom
attributes
that
you
can
put
on
parameters.
For
example,
where
you
know
you
can
you
know
one
direction
is
not
labeled,
but
the
other
one
is
not,
for
example,
or
properties
where
the
setter
is
nullable,
but
the
getter
isn't,
and
so
that's
why
we
basically
split
it
into
reset
and
write
state.
C
So
you
could
imagine
if
you
ask
for
a
method
that
people
might
expect
that
the
read
state
is
the
return
value
and
the
right
state
is
the
one.
You
know
argument
you
can
pass
the
method,
but
I
think
it
would
be
fine
to
also
have
a
method
dedicated
for
method
info
and,
I
think
yeah.
You
think
the
only
other
question
that
came
up
last
time.
If
you
scroll
down
jeremy
like
there,
was
the
question
of
like
which
custom
attributes
are
we
actually
looking
at,
and
so
I
went
over
all
of
them.
C
So
if
you
scroll
down
further
further
further
yeah
here,
we
go
so
basically
we
have
a
bunch
of
them,
so
some
of
them
are
related
to
flow
analysis,
so
it
does
not
return,
does
not
return.
If
maybe
now,
when
remember
not
now
remember
now,
when
not
now,
if
not
no
not
now,
when
they
don't
really
make
sense
to
ask
statically
for
an
api,
they
only
really
make
sense
to
ask
like,
in
the
context
of
a
particular
flow
graph
right.
Just
like
you
know
what
you
know.
C
C
You
know,
you
know,
with
the
one
direction
can
differ
from
the
other
direction,
so
those
we
will
actually
process
and
we
will
combine
it
with
the
actual
question
mark
annotations
on
the
type
itself,
and
so
we
you
can
totally
have
you
know
properties
where
you
know
the
setter
is
not
able,
but
the
getter
isn't,
for
example,
and
then
you
know
we
would
reflect
that
by
the
read
state
and
write
state
properties.
A
A
C
So
my
understanding
from
the
way
I
like
it's
basically
what
mirror
of
what
c
sharp
thinks
in
the
context
of
a
generic
right
like
if
you're
inside
the
generic
method
like
what?
What
does
c
sharp
think
the
the
the
t
is
right
and
the
answer
might
be.
It
doesn't
think
anything
because
it's
you
can't
express
it,
but
I
don't
actually
recall
what
c
sharp
does
in
that
case,
stephen
might
know
more,
but
I
would,
I
would
basically
say
we
would
we
would
mirror,
but
with
the
static
type
system
in
c-sharp,.
C
A
I
mean
I
was
asking
what
the
api
is
going
to
do.
The
nemo
had
an
assertion
that
I
don't
know
how
to
follow
up
on,
but
my
like
really
it's
the
I'm
just
wondering
like
for
so
yeah
it's
for
any
specific
method
that
would
be
callable.
A
You
can
look
at
things
and
you
can
answer
authoritatively
for
the
decorated
state,
not
the
data
flow
state,
but
any
open
generic
once
it
is
looking
at
the
like.
Well,
it
depends
on
if
t
is
a
reference
type
or
not,
this
api
is
going
to
give
a
definitive
answer.
Unless
yeah,
I
guess
it
could
return
unknown,
but.
E
If
you,
if
you
want
to
do
what
c
sharp
does
it's,
if
you
have
t
question
mark,
it
assumes
it
might
be
a
reference
type
in
terms
of
the
things
that
it
warns
you
about.
So
if
you
have
a
parameter,
that's
t
question
mark
and
inside
your
method
you
try
and
de-reference
it
without
asserting
it's
not
null
or
without
doing
a
null
check.
E
You'll
get
a
this
may
be
null
warning
because
that's
true,
it
may
be
null
right,
and
so
I
presumably
you
know
if
you
have
an
open
generic,
it's
it's
returning
a
t,
question
mark.
If
you
ask
it,
what
is
the
state
of
this?
Presumably
it's
going
to
be.
Maybe
no.
A
E
E
A
Fair
and
then
I'll,
just
I'll
I'll,
ask
the
question
just
for
the
sake
of
asking
it
for
the
things
that
we
know
at
the
bottom.
Would
it
be
worth
having
a
different
answer
that
just
says
you
know
flow
dependent,
there's
a
state
here,
it's
complicated.
We
can't
explain
it.
C
B
C
Basically,
you
like
the
like
the
first
four
are
still
sufficiently
describing
the
static
information
right.
You
just
may
know
additional
things
on
top
like,
for
example,
does
not
return.
If
this
thing
is
false,
for
example,
or
sorry,
it
does
not
return.
If
this
thing
is
null
or
something.
That
is
something
that
you
know
you
can
now
use
in
flow
analysis,
but
it
doesn't
really
change
your
static
answer
for
this
method.
It
just
means
sure
you.
B
C
A
E
The
one
problem
with
it
are
things
like
the
maybe
know
when,
because
if
you
have
for,
if
you
have
a
parameter,
that's
out
out
string
s
right.
If
you
ignore
these
custom
attributes
you're
going
to
say,
this
will
always
return
not
null.
But
if
it's
attributed
as
maybe
null
when
false,
then
it
actually
can
be
null.
C
E
Cannot
be
not
nulls
will
not
know
if
not
know
and
not
know
when
go
from.
Allow
you
to
turn
something
that
is
maybe
null
into
something
that
is
not
known
so.
E
E
I
mean
I'm
not
sure
that
really
matters
for
the
scenarios.
This
is
targeted
at
it's
all
about.
You
know,
you've
called
them
yeah,
that's
those
don't
matter
does
not
return.
I
don't
think
those
matter
either.
C
C
Yeah,
that's
I
kind
of
like
it
because
it
kind
of
matches
the
attributes
which
to
me
is
the
extent
to
which
we
expose
it
in
the
public
api
and
the
bcl
the
c-sharp
compiler
naming
is
just
I
don't
know,
not
exactly
approachable.
C
And
I
think
jan
kind
of
felt
strongly
the
generic
type
argument
should
just
be
an
array
yeah.
I
I
don't
have
super
strong
opinions.
I
mean
everything
in
reflection
is
kind
of
array
based,
but
it
does
violate
our
guidelines
and,
given
that
this
thing
is
allocated,
I
mean
quite
frankly,
this
thing
is
not
super
cheap
to
begin
with,
because
it
basically
has
to
crack
open
custom
attributes
and
stuff.
F
C
Yeah,
so
the
only
thing
is
like
the
reason
why
I
don't
care
here
is
because
the
nullability
info
is
not
something
you
get
off
of
reflection
right
you,
you
basically
call
the
method
and
it
instantiates
it
every
single
time.
You
ask
it
so
if
you
mutate
the
instance
afterwards.
Well,
you
meet
you.
You
mutated
the
instance
that
you
created
yourself
so
to
me
it's
kind
of
like
you
own
it.
C
So
if
you
stomp
on
it
it's
your
problem
like
I
don't
expect
people
to
actually
stash
away
these
vulnerability,
infos,
in
which
case
the
lifetime
is
limited.
To
you
ask
one
question:
you
get
an
answer
and
if
you
then
in
the
process
of
doing
so,
you
stomp
over
your
own
data.
Well,
that's
on
you.
I
don't
personally
care.
C
Yeah,
so
the
only
caching
that
we
currently
want
to
do
is
is
this.
You
know
there's
this.
I
forgot
it's
notable
context
that
the
compiler
basically
uses
to
compress
the
attributes,
and
we
want
to
cache
those
when
we,
when
we
look
up
things.
So
it's
basically
that
that's
the
it's
the
private
cache
that
isn't
another
ability
in
for
context
itself,
but
we
don't
cache
nullability
info
because
that's
too
expensive
and
doesn't
really
provide
much
benefit.
F
Okay,
there
was
a
related
open
question
about
an
unresolved
question
about
where
they
should
live
system,
reflection
or
system
diagnostics
code
analysis,
because
if
you
put
this
in
code
analysis,
you
don't
have
to
follow
the
existing
reflection
patterns.
C
Yeah,
I
think
jan's
argument
was
less
about
the
pattern.
It
was
more
like.
Well,
it's
cheaper.
So
why
would
you
go
buy
a
you
know,
a
wrapper
collection
that
is
yet
another
object
and
to
me
I
you
know,
as
I
said
like
it's
kind
of
like
when
you
call
create.
You
definitely
create
something
new.
So
it's
yours.
If
you
want
to
mutate,
it
be
my
guest.
So,
like
that's,
why
I
care.
F
C
All
right,
so
is
that
that
you
want
to
return
an
array.
Well,
I'm
kind
of
asking
the
room,
because
I
mean
I
I
can
go
either
way
like.
I
think
this
thing
is
going
to
be.
You
know
moderately
expensive,
so
whether
you
create
another
object
to
me
makes
not
a
huge
difference,
but
I
also
haven't
profiled
it
by
any
stretch.
Right
so
I
mean,
if
you
said
john
felt
strongly.
F
If
you
return
an
array,
make
it
non-nullable
and
just
return
a
rate
on
empty
or
something
in
the
case
where
it's
not
relevant,.
C
F
I
was
just
giving
feedback
yeah
so.
A
J
F
C
C
I
mean
in
fairness,
that's
why
we
exposed
the
type
right.
So
the
idea
would
be
that
if
you,
if
you
you
know,
you
can
basically
get
the
corresponding
side
by
just
you
know,
dotting
and
then
say
dot
type,
but
yeah
I
mean
that's.
The
general
idea
is
that
you
know
it
seems
like
there's
enough
cases
when
you
do
reflection-based
code,
where
you
have
the
index
of
the
generic
type
argument,
and
you
just
want
to
get
it
right.
I
think
the
I
don't
know
exactly
what
I
went
with
now.
C
C
We
should
just
paula
just
said
this
name
sucks,
not
sure
what
he
saw,
but
I
don't
think
he's
commenting
what
we're
doing
right
now,
so
I
think
the
yeah
we
should
just
do
whatever
reflection.
Does
I
think,
if
reflection
gives
you
an
empty
array,
we
should
do
an
empty
array.
If
perfection
gives
you
another,
we
should
probably
do
now.
Just
because
I
mean
you
use
both
of
them.
At
the
same
time,
most
likely.
C
K
K
C
C
F
C
Yeah
like
what
I
don't
like
about
that
is
now
you
have
a
you
know
this
weird
split
in
the
overloads
right
but
yeah.
That's
why
I
originally
didn't
have
it
because
the
other
ones,
it's
kind
of
clear
what
you're
asking
for
for
the
method.
It's
a
bit
odd,
but
I
guess
you
could
make
the
same
argument
about
the
property
info,
because
you
logically
have
a
getter
and
a
setter.
C
J
C
Cool
yeah-
if
people
have
are
happy
with
that,
then
you
can
approve
that.
F
So
just
as
as
a
concrete
example
say
that
I
give
you
say
that
I
give
you
list
of
t
dot,
add
the
the
parameter
being
the.
F
F
Well,
that's
one
of
the
cases
where
the
t
itself
is
the
annotation
and
there's
no
attribute
on
the
parameter
like
if
I
have
a
list
of
string
or
a
list
of
string
question
mark
from
the
runtimes
perspective.
These
are
the
exact
same
type.
The
compiler
is
the
thing
that
knows
the
difference
between
the
two.
C
I
mean
that's
the
kind
of
problem
right,
like
I
mean
open.
Generics
are
kind
of
weird,
like
people
don't
even
know
how
to
do
it
in
c
sharp
right,
because
in
t-shirt
we
don't
really
use
open
generics
right.
People
think
they
do,
but
it's
usually
they're
inside
the
generic
type
or
method
and
they
use
their
t
and
they
think
that's
an
open
generic.
But
that
case
it's
bounded
by
whatever
that
that
t's
annotation
happens
to
be.
F
Okay,
ignore
ignore
the
ignore
the
open
generic,
then
list
of
string,
question
mark,
get
method,
add
get
parameters,
sub
zero
and
then
I
pass
that
to
the
create
method.
What
do
I
get
back.
C
F
C
If
it's
list
of
string
and-
and
you
know
when
you
like,
you
know
when
you
compiled
your
code,
okay,
assuming
you
had
unlimited
annotations
on
then
that
that
that
concrete
generic
type
parameter
would
be
marked
as
a
you
know,
the
non-nullable
string,
so
it
should,
it
should
tell
you
it's
a
it's
a,
not
null
string
at
that
point.
C
C
C
F
F
K
F
To
create
the
oh
man,
the
get
generic
arguments,
yes,
is
going
to
return
a
t
that
has
an
annotation
that
says
maybe
null,
because
that
that
should
actually
be
an
annotation
on
the
generic.
But
if
I
look
at
the
type
property,
the
type
property
will
just
be
list
of
string,
not
list
of
string
question
mark
so
that
that
means
that
as
a
caller,
I
still
need
to
and
as
a
caller,
I
still
need
to
keep
track
of
all
of
these
different
hierarchies
myself.
C
Well,
that's
that's
why
I
repeat
the
type
of
availability
info
right
so
the
years,
if
you
care
about
download
notation,
you
should
be
able
to
just
walk
nullable
info.
So
basically,
just
with
that,
you
should
be
able
to
produce,
for
example,
the
string
that
has
either
question
marks,
or
you
know
exclamation
marks
or
whatever
you
want
to
use
to
annotate
it
right.
So
you
so
you
basically
can
construct
that
that
that
that
type
information
but
yeah
yeah
you're
right
the
instance
of
system
type
itself,
will
never
know
whether
it's
not
no.
F
I
guess
I
I
guess
the
thing
the
thing
that
I'm
driving
at
ultimately
is:
if
I
want
to
know,
if
it's
valid,
to
pass
null
into
the
add
method
of
some
list
of
string,
then
it's
not
sufficient
for
me
to
have
only
the
list
of
string
instance
that
I
care
about.
I
actually
need
to
go
back
to
what
api
originally
gave
me
this
list
of
string
and
follow
its
nullability
info
context.
All
the
way
back
there
correct.
C
A
F
There's
only
one
so
the
again,
the
reason
I
bring
this
up
is,
it
might
have.
It
might
have
interesting
impact
on
how
things
like
system
text
json
need
to
honor
these
if
they
do
want
to
to
honor
them
for
things
like
binding.
F
F
Well,
maybe
because
if
I,
if
I
have,
I
know
the
way
that
system
text
json
works
now
and
steve,
please
like
correct
me
if
I'm
saying
something
incorrect,
but
I
I
know
that
you
have
you
have
converters
for
things
like
list
of
t
if
I
have
a
a
model
object,
so
public
class
foo
that
has
a
property
that
returns
a
list
of
string
and
another
property
that
returns
a
list
of
string,
question
mark.
Presumably
those
two
things
are
actually
going
to
have
to
filter
down
to
different
converters.
J
Today,
the
converters
I
understand
themselves,
if
their
value
type
or
reference
type,
and
they
they
don't,
they
don't
know
what
property
they're
bound
to.
For
example,
they
only
know
about
the
type.
C
What
way
you
want
to
handle
it
right,
I
guess
for
collections,
you
kind
of
want
to
do
it
on
the
type.
I
guess
that's
true,
but
for
I
think
regularly
I
mean
I
would
think
you
if
you
want
to
enforce
it
in
system
text.json.
I
think
you
would
do
it
for
the
cases
where
you
call
a
constructor,
set
a
property
or
set
a
field
right.
C
J
J
C
C
J
C
I
mean
well
in
c
sharp,
like
nullable
context,
is
just
an
implementation
detail
of
the
way
they
compress
the
metadata
right,
like
logically
in
c
sharp.
It's
just
you
either
annotated
an
api
with
another
annotation
or
you
didn't
right,
and
so
you
either
said.
I
don't
know
whether
this
reference
type
is
null
or
not.
C
Now
or
you
said
well,
I
do
know,
and
it's
either
not
or
not,
no
right,
and
so
that's,
basically,
the
three
states
that
a
given
reference
type
can
have
and
then
the
the
the
nullable
context
that
your
sharp
is
using
is
just
basically
flipping
around
the
default
so
that
you
know
the
amount
of
metadata
that
they
have
to
emit
to
keep
track
of.
Those
is
just
smaller
right,
but
it's
logically
complete
implementation.
Detail
of
the
encoding.
C
J
Yeah,
so
the
previous
discussions
around
this
was
whether
we
should
try
to
help.
In
that
case
and
say:
hey
you
have
a
reference
type.
Of
course
it
can
be
null.
You
have
a
value
type.
It
can
be
null
if
it's
wrapped
in
noble
t,
otherwise,
not.
J
C
A
C
A
C
I
think
no
literally,
the
video
is
now
like
that
you
actually
end
up
boxing
another
reference,
so
it's
not
just
you
so
like
if
you
so,
if
you're,
basically
there's
special
knowledge
in
the
runtime
for
boxing
and
an
unboxing
another
bill
of
tea
right.
C
C
Your
box
contains
an
end,
not
not
an
in
question
mark
and
similar,
if
you,
if
you,
if
you
bought
boxing
in
question
mark
that
happens
to
be
null
you
just
box
another
value,
that's
basically
the
behavior
of
the
runtime,
so
that
in
that
sense
it
is
handled
by
the
runtime,
not
the
language,
and
then
the
language
just
has
additional
semantics.
When
you
do
casting
and
stuff
like
that
right,
but
or
have
operators
and
stuff,
and
they
have
this
lifting
semantics.
C
B
C
To
me,
we
I
can
go
either
way
you
could,
because
reflection
is
all
object-based.
So
if
you
actually
set
a
property,
that
is
let's
say
in
question
mark
you
know,
because
the
the
values
that
you're
actually
exchanging
are
basically
over
the
underlying
type,
not
the
nullable
type
it.
It
doesn't
strike
me
as
insane
to
say
it
would
be
nice
if
notable
info
would
give
you
that
valuable
information.
C
The
the
only
question
now
becomes
is
like
what
is
type
is
type
now
the
unwrapped
thing.
So
should
it
say,
or
should
it
say,
nullable
of
end
right
and
that's
why
I
said
to
me
that
it
has
pros
and
cons
like
I
when
I
originally
wrote
it.
I
just
went
with.
We
just
exposed
the
c
sharp
notion
of
nullable
reference
types.
So
as
far
as
value
types
are
concerned,
they're
always
treated
as
you
know,
not
null,
and
you
know,
type,
might
give
you
another
blow
of
end
right.
C
A
Well,
I
think
like
so
it's
you
know,
let's
go
back
to
a
let's,
take
a
simple
parameter
of
int
question
mark
right,
the
I
guess
you
know
super,
let's
go
with
a
simple
method,
return
event
question
mark
and
there
are
no
other.
This
is
the
unannotated
case.
I
think
it
would
be
reasonable
to
say
that
the
type
is
nullable
event,
because
that
is
the
type
that
is
being
returned,
but
if
you're
calling
it
via
a
reflection
api,
there
were
comments
in
the
chat
that
it
is
not
a
box
null.
A
It
is
in
fact
you
get
the
null
reference
for
object
like
if
you
say
object,
you
know,
is
it
zero?
It
is
it's
the
zero
box.
You
don't
get
a
box.
Yes,
that's
what
it's
you
don't
get
a
box,
you
get
null
and
so
then
the
answer
is,
if
you
call
it
via
a
thing
that
can
be
cast
or
be
interpreted
as
object,
then
yes,
null
can
appear.
So
therefore
it
may
be
null
if,
if
cast
to
object,
null
might
appear.
A
So,
that's
why
I
think
that's
a
reasonable
starting
place
other
than
saying
well,
it's
obviously
nullable
of
t
if
the
type
was
a
value
type-
and
it
said
maybe
null
I
would
just
be
like
the
type
is
nullable
of
t
or
nullable
event,
and
the
answer
is
it
might
be
null
because
well,
it's
notable
yeah.
I
think
that
makes
sense
to
me
and
then
yeah
really
it
would
come
down
to
after
it
gets.
A
C
Does
anybody
know,
does
c
sharp,
actually
allow
these
custom
attributes,
or
does
it
honor
the
custom
attributes
on
notable
value
types,
the
not
null
win
and
stuff
yeah?
Can
I
yeah?
Can
I
basically
have
a
property
of
type
in
question
mark
and
then
basically
annotate
the
getters
and
status
and
say
the
setup
will
never
give
you
null
basically
do
the?
What
is
it?
A
C
C
sharp
fails
to
compile
it.
It
says
attribute
this
alone.
Now,
that's
not
valid
on
this
declaration
type,
it's
only
valid
on
property
index
field,
and
oh
actually,
I
put
it
in
the
wrong
spot.
I
guess
so.
I
can't
do
this
alone
now,
I
have
to
say:
oh,
I
have
to
put
it
on
the
property,
not
the
center,
okay,
okay,
so
that
one
compiles
now,
the
question
is:
what
does
it.
C
C
Naturally,
actually
the
compiler
number
ones
and
I
turn
another,
but
it
says
possible
another.
You
may
not
be
used
for
a
type
mark,
if
not
now
or
just
alone.
Now
so
yeah.
The
compiler
does
honor
them
on
available
video
types.
So
yeah
we
should
do
the
same
thing.
So
basically,
what
I'm
hearing
is
yeah.
We
should
just
specially
it's
not
above
t.
A
All
right
so
yeah
personally,
I'm
not
a
fan
of
the
maybe
null
name
but
I'll.
That's
the
amount
of
complaining,
I'm
willing
to
do
about
it.
So
what
would
you
like
to
see?
Instead,
I
think
yeah
nullable
seems
better
to
me.
I
think
nullable
was
reproposed
via
youtube,
chat.
C
F
B
C
For
some
reason,
I'm
not
thinking
of
arrested
development
so
yeah,
I
yeah.
I
think
that
was
fine.
I
think
booyah
said
the
same
thing
I
think
that's
reasonable,
so
it
would.
J
If
you
add
nullable,
maybe
nullable
state,
the
name
of
the
enum
should
be
nullability
state.
Then.
B
A
That's
yeah.
We.
C
Well,
I
mean
it's
just
the
default
right,
so
I
mean
so
I'm
not
trying
to
say
we
wouldn't
ship
it
as
a
package
right.
I'm
just
saying,
like
my
default
assumption,
was
we
just
rev
reflection
and
edit?
If
we
think
that's
a
feature
that
should
be
available
out
of
man
so
that
things
like
system
text.json
or
other
packages
can
use
it,
then
I
think
we
can
do
that.
C
I
mean
it
seems
to
be
something
that
can
totally
sit
separately
on
top,
there's,
no
reason
why
it
would
have
to
go
into
call
it,
but
it
also
seems
weird
to
me
to
like
if
we
just
wrap
the
platform
itself
by
ignoring
dawn
level
for
a
second
it
would
seem
weird
to
put
in
you
know
three
types
in
a
brand
new
assembly
right
just
for
yeah,
because
we
can
right.
F
I
mean
it
wouldn't
be
because
we
can,
it
would
be
because
we
apparently
have
a
significant
enough
code
base,
compiling
against,
say
netstandard
2o,
who
also
want
to
be
able
to
use
null
ability
and,
like
we
didn't,
tie
nullability
to
netcore.
So
why
would
we
tie
this
to
netcore.
C
Well,
that
goes
back
to
like.
What's
our
official
stance
on
that,
I
don't
know
and
officially
our
or
our
stance
is
that
net
standard
two
doesn't
support
t-shirt
aid
so,
but
I
so
to
be
clear:
I'm
not
saying
that
that
we
should
not
ship
this
as
a
package.
All
I'm
saying
is
when
I
thought
about
it.
I
just
thought
about
it
as
a
as
a
net
six
feature
right
and
I
think
within
that
six
we
should
put
it
where
it
makes
sense.
If
we,
for
example,
I
think
yarn
brought
this
up
as
a
concern.
C
Should
this
go
into
call
up,
so
if
we
think
it
shouldn't
go
into
caller,
it
should
go
into
a
separate
assembly
anyways
then
you
know
just
ubing.
That
assembly,
as
is,
is
probably
the
simplest
right
if
it
goes
into
call-up
and
then
we
also
ube,
then
you
know
we
can
do
that
too,
because
I
mean
the
api
can
probably
be
frozen
pretty
much
on
day
one
because
it
probably
doesn't
change
anyways
and
then
we
can
we
can.
We
can
do
that
too.
I
just
didn't
start
with
that.
A
C
C
C
I
mean
that's
a
fair
concern,
I
think
the
the
I
I
just
wrote
serializers,
because
it
seemed
to
make
sense
when
I
wrote
it,
I'm
not
saying
we
need
to
honor
it
in
system
text.js,
and
it's
just
something
that
we
could
honor
in
systemtext.json
right
and
I
think
I
would
leave
it
up
to
steve
and
laomi
to
make
a
determination
whether
that's
a
good
idea
or
not.
The
actual
scenario
that
was
brought
to
me
was
a
spinettes
model
binder
and
ef
they're
they're,
particularly
the
two
people
that
asked.
J
J
Yep
one
complication
in
making
it
boob
or
not
you
know.net
six
is
that
the
compiler
has
been
changing
the
way
it
adds
the
nullability
information,
so
it'll
be
more
complicated.
If
we
have
to
detect
that.
C
Yeah
to
be
clear,
I
think
the
compiler
is
done
now.
I
think
they
changed
it
halfway
through
eight
based
on
our
feedback
that
it
bloats
metadata.
So
like
the
idea
is
that
you
know
it
is
frozen
for
all
eternity.
So
the
if
you
wanted
to
do
it
yourself,
you
could
it's
just
you
know
quite
a
bit
of
code
to
get
it
right,
but
the
compiler
promised
to
never
change
the
way.
It's
encoded.
J
It
might
I
mean
you,
do
link
to
some
other
possible
new
attributes
and
optimizations,
and
things
like
that
right,
yeah.
C
So,
for
example,
if
you
wouldn't
have
shipped
the
maybe
null
when
attribute
in
v1,
if
we
wouldn't
add
it
now,
well
you
know
it
would
it
would
change
the
you
know
how
the
flow
analysis
would
reason
about
a
ref
parameter
right
and
so,
but
I
think
that
that
was
accepted
as
a
as
a
thing,
because
we
said
we
may
want
to
able.
We
want
to
be
able
to
change
nullable
annotations
themselves,
anyways
if
we
don't
consider
that
a
breaking
change
or
we
consider
that
an
acceptable
source
breaking
change.
C
I
should
say-
and
so
in
that
sense
I
think
yeah
it's
possible,
that
you
run
on.net
framework
and
then
based
on
the
presence
of
new
attributes
that
it
did
add
later
yeah.
You
may
actually
change
the
behavior
of
what
the
serializer
thinks
is
notable
or
not
notable,
but
that
seems
kind
of
more
far-fetched,
because
I
think
the
only
area
where
they
will
likely
add
attributes
is
for
flow
analysis.
I
think
for
static
representation.
C
A
Like
the
place
that
you
use
this
right,
it
takes
property,
infos
and
method
info
or
not,
method,
infos.
It
takes
property,
infos
and
other
things
that
are
too
small
for
me
to
see.
Since
the
tv
turned
off
and
like
you're
doing
reflection.
When
you
want
this
it's
so
it
feels
weird
that
it
would
be
go.
Add
this
other
namespace
to
go,
find
the
answer.
A
If
you
want
the
the
flow
state,
because
you
are
apisov.net
and
you're
trying
to
rebuild
all
of
the
declaration
in
a
unified
manner,
then
yeah
you're
going
to
also
need
that
namespace
except
you're,
not
you're,
going
to
need
weird
reflection
stuff
because
of
the
locally
defined
versions
of
the
attributes.
So,
okay,
so
reflection.
C
A
I
know
a
yeah,
so
so
reflection
makes
more
sense.
It's.
Basically,
this
comes
down
to
what's
the
name
spaces
you
would
have
already
had
an
import
for
when
you
want
to
use
this.
A
Everything
it
takes,
is
reflection,
you're,
obviously
doing
reflection
when
you
do
it,
it
feels,
like
reflection,
sounds
good,
and
so
I
think
we
can
say
that
we
would
approve
the
api,
as
is
as
and
then
the
assumption
is
it's
net
six
only
and
then,
if
rpm
feels
like
it's
warranted
down
level,
then
he
emo
can
come
up
with
a
packaging
proposal
and
that's
has
to
be
routed
through
our
down
level
packaging
person
which
is
emo
and
then
that
emo
basically
gets
to
do
whatever
it
wants.
C
So
I
mean
to
me:
it's
mostly
a
scenario
thing
right,
so
if,
if,
if
you
know
what,
once
or
so
guys
want
to
actually
use
it,
I
think
at
that
point
we
probably
have
a
requirement
to
make
it
available
right
and
we
can
like
one
option
we
have
in
system.
Text.Json
is
to
just
copy
that
code
and
make
it
internal
to
system
text.json,
because
it
won't
change
right.
So.
F
C
F
A
And
then
you
would
get
the
state
where
it's
the
you
know,
system
text
json7
package,
which
was
rebuilt
out
of
the
seven
tree,
if
assuming
it
does,
source
inclusion
instead
of
source
copy
paste.
It'll
just
now
know
about
these
new
attributes
as
well.
But
if
you
get
the
version
six,
when
it
doesn't
and
whatever.
C
F
C
There
are
not
that
many
people
that
want
this.
I
mean
this
got
a
decent
amount
of
upvotes.
I
think
it
got
like
100
comments
or
something
which
is
more
than
I
expected,
but
I
think
it's
also
more
because
people
just
expect
the
platform
to
be
able
to
do
that.
I
don't
think
that
the
people
that
all
commented
actually
really
need
that.
C
A
Yep
all
right,
so
I've
posted
the
notes
and
marked
it
approved
and
perfect.
I
note
that
we
are
past
time
and
therefore
we
will
see
everyone
who
cares
to
join
us
at
our
next
regularly
scheduled
session,
which
is
10
a.m
on
tuesday
redmond
time,
as
always
where
at
least
one
of
us
is
actually
in
the
city
of
redmond
right
now,
hello,
concrete
and
with
that,
I
declare
the
meeting
adjourned
and
I
have
the
gavel.