►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
All
right
good
morning,
everyone,
so
let
me
just
go
over
what
we
want
to
do
today,
so
we
have
10
open
issues.
We
still
want
to
review
the
backlog
because
we
have
a
lot
of
stuff
in
there.
It
seems
we're
still
hovering
over
33.
for
some
reason,
because
everybody
files
new
issues,
it
seems
so
we
will
do
a
few
more
out-of-band
api
reviews.
Normally
we
do
tuesday,
but
I
guess
we
will
do
a
few
more
thursdays
and
fridays
to
get
the
stuff
under
control.
B
Yeah,
I
can
talk
about
it
for
this
one
we
have
the
activity
class
which
is
used
for
tracing
and
this
class
have
a
property
is
called
tags
which
is
return,
a
collection
of
tags
which
is
key
value
pairs.
B
B
So
the
proposal
here
is
is
just
add
a
method
in
the
activity
tag
which
is
we
call
it
get
get
tag
item
which
just
takes
the
key
of
the
tag
and
it
returns
the
value
of
this
tag
from
this
collection
without
allocating
anything
why
we
use
this
name
get
tag
item,
because
we
have
a
similar
concept
inside
the
same
class
activity.
We
have
something
called
the
baggage
and
baggage.
B
B
A
Yeah,
so
it
seems
you
already
have
the
pattern
that
basically,
a
bunch
of
methods
are
directly
on
activity
like
get
an
ad
already,
so
that
seems
kind
of
within
that
thing
the
only
thing
is
like
I,
it
seems
the
actually,
maybe
I'm
looking
at
the
wrong
api
signature
here,
no,
never
mind.
Okay,
so
get
baggage
items
also
returning
another
string.
So
it
looked
right
now
it
was
returning
a
non-nullable
string,
but
that's
not
the
case
so
okay,
so
that
seems
fairly
straightforward.
C
A
A
B
B
E
B
A
B
A
F
A
D
D
D
Restructured
later,
to
avoid,
if
there's
a
on
the
fly
I
admirable
being
generated,
it
could
avoid
it,
but
it
this
is
really
just
about
cleaner
syntax
than
saying
items.first,
where
kvp.key
is
whatever.
B
Yeah,
actually,
internally,
we
we
have
that
we,
we
maintaining
the
list
inside
internal
like
linked
list,
and
when
you
you
request
that
the
package
or
the
the.
F
B
B
Yeah
I
I
internally,
we
can
optimize
this,
but
I'm
not
talking
about
about
the
tags
itself.
I
mean
we
are
not
going
to
do
the
same.
I
mean
we
just
like.
D
B
A
A
I
think
the
get
syntax
works
fine
and
if
you
actually
have
the
the
query,
synthetic
no,
not
the
query
syntax,
the
expression
was
it
called
the
pattern
kind
of
syntax.
Where
you
say
you
know:
if
activity
dot,
try
get.
You
know
key
comma
out
var
value
like
it's
very
similar
to
if
activity
get
tag.
Item
foo
is
string
s
right,
so
you
can't
even
write
the
code
the
same
way
almost
the
same
way
right.
You
don't
even
have
to
have
multiple
lines,
so
I
think
they're
both.
A
As
short,
I
mean
I
personally
find
the
get
one
a
little
bit
more
intuitive
than
the
try
get
one.
But
I
don't
have
super
strong
opinions
right.
A
Doing
I
guess
the
answer
then
is
like
you
know
the
the
get
one
is
basically
the
90
percentile
and
then,
if
you
want
more,
you
just
reach
over
the
collection
and
then
you
can
get.
You
know
multiple
keys
and
you
can
also
find
out
whether
they're,
actually
null
or
whether
they're
totally
non-existent
right
yeah
seems
reasonable.
G
So
the
host
the
the
hosting
model,
but
we
have
background
services.
You
know
the
generic
host
and
kind
of
there's
been
a
lot
of
complaints
about
the
way
we
handle
exceptions
that
happen
in
the
background
service
today.
G
Well
before
460,
when
an
exception
would
happen,
it
would
just
kill
the
kill,
the
background
service,
nothing
would
get
logged
and
the
app
would
continue
on
running
and
so
at
the
beginning
of
60.
We
we
added
it
so,
at
least
if
an
exception
happened
in
the
background
service,
we
log
it
and
now
the
ask
is
to
be
able
to
like
fail
the
app
basically
when
a
background
service
crashes
or
throws
an
exception.
G
The
proposal
is
to
add
a
there's,
an
existing
class.
This
hope
shop
host
options.
If
the
proposals
to
add
a
boolean
to
control
this
behavior,
it
would
be
off,
you
know,
be
false
by
default
to
continue
the
current
behavior
and
so
somebody
when
they
create
the
host
they
can
set
this
to
true,
so
it
would
crash
the
app
my
biggest
concern
with
this.
A
It's
really
clear,
like
these
host
options
are
the
the
initial
thing
that
you
create
right.
So
it's
basically
in
the
in
the
program
class,
where
you
basically
boot
up
the
create
default
builder
and
then
configure
web
host
defaults,
blah
blah
blah.
That's
where
you
would
pass
in
the
the
options
right.
G
A
G
A
G
G
A
Right
yeah,
that
makes
sense,
I
think
the
yeah.
My
only
concern
with
this
proposal
is
that
I
don't
know
how
discoverable
the
host
options
are
today
like.
I
would
think
that
most
people
probably
wouldn't
figure
out
how
to
do
that.
So
if
the
default
is
still
what
we
shipped
today,
then
I
think
very
few
people
will
be
actually
able
to
take
advantage
of
this,
but
I
also
don't
have
a
magical
solution
to
this.
Unless
we're
willing
to
say
yep,
it's
a
breaking
change,
we
document
it
and
then
it's
like.
A
If
you
want
to
get
the
old
behavior
back
yeah,
you
have
to
do
some
work,
but
almost
everybody
gets
a
new
behavior
for
free
right.
That
seems
also
not
I
don't.
I
don't
know
like.
It
seems
hard
for
me
that
you
want
this
behavior
like
because
your
app
is
probably
not
working
well,
when
half
of
your
services
stopped
working
right.
A
I
mean
that's
the
thing
right
if
we
believe
we
make
the
new
behavior
the
default
and
it
just
boils
down
to
you
know:
people
have
to
be
able
to
get
the
old
behavior
back.
Then
you
know
if
we
think
it's
super
advanced
and
almost
nobody
needs
that,
then
I
think
a
compact
switch
may
be
the
better
way
to
do
it,
but
yeah.
If
we
think
that
this
is
useful,
I
just
don't
think
it's
very
discoverable.
A
G
I
mean
quite
honestly,
it's
just
it
depends
on
who
you
are
and
what
opinions
you
have
right,
like
the
the
very
first
people
who
are
using
hosting
this
is
kind
of
a
pitfall
right
like
right,
especially
I
mean
especially
before
when
there
was
no
logged
exception.
It
would
just
go
off.
You
know,
but
there
has
been
a
decent
amount
of
complaints
about
the
exception
handling
to
the
point
where
people
kind
of
made
their
own
little
layer
of
like
critical
background
services,
where
they're
guaranteed
certain
behaviors.
B
A
I
mean
to
me
it's
kind
of
like
I,
I
am
I'm
honestly,
not
super
sure,
either
way
like
I
can.
I
can
see
arguments
for
both
ways.
I
mean
I
just
have
a
hard
time.
Thinking
that
somebody
wants
that
behavior.
I
can
see
somebody
inadvertently
relying
on
that
behavior,
but
I
don't
think
that
you
know
the
you
know
just
silently
continue
with
my
services
crash
as
desirable
behavior.
G
A
F
A
Picture
a
way
where
somebody
wants
that
I
can
just
see
a
case
where
well,
the
app
is
actually
buggy.
The
app
actually
doesn't
work,
but
it
works
enough
that
people
are
not
broken
by
this
behavior
right.
But
that
that's
why
I'm
saying
it
seems
to
me
it's
on
the
fence
of
like
I
can
see
an
argument
either
way,
but.
G
The
main
argument
for
me
for
changing
the
default
is
for
new
new
developers
coming
to
use
the
hosting
service.
This
seems
like
a
common
pitfall
right
that
they
they
don't
expect
that
they
expect,
if
your
background
service,
fails
that,
like
like
it
to
act
like
other
net
apps
right
for
your
app
to
go
down.
There's
an
unhandled
exception
goes
down.
A
G
A
Right,
that's
basically
the
way
you
would
do
it
and
then
you
would
say
yeah
you
found
your
project
and
then
you
get
that
behavior
you
will
just.
I
mean
there
will
be
another
discussion
now,
because
if
we
do,
if
we
go
down
that
path,
it
just
means
the
templates
will
grow,
which
people
also
don't
like
right,
but
maybe
that's
the
first
step
and
then
we
can
in
dotnet
seven
you
know
decide
that
or
maybe
we
should
maybe
we
should
just
make
it
the
default
right.
A
Yeah,
well,
I
wouldn't
be
breaking
this
release
right,
because
existing
code
behaves
exactly
the
same
way
and
if
you
do
follow
your
project
well,
the
behavior
is
observably
different,
but
I
don't
think
we
consider
that
a
breaking
change,
it's
just
well.
The
project
file
that
you
created
has
different
defaults.
I
mean
I'm
okay
with
that.
I
would
just
say
like
if
you,
if
you
expect
people
to
discover
this
api,
I
would
say
my
hope,
for
that
is
close
to
zero.
G
H
A
I
mean
my
personal
opinion
is
that
I
I
can
see
how
it
breaks
people,
because
you
may
have
an
app
that
works
today,
but
works
with
an
asterisk
where
one
of
your
background
services
crashes,
but
you
either
stopped
actually
using
that
thing,
you're,
just
not
aware
that
it's
actually
still
a
part
of
your
application
or
your
app
like
the
background
service
doesn't
do
anything
vitally
important,
and
so
it's
okay.
If
you're,
if
this
thing
doesn't
do
anything
anymore,
but
I
think
at
a
high
level.
A
I
have
a
hard
time
seeing
somebody
building
something
from
scratch
and
wanting
that
behavior,
where,
if
one
of
the
services
crashes,
the
app
keeps
running
right.
So
in
that
sense,
I
think
a
better
default
would
be
true.
It's
just
a
function
of
like
how
many
people
are
impacted
by
this
and
that
one
don't
have
a
good
handle
on.
G
H
Yeah,
I'm
pretty
sure
I
was
in
that
triage.
I
don't
think
we
were
ever
happy
with
the
behavior
and
we
were
just
trying
to
give
people
workouts,
at
least
as
we
discussed
in
triage
yeah,
if
there's
no
guiding
principle
that
says
that
a
change
like
this
is
never
acceptable.
I
would
personally
push
for
making
this
the
default
to
crash
the
process.
H
H
A
Too
many
right,
so
the
question
is-
and
that's
I
mean
I
don't
think
most
will
rely
on
this,
but
the
question
is
still
how
many
happen
to
rely
on
this
and
whether
we're
okay
with
that,
because
here's,
the
other
thing
right
so
keep
in
mind
when,
when
the
new
behavior
kicks
in
people,
wouldn't
necessarily
know
how
to
fix
it
right,
it's
not
obvious
that
because
you
change
their
behavior
now
you
have
to
send
you
know
sec.
You
know
it's
this
property.
A
Right
we
can
write
a
message
to
the
consonant
and
say:
hey
your
background:
service
just
died,
so
we
decided
to
shut
down
the
process.
If
you
don't
like
this
behavior
go
to
this
akms
and
figure
out
what
you
can
do
instead
right.
So
maybe
that's
okay,
but
I
think
if
it
happens
in
production,
probably
people
will
have
to
go
through
the
logs
to
figure
out
what's
happening
and
that
might
piss
people
off
right.
A
That's
why
I'm
saying
I
might
be
okay
with
saying:
let's
for
now
just
make
this
opt-in
right
by
either
giving
people
an
api
and
then
for
net
7
decide.
You
know
based
on
feedback
that
that's
the
new
default
and
we
make
a
breaking
change
and
change
the
template
and
sticks
yeah
yeah.
I
guess
that
would
be
a
good
idea.
Change
the
template
in
six
make
it
opt-in,
make
the
templates
opt-in
by
default,
and
then
you
know
in
seven
we
can
decide
screw
it.
We
just
make
it
the
default.
H
A
Like
the
the
problem
of
drawing
the
template
is
then
eventually
have
more
and
more
junk
in
the
templates
right,
but
I
feel
like
that
to
me
might
not
be
the
worst
of
the
world,
because
in
that
sense
our
templates
become
effectively
a
running
total
of
like
here's
new
behavior
right
and
then
you
have
to
decide
whether
you
move
it
out
of
the
template,
make
it
the
platform
default
or
whether
you
leave
it
in
the
template.
Right.
D
Yeah,
I
feel
like
somebody
had
asked:
does
it
make
sense
to
handle
that
so
I'll
ask
it
or
to
expose
a
handler?
Would
it
make
sense
for
this
to
be
basically
like
the
app
domain,
unhandled
exception
event
that
we
want
a
host
option
of?
What
do
you
want
me
to
do
given
this
exception,
and
so
that
somebody
could
decide
to
handle
different
exceptions
differently.
H
D
D
H
A
Yeah,
I
mean
I'm
not
sure
an
enum
is
necessarily
better
because
it
still
seems
you
have
now
a
centralized
place
where
you
have
to
handle
every
possible
app
model
in
the
world.
So
if
we
make
it
an
actual
event
where
you
can
write
code,
then
you
know
we
could
again
change
the
template
to
emit
the
code.
That,
basically
just
does
environment
fail
fast
and
then
another
app
model
is
where
you
want
to
do
something
more
sensible.
A
Like
I
don't
know
in
on
a
mobile
device,
you
may
want
to
call
some
operating
system
api
to
suspend
your
app
or
I
don't
know
what
the
what
the
semantics
are
for
that
and
that
might
be
better,
but
like
it's
certainly
more
ceremony
now
to
get
the
behavior
right.
I
A
That
one
I
don't
know
enough
about,
I
mean
I
would
assume
no
matter
what
you
do,
you
would
have
to
write
code
somewhere.
So
I
guess
you
could
still
say
in
config.
There
is
a
you
know.
There's
you
know
you
could
say
like.
Oh
in
config,
you
can
say
x
equals
true
and
then,
when
you,
when
you
read
config
you
you
know,
apply
some
default
handler
or
something.
H
But
so
my
understanding
on
this
is
that
it's
the
host,
that's
loading
the
configuration,
so
it's
a
little
too
early
right
now.
I
think
the
only
other
host
option
is
shutdown
timeout
that
can
be
configured
via
an
environment.
Variable.
H
It
it
might
be
fine
as
long
as
it's
using
it
late
enough.
I'm
sorry,
but
there
are
some
host
options
that
happen
before
configuration
that
are
used
before
configuration
is
loaded
right,
but
I
guess
that
probably
wouldn't
be
this.
A
Yeah
also,
I
don't
know,
but
the
configuration
helps
us
here,
because
it's
just
you
know
you
still
need
an
api
right.
So
then
you
may
maybe
there
is
configuration
on
top
or
maybe
there
isn't,
but
I
guess
the
yeah.
The
only
question
is
like.
Is
it
a?
Is
it
a
type
that
we
can
conveniently
set
from
configuration?
I
assume
enums
would
work
already
and
so
enums
or
boots
will
be
easier
versus
a
delegate
or
an
event
wouldn't
be
as
great
to
set
from
config,
but
maybe
I'm
also
over
engineering.
A
D
Yeah-
and
I
do
think
that
when
I
said
event,
I
probably
meant
just
a
single
action
and
not
a
an
actual
event,
because
I
don't
know
what
multicast
would
mean,
especially
if
we
think
that
someone's
gonna
write
environmental
fail
fast.
A
D
Have
to
do
a
whole
lot.
More
work
to
like
assignment
versus
edition
is
different
pattern
sure,
but.
A
A
Doesn't
respect
this?
Yes
yeah,
I
guess
yeah,
that's
my
question.
So
does
the
web
host
derive
from
like
web
host
options?
Does
it?
Is
there
a
web
host
option
that
drives
some
host
options
or
are
they
separate
options
there's
a
book?
Well,
they
have
web
host
builder
options
right
which
doesn't
seem
to
derive
from
it.
So
I
guess
what
I'm
asking
is
like
who's
like.
If
we
put
us
on
this
type
like,
does
it
actually
go
in
all
the
right
places
or
do
we
have
to
put
this
on
more
times.
A
D
A
D
Continue
become
is
a
weird
word
because
it
sort
of
feels
like
vb's
on
air
resumed
next
and
what
it's
really
doing
is
it's
terminating
the
the
background
service,
but
not
the
process
right.
H
H
H
Right,
I
thought
we
were
doing
more
of
an
application
lifetime.
Stop
application
thing
originally,
where
it
just
tries
to
shut
down
the
host.
A
I
Yeah,
I
don't
know,
don't
we
want
to
have
a
graceful
shutdown
when
like
when
we
opt
in
to
like
stop
the
application
in
that
case,
fail
fast.
Would
that
be
what
we
want
to
do.
A
Yeah,
I
guess
I
think
not,
I
think
it
fell
fast
to
me
only
makes
sense
if
you
actually
have
the
ability
to
get
a
dump,
if
you,
if
you,
if
you
don't
care
about
that,
and
it
seems
to
me
like
just
exiting
the
host
or
whatever
the
technologies
that
you're
using
for
just
basically,
you
know
getting
out
of
the
run
loop
that
that's
probably
is
a
more
sensible
default,
which
in
practice
probably
means
just
up
shutdown
right,
because
there's
no
other
code.
That
runs
after
that.
D
Right,
I'm
just
yeah,
I
mean
my
expectation
without
knowing
what
any
of
this
is
actually
doing
was
that
it's
basically,
instead
of
treating
it
like
a
background
thread
which,
if
it
throws
an
exception,
is
ignored,
treat
it
like
a
foreground
thread
which,
if
it
throws,
has
an
unhandled
exception.
Your
process
is
terminated
like
right.
No
graceful
handlers
kick
in
unless
you
registered
app
domain,
I'm
about
to
die,
and
then
you
can
be
like.
Oh
cool.
D
Do
something
great
now
now
it's
too
late
we're
dead,
but
so
that's
where
I
thought
terminate
process
was
coming
in.
If
this
is
terminating
some
host
object,
then
that
would
be
a
different
set
of
words.
A
A
G
G
G
I
So
so
I
host
builder
has
build
and
run,
I
believe,
actually
no
ios
builder
has
build,
and
then
I
think
I
host
has
is
that
the
one
that
has
run.
A
Yeah,
so
I
mean
in
that
case
it
sounds
like
stop
host
would
be
the
you
know.
The
accurate
description
then
what's
happening
when
we
say
you
know
just
just
basically
don't
terminate
the
process
just
finish
the
the
host
right
and
then
subsequent
code
can
run.
G
G
D
D
D
D
H
So
so
maybe
not
continue.
I
think
ignore
is
fine.
I
I
don't
know
why
you
would
assume
that
the
services
get
restarted,
but
if
you
want
to
put
like
not
restart,
I
don't
know.
D
A
A
G
D
D
D
D
If
you
don't
write
the
word
async
you
can
throw
and
that
throws
on
the
call
instead
of
in
the
task
there's
and
there's
a
very
important
distinction
of
one
of
them
is
thrown
to
the
caller
and
the
others
only
throw
into
the
caller
if
they
all
await
or
get
results
or
any
of
the
other
things
that.
A
Yeah,
so
I
guess
to
me,
ignore
kind
of
is
probably
the
least
promise
like
the
the
best
word
is
and
because
it
doesn't
apply
a
lot
of
policy,
because
otherwise
it
gets
very
funky.
If
you
say
well,
it
depends
on
how
the
you
know
the
actual
service
failed
right,
and
that
becomes
very
nuanced.
Then,
if
it's
literally
just
oh
yeah,
we
basically
stop
the
service.
I
mean.
Maybe
stop
service
is
the
better
word
then,
but
if
it's
like
well,
sometimes
we
stop.
Sometimes
we
don't,
I
think
ignore
seems
fine.
A
A
D
Yeah
it
ignores
okay,
I'm
just
I'm
merely
raising
that
there
is
an
interpretation
which
is
pretend
the
exception
didn't
happen
right,
which
would
be
like
on
air
resume
next,
and
if
everybody
believes
that
in
2021,
that
would
be
an
absurd
interpretation
for
someone
to
have
then
cool.
D
I
Hosted
service
the
background
service
would
that
through
exception
would
probably
not
work
and
so
every
place
yeah
so
like.
If
we
do
continue,
would
it
convey
the
message
that
the
background
service
that
through
is
continuing,
is
going
to
continue
working,
which
is.
I
B
A
I
mean
one
way
to
to
do
it
would
be
to
say,
like
you
know,
to
me,
the
difference
between
ignore
continue
implies.
The
service
continues,
which
is
not
the
case.
Right,
ignore,
doesn't
really
imply
anything.
It
just
means
that
we
know
we
eat
the
exception,
and
then
you
would
have
to
think
about
what
that
means
for
the
overall
app,
which
I
think
seems
probably
the
least
controversial
one.
D
I
feel
like
my
proposal,
would
be
terminate
service
instead
of
continue
and
stop
application
being
the
one
that
calls
the
stop
application
method.
A
Yeah
I
mean
to
me
log
and
stop
kind
of
implies
that
first
we
will
always
log
which
might
not
actually
hold
true,
because
to
me,
logging
is
kind
of
an
orthogonal
concern,
so
I
wouldn't
necessarily
promise
that
as
part
of
the
enum
and
then
like
stop
kind
of
implies
that
you
actually
call
stop
service,
which
we
don't
right.
We
just
with.
D
I
A
H
Yeah,
just
in
my
mind,
it
seems
like
the
host
is
taking
proactive
action
to
stop
the
service
in
that
case,
like
with
any
of
those
namings
in
reality,
it's
just
not
doing
things
because
when
an
exception
is
thrown,
but
I
don't
know.
D
Yeah
I
mean
like,
I
feel,
not
very
strongly
that
it
should
describe
the
behavior
that
the
author
of
the
code
experiences
as
opposed
to
what
the
code
that
is
calling
it
is
doing
where
the
ignore
is.
It
was
a
background,
something
on
a
background
thread
through
the
like
the
threads
terminated
in
the
process.
Didn't
care
like
we're
done
caring,
like
that's
a
detail
of
implementation,
but
what
they
experience
is
this
thing
that
you
registered
as
a
background
service
is
terminated.
H
D
H
G
Answer
want
to
go
back
to
stop
application,
real
quick,
because
I
I
think
it
should
stop.
It
should
be
the
behavior
I
think,
should
actually
be
to
stop
the
host
and
the
stopping
the
host
calls
that
stop
application,
and
so
I.
A
A
Yeah
that
sounds
good.
Okay,
like
honestly,
it
doesn't
even
matter
like
the
order
right
like
even
if
you
call
even
I
mean,
even
if
the
implementation,
where
you
you
stop
application,
calls
stop
host.
I
think
it's
fine
right,
like
it's
logically
really.
The
thing
you're
talking
about
here
is
the
host
and
the
host
ends
right.
I
think
that's
the
number
one
thing
you
want
to
convey.
G
H
There
is
that
whole
dance
with
application,
stopping
that
the
run
async
extension
method
does
right.
So
there
is
like
a
a
subtle
difference
between
stopping
the
application
host
generally
stopping
the
application
induces
the
latter
in
run.
Async.
A
H
Yeah,
I
think,
stop
host
is
okay,
it's
just
it.
G
G
A
I
I
mean,
I
think,
for
I
think
the
default
video
makes
more
sense
when
you
consider
default
parameters
and
overloads
and
stuff.
But,
like
I
don't
know,
if
you
call,
if
you
talk
about
settings,
I
think
it's
okay
to
say
a
default.
Video
is
not
the
default
memory.
Right
like
it
could
be
a
default
string
of
something
right.
H
H
G
H
H
So
generally,
when
we
shut
down
the
host,
we
use
eye
application
lifetime
when
it's
running
the
whole
stop.
Async
is
kind
of
what
happens,
kind
of
after
control
c
triggers.
You
know
you
know,
or
a
sig
term
or
whatever
triggers
iaplication.stop
application
to
run
and
there's
just
the
kind
of
entire
unwinding
so
to
have
something
from
like
another
thread,
call
host.stop
async.
I
don't
know
if
we
do
that
anywhere
or
like
from
another
continuation.
A
Yeah
to
me
it's
a
distinction
about
a
difference
because
I
mean,
like
nobody,
actually
calls
any
methods
here
right.
It's
just
you
saying
what
behavior
you
want
and
I
think
the
key
here
is
you
want
to
stop
the
you
know,
shut
down
or
exit
the
whole
sort
of,
like
any
word
that
conveys.
That,
I
think,
is
fine.
I
would
argue.
A
D
D
D
H
D
That
someone
would
want
to
ignore
what
or
hope
that
they're
keeping
ignore
past
the
upgrade.
Maybe
someone
even
writes
the
line
that
sets
it
to
ignore,
and
then
someone
else
later
looks
at
the
code
and
is
like,
but
you're
setting
this
to
the
value
it
already
has
by
default.
This
is
stupid
and
then
erases
that
assignment
and
now
they're
back
to
it
depends
on
which
version
of
the
runtime
they
have.
A
A
H
Right
right,
like
I
think,
if
it
weren't
for
back
and
forth
issues,
we
would
make
this
the
default.
The
stopping
the
host,
because
of
this
whole
discoverability
thing.
E
A
Well,
I
think
if
we
already
knew
that
we
will
change
the
default,
then
I
don't
think
I
would
do
an
api,
but
I
think
the
problem
here
is
that
we
don't
know
how
many
people
are
broken,
and
so
we
want
this
staged
kind
of
thing
where
we
say
well,
we
don't
change
the
default
4.net
6.
We
just
changed
the
template,
so
new
apps,
we
use
the
new
behavior
and
then
by.net
7
we're
going
to
decide
whether
we
actually
change
the
default
right.
A
B
G
G
A
F
A
The
because
that's
the
one
that
we
actually
announced
very
heavily
and
then
the
rest
are
just
increments
right.
So
I
think
any
change
before
build
seems
will
probably
get
attention
anything
after
build
yeah.
You
basically
talk
about
a
few
thousand
people
right.
So
that's
why,
given
that
we
are
relatively
early,
I
think
I
can
live
with
the
you
know,
let's
break
and
see
what
falls
out.
A
I
I
think
past
build.
I
would
probably
go
with
you.
Don't
really
know
until
you
ship
an
rc
and
then
yeah
then
becomes
a
fire
drill.
I
mean
it's,
not
a
horrible
fire
rule.
I
mean,
I
think
we
can
decide.
I
guess,
but
I
I
don't
know
like
to
me.
It
kind
of
seems
like
already
have
a
design,
so
we
would
just
have
to
get
it
out
of
the
you
know,
cabinet
and
then
just
to
you
just
implemented
right.
A
I
mean,
then,
I
would
say
that
the
only
concept
of
the
conservative
plan
is
more
noise
right.
You
introduce
an
api.
You
change
templates
one
way,
then
you
change
templates
the
other
way,
so
that's
that
might
be
a
bit
over
the
top
for
something
that
maybe
not
many
people
actually
are
impacted
by
right,
but
that
is
kind
of
predicated
on
that
right.
If
I
don't
know,
10
of
apps
are
broken
by
this,
then
that's
probably
a
bad
plan
right.
If
it's
less
than
one
percent,
then
it's
probably
fine
and
that
one
I
just
don't
know.
A
I
mean
it's
very
hard
to
reason
about
error,
behavior
and
how
people
rely
on
this
inadvertently
right
but
yeah.
I
don't
know
like
to
me.
It
seems
like
it's
not
an
insane
plan
to
say
screwed,
we
don't
ship
any
api.
The
only
thing
we
do
right
now
is
an
app
compat
switch
and
the
new
behavior
is
the
new
behavior.
G
I'd
be
okay
with
shipping,
a
new
api
and
changing
the
default.
I
think,
especially,
and
especially
that
gives
us
much
more
ability
to
just.
We
just
change
the
default
back.
If
we
get
a
bunch
of
of
reports
that
this
is
breaking
them
right,
but
the
api
is
still
there
and
then
you
can
pick
which
one
you
want.
D
I
A
Mean
even
if
you
have
an
api,
I
think
we
would
have
to
document
the
breaking
change
right
and
I
think
that's
usually
where
we
would
document
or
the
context
in
which
you
would
document
the
app
compat
switch
like
to
me.
The
only
reason
I'm
saying
you
know,
maybe
we
don't
do
an
api
is
because
I
don't
think
the
api
is
massively
discoverable
either.
A
A
G
A
I
think
to
me
kind
of
depends
on
what
you
think
the
future
is
right.
So
to
me,
an
app
compat
switch
only
makes
sense
if
you
believe
it's
a
temp,
if
that,
if
we
expect
for
most
people
it's
a
temporary
clutch
until
they
have
it
under
control,
if
you
think
somebody
will
write
a
net
new
app
and
they
want
the
old
behavior
for
that
app
by
design
an
app
compat
switch,
I
think,
is
horrible.
I
think
at
that
point
you
want
to
say
no.
I
have
an
intention
here
and
I
intend
to
use
this
behavior.
A
G
H
H
So
it's
like
originally,
we
just
had.
I
hosted
services,
if
I
recall
correctly,
and
then
we
added
background
services
that
gave
you
this
execute
async.
So
now
there
certainly
could
have
exceptions
after
star
dacing,
but
I
think
if
we
started
with
just
background
services,
we
would
have
had
it.
A
Okay,
so
I
think
I
actually
like
the
plan
of
shipping
the
api.
I
think,
because
it
gives
us
the
most
flexibility
and
even
if
we
eventually
think
that
it's
a
mistake
to
offer
that
behavior.
I
still
think
it's
not
terrible,
because
it's
also
not
a
very
prominent
api,
so
it
doesn't
really
pollute
people's
experiences.
A
So
yeah,
I'm
fine
with
it
being
an
option.
I
don't
think
it
means
switch,
and
so
that
means
to
me,
like
you
know,
if
we
actually
get
feedback
from
the
previews,
that
it
breaks
too
many
people.
The
only
change
we
would
have
to
do
is
change
the
default.
Everything
else
would
stay
as
is
right,
and
then
maybe
we
additionally
change
the
templates,
because
we
think
new
code
should
take
the
new
behavior,
but
that
seems
optional
at
that
point,
but
that's
the
fewest
amount
of
moving
items
here.
A
F
E
The
the
notable
four
that
are
missing
from
this
list
are
the
max
number
and
max
magnitude
number
apis
which
we
previously
reviewed
and
which
got
pushed
back,
because
there
were
concerns
about
confusing
users
with
the
additional
names,
but
they
are
also
technically
part
of
this
set.
E
E
E
The
and
the
the
only
alternative
for
those
ones
so
far
has
been.
We
could
put
them
on
float
and
double
as
static
methods,
but
given
the
the
requirements
around
syncing
with
the
language
and
everything
else
on
that,
and
if
we're
going
to
be
adding
this
full
set
of
apis
as
well,
I'm
not
sure
that
the
confusion
warrants.
Postponing
those.
E
I
think
the
the
intellisense
and
the
fact
that
they
only
exist
for
double
and
float
will
allow
users
to
know
how
they
function
and
how
and
how
to
use.
A
E
A
F
A
The
whole
way,
I
think,
the
confusion
I
mean
because
I
don't
know
like
just
exposing
these
apis
by
themselves.
I
think
I
can
defend
the
or
that's
confusing
and
seems
a
little
value
if
it's
part
of
a
larger
set,
and
that
gives
us
the
entire
com.
You
know
compliance
might
be
the
wrong
word
here,
but
yeah,
my
the
entire
consistency
of
that
spec.
A
That
seems
a
bit
more
of
a
compelling
argument
at
that
point,
but
I
mean
there
certainly
will
be
people
that
will
be
confused
by
this,
but
it's
probably
not
worse
than
you
know
the
two
or
three
or
four
options
that
we
have
for
rounding
right
where
you
have
to
read
the
oh
yeah.
This
means
this.
This
means
that
and
then
well.
A
E
A
E
Right
it
it
so
it
computes
a
tan
two,
just
like
regular
and
a
tan
two,
but
there's
some
it's
not
directly
expressible
in
basically
normalc
and
I
didn't
want
to
have
to
write
out
the
three
or
four
paragraphs
explaining
the
difference
there,
because
a
tan
two
is
effectively
a
tan
y
over
x.
E
The
the
handling
around
pi
is
isn't
quite
a
a
tan
y
times
pi
over
x.
It's
it's
slightly,
adjusted
to
account
for
divisions
within
where
one
of
the
inputs
is
infinity
or
negative
infinity.
In
a
couple.
Other
cases.
D
Okay,
but
so
I
guess
it's
if
it's
like
a
tan
two
but
different,
then
I
guess
that
makes
sense
why
it's
y
comma
x,
when
everything
else
is
x,
comma
y,
but
a
tan
two
is
named
a
tan
two.
So
should
this
be
tan
pi,
two.
E
The
name
in
the
in
the
ieee
spec
is
a
tan
two
pi.
D
E
E
I
also
just
updated
them
in
the
original
post
to
make
that
easier
to
correlate
later.
D
A
A
E
Tanner
all
right,
so
we
actually
approved
this
api
already.
This
was
the
one
that
I
mentioned
where
there
was
a
question
on
whether
or
not
it
should
be
an
extension
method,
because
the
equivalent
api
we
exposed
on
for
vector,
128
and
vector
256
is
so,
if
you
scroll
all
the
way
to
the
bottom.
E
E
Oh
no!
It's
it's
too!
It's
one!
Co!
It's
above
right
there
I
didn't
put
it
there.
We
just
responded,
basically
change
it
from
not
being
an
extension
method
to
being
an
extension
method.
A
A
A
A
E
When
we
were
going
to
expose
vector,
128
vector
256,
we
notice
that
this
actually
hinders
code,
gen
optimizations
due
to
this
being
reference
taken,
and
so
we
opted
for
vector,
120
and
256
to
make
everything
a
static
extension
method.
Instead,
that
way,
you
would
still
get
the
nice
to
use
api,
but
you
wouldn't
have
the
reference.
The
the
the
reference
taken.
A
A
A
E
D
A
E
Not
today,
you
have
to
specify
both
t
from
and
t2
and
that's
what
the
user
was
asking
about.
The
issue
with
having
it
be
an
instance
method,
however,
is
it
hinders
code
gen
and
at
least
with
vector,
128
256.
We
said
that
that
was
undesirable
overall,
because
it
leads
users
into
a
pit
of
failure
with
the
types
that
are,
namely
meant
to
be
performance,
oriented.
A
E
It
makes
it
more
readable
overall,
the
the
typical
use
case
for
generics
is
you'll,
have
the
ad
the
as
method
at
most
once
per
input
and
once
for
the
output
and
having
it
read
as
as
with
the
with
the
expected
type
and
the
type
you're
casting
to
ends
up
helping
the
readability
of
the
code
overall
as
compared
to
having
to
call
vector
as
type
type
input
input.
A
Binder
who
marked
this
again,
this
would
be
sanji
if
he's
on
the
call,
I
think
he's
out,
so
it
probably
isn't
on
the
call.
Can
anybody
else
talk
to
this?
Otherwise,
let's
give
it.
I
Yes,
I
remember
this
one.
Let
me
quickly
have
a
skim
source.
Three,
six
zero
one;
five,
three,
six:
zero
one:
five!
Oh.
G
I
So
I'm
trying
to
read
on
santi's
comment.
A
A
G
A
G
A
Yeah
yeah,
I
think
the
the
proposal
here
is
to
have
the
current
behavior
as
the
default,
and
then
the
new
behavior
would
be
opt-in.
That's
how
I
read
it,
but
like
just
just
to
ask
eric
like
it
seems
that
what
you're
describing
is
the
inverse
of
what
the
what's
proposed
here,
because
basically
it
says,
if
doing
configuration
binding,
a
configuration
key
is
found
for
which
the
provided
model
object
does
not
have
an
appropriate
property.
So
that
means
you
have
one
more
in
your
json
file
than
you
actually
have.
That's.
H
A
No,
I'm
not
saying
you
know,
make
the
same
decision
for
both
I'm
just
saying
like
for
the
first
one.
It
completely
makes
sense
because
you
basically
have
a
type
one.
Your
json
file
right
or.
B
G
A
A
A
G
A
F
G
A
More
intuitive,
at
least
right.
H
F
H
H
H
G
I
Trying
to
think
if,
like
something
like
this,
like
error
on
key
missing,
would
be
something
that
can
be
handled
when
we
are
doing
options.
Validation
like
rather
than
having
a
binder
option.
H
I
That's
one
thing
I'm
thinking
about
and-
and
I
think,
if
I
understood
mo's
recommendation
correctly,
if
we
had
like
a
attribute
on
the
properties
themselves,
it
wouldn't
have
to
be
like
all
or
nothing
so
like.
If
it's
the
connection
string,
then
maybe
for
the
connection
string.
Only
then
maybe
like
there
are
cases
where,
like
the
whole
application
may
be,
logging
or
a
lot
of
things
are
not
necessarily
always
specified,
but
they're
like
said
by
default,
and
then
someone
needs
to
go
and
go
through
all
properties
and
see
if
they
are
missing
anything.
I
I'm
not
sure
this.
Just
my
first
thought.
H
So
can
we
approve
error
on
property
missing
and
then
maybe
investigate
further
the
air
on
key
missing
and
look
at
the
attribute
pos,
possibly.
G
G
G
Property
missing:
it's
that
you
have
a
property
in
your
code
in
the
object
that
didn't
get
supplied
by.
So
the
other
thing
is.
This
goes
through
objects.
Right,
like
this,
isn't
just
simple
strings
and
you're
checking
the
string
for
null.
It's
like.
I
have
my
top
level
section.
That
section
has
a
sub
section
right:
you'd
want
you'd,
have
to
check
for
null
all
the
way
down
all
the
time
where.
F
D
H
A
D
Argue
with
that,
it's
like
open
ssl
had
this
model
in
their
configuration,
and
then
they
added
some
properties
in
openssl,
one
one,
and
when
dotnet
core
picked
up
openssl
100,
and
then
it
found
a
config
file
that
specified
those
properties.
Then
the
process
terminated
because
it
was
you've
configured
me
with
something
I
don't
understand
and
then
so
later,
when
they
added
stuff
in
one
one,
they
then
changed
their
model
to.
D
If
I
don't
know
what
it
is
ignore
it
because
this
could
be
config
from
the
future
running
on
an
old
app
needs
to
be
something
throwing
to
me
feels
like
something
you
should
opt
into
unless
we're
already
doing
it,
in
which
case
it's
fine.
A
D
A
G
In
the
original
post,
like
the
second
one,
is
the
one
that
they're
talking
about.
In
the
event,
the
property
doesn't
get
bound,
the
binder
simply
defaults
to
null
for
that
property.
This
results
in
runtime
null
exceptions,
and
now
your
app,
you
know,
gets
null
refs
from
the
binder
or
from
the
thing
that
walked.
D
Through
the
dot,
without
checking,
if
it
was
null
obviously
from
the
thing
that
walked
through
the
dot
right,
so
that
seems
like
they
wanted
it
on
this
particular
item,
which
is,
I
didn't
understand
that
I
should
supply
a
default
value
and
really
that's
a
bug
in
their
application
of
they
had
a
config
model
and
they
didn't
accept.
Do
whatever
you
want,
as
the
config.
H
So
I
guess
the
only
risk
is:
if
we
don't
do
the
air
on
queue
missing,
is
there
a
risk?
Like.Net?
Six?
We
don't
cover
the
scenario
at
all,
because
we
don't
do
like
the
attributes
either
and,
like
worst
case,
it's
a
little
bit
redundant.
There
are
workarounds.
Of
course
you
can
always
check
properties
explicitly
in
your
consuming
code.
I
I
As
think
it's
on
track
to
do
a
little
more
improvement
for
options,
validation
for
6.0,
so
maybe
that
would
overlap
with
our
on
keynesian.
So
that's
my
thought.
I
Their
own
property
missing,
trying
to
think
yeah,
I'm
not
too
sure
if,
like
maybe
we
can
kind
of
I'm
not
a
super
keen
on
having
these
apis
in
yet,
but,
like
my
I
don't
have,
my
only
argument
would
be
that
maybe
this
is
like
a
one-off
thing,
as
opposed
to
maybe
like.
I
It's
like
it's
a
one-off
feature
that
we're
just
gonna
put
in
on
configurations
and
I'm
not
sure
how
much
value
there
would
be
and
there's
I
don't
know
what
you
guys
think,
but
I.
I
I
H
We're
talking
about
so
I
don't
know
anything
about
options,
validation,
we
don't
have
to
get
too
deep
into
it,
but
does
that
deal
with
the
eye
configuration
binding
to
options
or
is
that,
after
the
options
have
already
been
like
created.
I
It's
upon
startup,
so
from
what
I've
understood
is
when
we're
using
service
provider
in
di
there
is
a
service
provider
option
for
doing
validate
on
build.
But
that's
because
di
is
not
hooked
up
with
options
it.
We
like
the
the
the
thing
about
options.
Validation
is
that
if
we
could
have
that
sort
of
functionality,
but
not
for
like
early
when
we
build
to
be
able
to
do
validation
on
options,
so
I
think
it
has
relevancy
with
binding.
If
we
need
to
do
binding
to
be
able
to.
I
Do
the
validate
eager
feature
properly,
but
that's
my
high
level
thought
about
this
without
going
too
deep
in
the
code
yet
correct
me.
If
I'm
wrong,
though,.
A
Yeah
I
mean
I
mean,
even
if
we
have
a
customizable
configuration
or
like
configuration
validation,
I
don't
know,
I
think
the
property
still
adds
value,
because
if
you
validate
something
you,
you
probably
still
don't
deal
with
unmatched
properties
by
default
right,
you,
you
would
just
say
well,
the
user
specified
value
x
is
value
x
in
range
or
something
like
that
or
the
user
specified.
These
four
values
is
the
combination,
legal
or
something
right.
So
I.
F
A
Me
this
property
really
is
like
you
know,
it's
not
a
well-formed
configuration
file,
because
we
can't
bind
the
value
right.
That
is
usually
not
something
that
I
would
think
a
user
would
actually
write.
Validation,
for
you
would
expect
that
to
be
already
done
by
the
framework.
D
A
A
All
right,
let's
go
before
now
and
then
so
error.
H
True
air
on
unmatched
configuration-
I
don't
know.
C
E
A
G
A
All
right,
yeah
anything
more
to
this.
H
D
D
A
I
Adding
the
new
overload
create
default
builder
would
allow
us
to
kind
of
pass
it
in
and
if
you
scroll
up,
I
think
that
david
has
a
reason
behind
where
this
is
needed.
Is
that
true.
G
A
G
F
F
A
D
G
A
Cool
so
nice,
so
today
we
went
to
six
issues,
that's
actually
decent,
all
right.
So
then
I
see
you,
I
think
next
tuesday.
So
I
think
this
was
the
last
extra
one
that
we
had,
or
maybe
we
have
one
more.
I
will
probably
set
up
more
because
we
I
really
want
to
get
to
a
point
where
we
have
less
than
10
again
so
that
we
don't
have
this
ever-growing
backlog
situation.
A
I
D
G
D
G
G
D
Emo
doesn't
cave
on,
configure
going
back
to
create,
then
I'm
good
with
whatever,
and
so
I'm
gonna
go
ahead
and
drop.
H
It
doesn't
noise
up
host
dot.
This
way,
yeah
true.
A
Nice
all
right,
then,
let's
call
it
a
day,
and
then
I
see
everybody
next
week
have
a
good
weekend.
Bye,
bye.