►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
A
A
A
B
Complexity,
this
isn't
going
to
introduce
a
release
or
the
you've
completed
the
value
task.
So
the
source
is
refreshed
problem.
It
doesn't
have
a
problem,
but
it
means
basically,
once
you
use
weight
async
on
a
value
task.
You
can't
touch
the
value
task
again,
which
is
the
reason
why
adding
it
is
a
little.
B
B
B
Yeah,
so
why
don't
we
start
with
just
the
task?
How
do
people
feel
about
switching
from
the
configure
weight
to
weight?
Async
right,
it
looks
good
to
me.
My
only
concern
would
be
just.
Are
we
comfortable
with
the
perf
implications
here
and
the
only
other
feedback
I
would
have?
Is
I'm
just
looking
at
the
existing
task
that
weight
method?
It's
got
some
a
slightly
random
set
of
overloads.
Do
we
want
to
mimic
those
or
not
right?
B
The
the
randomness
you
refer
to
is
in
part
that
it
also
has
overloads
that
take
int
timeout
or
in
milliseconds
timeout,
yeah,
and,
and
I
and
it
I
think
it
only
has
I
don't
remember
now.
I
think
it
only
has
that
for
like
the
one
that
just
takes
a
timeout,
but
it
doesn't
for
the
one
that
also
takes
a
cancellation
token,
or
maybe
I
miss
remembering
it's
actually
the
other
way
around
it.
B
C
B
Weird
thing
is
it's
missing
what
seems
like
the
most
complete
one,
which
would
be
you
know,
time
span
cancellation
token
right,
so
I
I
honestly
don't
have
a
strong
opinion
about
whether
we
have
an
int
overload
or
two
into
overloads
here.
I
didn't
include
them
just
because
I
know
there's
been
feedback
in
the
past
about
not
liking
the
fact
that
we
have
this
raw
int
without
a
unit
associated
with
it.
But
if
people
want
to
add
it,
I'm
totally
fine
with
that.
B
No,
I
mean,
maybe
by
a
few
bytes
if
we
really
wanted
to
eke
out
perf,
but
the
configurate
still
needs
to
allocate
some
object
to
coordinate
between
the
task,
completing
the
cancellation,
token,
completing
being
canceled,
and
the
time
span.
Timing
out,
I'm
having
a.
I
have
a
hard
time,
imagining
a
scenario
where
it
wouldn't
need
that
extra
object.
Now,
maybe
you
could
do
something
like
pooling
that
object
if
you
wanted
to,
but
it's
I
think
any
implementation
we
would
go
with
for
the
foreseeable
future.
B
C
A
I
I
honestly
would
have
said
the
same
thing
because
you're
effectively
having
to
call
some
method
on
you
know
before
you
actually
await
it,
so
it
will
look
virtually
identical
in
intellisense
I
mean
you
could
argue
that
configure
weight
is
the
uglier
version
of
this
year,
but
I
feel
like
discoverability
wise.
It's
the
same
because
you
just
do
dot
and
you
know
things
show
up
in
intelligence
or
not.
A
B
As
well
from
there
was
a
question
earlier
about
efficiency.
My
hope
as
well
is
that
these
methods
are
the
rare.
You
know.
Are
the
minority
use
case
like
you?
Ideally,
you
don't
need
these,
because
the
apis
that
you're
using
take
a
cancellation
token
right,
for
example,
these
are
only
used
if
you're
trying
to
wait
on
something
that
doesn't
support
these
concepts,
and
so
my
hope
is
these
aren't
showing
up
on.
You
know
really
core
critical
hot
paths.
B
And
this
also
solves
the
you:
don't
want
the
throw
to
happen
right,
because
you
could
await
the
weight
and
then
ask
if
the
state's
faulted
yeah
I
mean
if
we
were
to
add
a
subsequent
a
custom,
a
waiter
that's
suppressed,
then
it
would
work
with
this
like
it
would
with
any
task.
I
guess
if
wade
async
is
returning
this,
then,
if
it
truly.
D
C
B
Configure
a
weight
like
method
that
was
meant
to
suppress
the
exception
actually
being
thrown,
would
work
with
this
just
fine,
whereas
with
the
configure
weight
approach
it
would
have
had
to
have
been
written
as
an
extension
on
configure
to
waiters
right
yeah.
I
was
had
a
brief
moment
of
that.
The
two
tasks
were
independent
and
so
that
what
you.
B
B
C
B
Versus
blocking
is
that
the
existing
weight
methods
for
timeouts
return
a
bool
and
use
the
bool
to
indicate
whether
the
weight
timed
out
or
not.
But
that's
weird
here,
to
try
and
propagate
here.
That
here
is
weird
because
then
the
weight
async
method
ends
up
needing
to
return
a
task,
a
bool
which
is
very
confusing.
If
you
are
on
a
taskable,
for
example,
we
could
return
a
task
of
bool,
comma
t
results,
but
that's
harder
to
consume,
so
I'm
suggesting
it
just
be.
D
B
G
B
B
E
B
B
Span
into
the
waiter,
you
would
have
got
weight
async
with
the
token
in
the
timeout,
and
then
some
configuring
a
weight
thing
either
explicitly
named
for
suppression
of
throws
or
configure
a
weight
that
takes
an
enum
with
the
behavior
or
you
know,
we'd
be
back
to
that
discussion
about
controlling
the
actual
await,
whereas
these
were
really
controlling
things.
That
can
only
be
done
via
the
await,
whereas
these
are
things
that
can
be
done
not
just
for
weights.
A
B
B
A
B
Until
we
see
how
people
end
up
using
this
in
practice,
like
the
I'm,
I'm
concerned
that
we're
adding
yet
another,
this
invalidates
the
value
task.
Please
don't
touch
the
the
original
input
again.
The
fact
that
this
is
returning
the
the
this
in
some
cases
means.
Hopefully
people
won't
ever
go
back
and
look
at
the
previous
task,
but
it's
it's
a
concern
because
you
know
with
the
power
that
comes
with
high
value
test.
B
B
B
Yeah,
that
would
be
if
we
didn't
have
these
and
they
wanted
to
wait
on
a
value
task
with
a
cancellation
token
times.
You
know
time
span,
they
would
need
to
as
task
and
if
they
cared
about
eking
out
perf,
they
would
probably
first
have
that's
one
of
the
two
lines
I
mentioned.
The
other
line
would
be
if
not
completed
yeah.
B
B
B
Digital
complexity
of
actually
using
it
twice,
one
of
the
arguments
for
weight,
I
think,
was
there's
already
weight
methods
and
those
don't
exist
on
value
task.
Implementation,
wise,
they're,
really
just
convenience
methods,
whereas
the
ones
on
task
are,
you
know
a
hundred
lines
of
code
or
something,
whereas
the
ones
on
value
tasks
are
one
or
two
lines
of
code.
B
E
I
can,
I
guess,
is
miriam
here
nope.
This
is
just
inspired
by
today
we
have
an
api,
so
history
we
have
the
web
host
and
the
generic
host
the
generic
host
was
to
replace
the
web
host.
So
a
bunch
of
options
that
existed
on
the
web
host,
like
specifying
things
like
a
shutdown,
timeout
or
more
first
class
extension
methods
on
the
on
the
web
builder
in
the
generic
host.
E
E
A
E
G
A
E
E
I
think
there
was
no
confusion
there.
There
was
a
controversy
around
the
fact
that
potentially
some
streams
don't
support
zero
bite
reads,
and
I
guess,
support
in
this
case
means
it
would
robot.
That
seems
rare
and,
I
think,
for
the
most
part,
they're
kind
of
well.
I
think
I
think
season
two
actually
wrote
a
pretty
good
thing
on
this
on
a
different
issue,
where
they're
kind
of
three
kinds
of
streams-
ones
that
are
connected
ones
that
aren't
connected.
B
B
E
B
Think
I
think
it's
I
think
the
feature
is
fine.
The
only
feedback
I'd
have
is
wait
for
data
is
not
a
super
descriptive
name.
I
was
gonna,
have
the
exact
same
feedback?
It's
something
like
you
know,
delay.
I
don't
know
not
these
words
but
delay
allocation
until
data
available
or
something
long
and
terrible.
B
B
B
E
B
F
F
B
B
B
C
B
B
B
B
Or
defer
I,
like
I
don't
know
I
I
just
I
think
it's
you
know,
use
zero
byte
reads
it's
descriptive
of
what
it's
doing
why
there
may
be
a
problem
and
anything
else
that
we
feel
like
adding
behind
that
flag
is
now
possible
versus.
If
something
else
was
solved
by
the
same
solution,
we
need
a
new
name
for
it.
B
B
B
E
B
A
A
B
That's
fine!
I
I
don't
have
a
high
care.
I
just
want
to
make
sure
we
weren't
locking
ourselves
into
something
because
the
problem
with
allow
is
it
could
sound
like
it's
a
you're
you're
asking
whether
someone
is
allowed
to
call
into
the
stream
pipe
reader
with
to
do
a
zero
byte
read
instead
of
that
you're
describing
what
it
wants
to
do
to
the
stream
on
the
other
side
of
it
right.
E
F
F
E
B
B
E
E
E
And
there
is
there's,
there's
still
kind
of
one
thing
that
we
should
figure
out
after
this
whole
thing,
so
I
guess,
starting
from
the
beginning,
timer
has
a
couple
of
issues
or
yeah
quirks.
I
guess
that
that
are
there
in
in
the
wanted
four
listed
out
without
roots
itself,
withheld
timer
changes
can
timer,
callbacks
can
overlap.
E
E
Instead
of
doing
that,
you
await
this
wait
for
next
tick
method
and
it
will
just
yield
whenever
the
the
period
has
passed.
There
are
two
options
for
this.
There
is,
if
you
are
currently
running
the
continuation
and
other
ticks
kind
of
fire
along
that
time.
The
next
time
you
wait,
should
it
finish
immediately
or
should
it
wait
for
the
next
pick?
Basically,
if
you
miss
ticks,
do
you
get
to
observe
them
or
or
are
they
escaped?
I
think
that
could
be
an
option.
B
Does
that
make
sense,
it's
actually
there's
actually
sort
of
three
models.
Right.
There's,
let's
say
you
missed
seven
ticks.
Do
you?
Do
you
the
next
time
you
go
back?
Do
you
immediately
get
notified
and
that
consumes
all
seven?
Do
you
immediately
get
notified
and
that
consumes
just
one
of
the
seven
got
it.
C
B
E
E
B
B
C
B
B
B
E
B
E
E
E
E
H
B
System,
timer's
timer
is
just
a
wrapper
around
the
system.
Threading
timer,
that
adds
some
integration
with.
Basically
con
synchronization
context
allows
you
to
specify
it
explicitly.
There's
system
windows
forms
timer
that
allows
you
to
or
a
component
model
timer
or
something
that
allows
you
to
put
one
onto
a
windows
forms
form.
This
wpf
has
a
dispatcher
timer.
They
all
end
up.
Wrapping
threading
timer
under
the
covers.
E
E
But
yeah,
it's
pretty
simple
usage.
You
do
a
loop
and
you
wait
for
next
async
and
it
returns
task
of
bull,
which
is
interesting
because
it
avoids
you
having
to
write
that
well
true
logic,
which
I
think
is
gross.
I
guess
the
question
is:
how
do
you
stop
the
loop
from
running
in
this
case?
And
I
guess
there's
there's
two
modes
that
that
exists
today.
B
G
B
E
Yeah
yeah,
I
know
one
other
thing
about
the
pattern
here
for
usage.
Is
that
that
I
think,
is
a
big
deal.
Typically,
when
you
have
timers
that
fire
with
a
callback,
you
have
to
figure
out
the
disposal
and
ends
up
being
a
bit
tricky
in
this
model.
You
kind
of
dispose,
naturally,
where,
where
the
primer
is
used,
so
you
can
see
that
the
weight
using
bar
timer
equals
asynchronous
blah
and
the
and
the
call
to
cancel
our
stop
will
halt
the
loop,
but
the
timer
gets
disposed
where
it's
being
consumed.
E
B
H
H
E
E
F
E
E
G
E
E
B
B
C
B
The
main
value
of
this
api
is
for
where
you
you
want
to
be
able
to
be
notified
of
the
next
next
tick
that
started
the
the
moment,
the
previous
tick
fired,
because
that
helps
avoid
the
usage
problems
of
I'm
running
the
response
and
now
another
handler
for
it
is
running
in
parallel
to
me.
And
how
do
you
deal
with
those
you
know
overlapping
things
this?
This
type
would
help
to
avoid
that
with
this
usage
consumption,
because
there's
no
way
to
have
multiple
running
in
parallel,
because
it's
just
one
sequential
async,
loop
right.
B
Either
second
or
third,
first
or
so,
I
don't
know
what
the
numbers
were.
It's
a
vote
for
the
one
that
is
for
the
the
mode
being
defaulting
to
keeping
track
to
starting
the
period
immediately
right,
whether
or
not
it
keeps
track
of
how
many
times
it's
fired,
or
whether
it
only
keeps
track
of
whether
it
has
fired
right.
Yeah.
B
Yeah,
if
this
is
something
like
you
know,
akin
to
garbage
collection
right,
so
you're
you're,
moving
over
your
temp
files
or
moving
over
compacting,
some
storage
or
whatever
you
wouldn't
want
it
to
just
fire
seven
times
in
a
row
if
one
of
your
things
took
seven
times
longer
than
it
should
have
like.
So
I
I
would
say
that
the
default
mode
would
be
that
it
has.
B
H
Should
should
this
have
a
should
this
basically
mirror
how
event
weight
handle
works,
except
with
async?
Then,
because
it
sounds
like
that's.
The
three
modes
we
want
is
basically
what
event
handle
event
weight
handle
does,
but
with
a
proper
await
support,
whereas
waitable
timer
doesn't
have
that
for
those.
H
H
B
C
B
That
these
map
directly,
because
the
the
manual
one
for
me,
would
be
akin
to
saying
don't
start
your
next
period.
Until
I
take
some
explicit
action
and
the
auto
one
would
be
a
kid
like,
you
know
either
calling
I
like
calling
resume
or
something
and
the
auto
one
would
be
akin
to
saying
automatically
started
again
the
next
time.
I
call
wait
for
next.
Take
a
sync
both
of
those
would
seem
to
miss
the
keep
track
of
whether
there's
been
something
that's
happened
in
the
interim,
allowing
it
complete
automatically
and
then
sort
of
reset.
H
D
H
E
E
B
So
that
that
would
be
valid,
I
don't
think
that's
what
tanner
was
saying.
I
think
the
bull
that
tanner
was
describing
was
between
the
right,
so
we
actually
need
to
number
these
correctly
yeah
I
mean,
I
don't
think
it
will
be
a
boolean.
I
think
it'll
be
an
enum,
because
we've
already
talked
about
more
than
two.
B
H
Right,
the
third
mode
is
basically
it
I
I
guess
it's
basically
auto,
but
instead
it
it,
it
doesn't
stop
one
once
one
happens,
it
doesn't
just
change
it
from
false
to
true.
It
changes
it
from
zero
to
one
and
then
increments
it
every
time
it
gets
set.
That
way
you
can
track
how
many
times
it's
occurred.
B
And
I
think
in
my
mind,
the
the
first
mode,
the
one
where
it's
it
resets
the
it
starts
again
the
moment
you
call
wait
for
next.
Take
a
sync
like
that's
when
the
period
ticks
off,
there's
value
in
that,
but
I'm
not
sure
there's
a
lot.
There's
enough
value
over
tat,
wait
test.delay
for
it
to
be
worthwhile.
C
E
E
B
Yep,
this
is
kind
of
a
weird
reference,
but
javascript
has
set
interval
that
is
very,
very
commonly
used.
It's
used
for
ui,
so
that's
different,
but
I
do
wonder
what
it
does
when
ticks
are
skipped.
Of
course,
it
would
be
weird
for
ticks
to
be
skipped
in
javascript.
Well,
not
necessarily
weird,
but
not
common,
but
it
certainly
could
happen.
B
H
B
H
The
browser
so
so
does
there
actually
need
to
be
three
modes
and
not
two
where,
because
it
sounds
like
the
third
mode,
it
sounds
like
the
two
modes
are
the
the
auto
the
manual
and
then
this
third
mode
is
really
just
ref
counting
how
many
times
it's
triggered,
which
you
could
imagine
just
happens
automatically
in
any
scenario
and
there's
an
ex
the
the
method
for
reset
has
an
option
for.
Do
I
reset
back
to
zero,
or
do
I
decrement
by
one
wait
who's
calling
reset?
B
C
C
B
Weight
will
complete
immediately
if
there
has
been
anything
and
you
have
and
it
needs
to
play
catch
up,
and
then
I
guess
the
fourth
mode
is
the
weight
only
completes
on
a
heartbeat
and
if
you
weren't
listening
when
the
heart
beat
it
skips
the
thing.
So
those
are
the
four
different
behaviors
we've
described.
Yeah
four
four
sounds
very,
not
useful.
E
H
B
C
B
B
G
B
Because
I
assumed
that
stop
was
you
could?
If
the
timer
was
on
a
field,
someone
could
call
stop,
and
now
the
next
call
to
wait
for
next
async
will
return
false.
That's
true
right.
If
stop
stop
is
basically
transition.
This
thing
to
never
firing
again
such
that
all
subsequent
wait
for
next
take
async's
return,
return.
False
then
yeah.
It
can't
be
used
in
that
matter.
Yeah
yeah
pause,
but.
E
F
E
B
Right
as
a
field,
it
would
be
nice
that
you
just
get
to
say
like
open,
stop
the
timer
yeah,
and
so
that
just
means
that,
if
you
want
the,
I
want
you
to
always
take
half
a
second
from
the
time.
I
finish
this
iteration
to
the
time
that
I
start
the
next
one
so
that
it's
measuring
down
to
up.
Instead
of
up
to
up,
then
we
would
need
another
method
for
that,
where
pause
is
the
best
that
I
came
up
with
sorry
what
jeremy?
What
would
that
do?
B
B
B
B
B
Just
I'm
summarizing
in
my
head
well
vocally
as
well
as
for
the
cancellation
token
versus
stop.
I
think
both
is
fine.
I
view
them
largely
orthogonally,
like
the
stop,
is
they're
different
modes
of
interaction.
I
think
the
cancellation
token
is
one
where
you're
trying
to
tear
down
a
whole
bunch
of
stuff.
At
the
same
time,
you
want
everything
to
compose
so
use
a
cancellation
token
for
that
and
the
the
bool
is,
you
know
it's
just
I
want
to
while
await
and
break
out
of
it
kind
of
like
an
eye.
Enumerable
yep.
E
B
E
B
Maybe
yeah,
I
think
that
there
are
a
lot
of
people
who
could
look
at
the
async
and
umable
and
be
like
oh,
this
is
clever
or
that
they
would
write
it
of
like.
Oh,
this
is
clever,
but
I
think
that
the
class
gives
much
better
intent
and
allows
for
a
clean
way
of
just
of
doing
stopping
and
discussing
the
other
kinds
of
behaviors
it
could
have
in
the
future.
B
E
E
Yeah,
this
problem
is
one
of
the
as
a
as
a
like
platform
can't
really
solve
with
the
documentation.
The
one
and
goal
is
called
ticker.
If
that
helps,
we
could
call
it
the
same
thing
because
it
takes
more
than
once.
I
guess,
but
I
think
we're
gonna
have
this
problem,
even
if
you
call
it
something
that
seems
reasonable,
just
because
the
dots
will
all
point
to
timer
and
then
we'll
have
a
new
version
m
timer,
modern
timer.
B
Yeah,
like
I
understand,
and
I
mean
it
makes
sense
on
isolation
yeah.
I
wonder
if
using
something
like
interval
or
repeated,
or
I
don't
know
what
what
what
the
common
adjective
we
use
here
for
repeating
timers
is,
but
if
we
perhaps
if
we
include
an
adjective
like
that,
so
it's
like
async
interval
timer.
That
might
be
a
little
clearer
about
specifically
what
the
intent
here
is,
or
a
moving
timer
or
timer
loop
or
something
periodic
periodic
timer.
B
G
B
H
E
B
B
B
B
E
B
B
B
E
B
E
B
E
B
E
B
E
E
I
would
write
that
by.
I
would
have
to
write
an
async
method
and
I
would
call
it
directly
from
my
ui
thread
right
that
would
work
yes,
that
works
fine,
but
I
think
people
end
up
task.running
long,
running
async
methods
by
but
just
by
habit
by
pattern
right
to
offload
from
the
from
the
current
thread,
even
though
the
first
await
would
yield
use
that
that
code.
I
think
people
end
up
running
just
by
habit
and.
G
B
Yeah,
I
I
guess
I'm
I'm
struggling
to
understand.
I
think
I
think
what
you're
saying
is
the
problem.
Is
people
are
going
to
write
code
that
more
complicated
code
because
they
think
they
have
to
and
that
more
complicated
code
is
going
to
not
do
is
going
to
make
them
write
further
complicated
code
to
do
what
they
should
have
just
been
doing
in
the
first
place?
Yeah
yeah,
I
think
that's
an
education
issue.
B
E
A
E
B
E
B
B
C
B
E
I
just
think
people
don't
like
if
you,
if
you
look
at
the
cool
people,
end
up
writing
when,
when
you're
kind
of
trying
to
do
a
thing
in
the
background,
but
you
have
to
kind
of
start
it
from
your
current
synchronous
code
task.
Is
your
natural
go-to
for
kind
of?
Like
start
this
thing
over
here
and
let
me
continue,
people
rarely
call
the
message
and
let
it
yield
asynchronously
just
because,
like
maybe
it
would,
maybe
it
may
end
up
blocking
the
current
thread
for
longer
than
needed.
E
Like
imagine,
the
first
tick
fired
and
it
it
ran
on
the
ui
thread,
and
you
didn't
want
that.
Your
first
reaction
to
fix
it,
it's
a
task,
run
and
then
you've
lost
the
same
context
and,
and
it
isn't
like
a
it,
isn't
a
thing
we
can
just
solve
it's
more
like.
Should
we
should?
We
have
a
a
pattern,
because
this
will
become
more
common
with
what
we
have
more.
A
Also,
like
I'm
still
struggling,
why,
if
I'm
building
a
ui
app,
why
would
I
use
this
new
timer?
Why
would
I
not
just
use
the
existing
timers
that
are
effectively
already
designed
for
the
ui
stacks,
because
I
mean
it
seems
like
if
I
would
consume
this
time?
I
would
most
like
to
do
it
indirectly
by
some
other
api,
in
which
case
that
other
api
happens
to
use
the
timer
under
the
covers,
and
if
that
other
component
happens,
to
be
optimized
for
the
ui,
it
will
take
care
of.
You
know
calling
callbacks
on
the
ui
thread.
E
I
guess
so
we
we
shouldn't,
I
guess
so
much
more
time
on
it,
but
I
guess
the
last
point
is
that's
true
emolly
and
we
have
this
patchy
timer
and
the
winform
timer,
but
I
think
like.net
basically
did
a
good
job
of
abstracting.
The
whole
sync
context
thing
with
async
await
and
that
pattern
is,
I
think,
easier
to
grok
than
having
to
do
dispatcher
dot
whatever.
But
I
could
be
wrong.
I
don't
know.
A
Well,
it
depends
on
how
you
use
it
right
I
mean
the
idiomatic
use
of
these
timers
is
not
to
call
methods,
but
the
idiomatic
uses
you
instantiate
them,
and
then
you
subscribe
to
an
event
and
that
that
one
is
called
in
some
interval
right
so
by
the
time
you're
running
you're
already
on
the
ui
thread.
So
you
don't
have
to
talk,
start
run
to
offload
it,
and
you
also
don't
have
to
do
anything
and
then
within
that.
But
if.
D
E
A
Yeah
I
mean
I
guess
I
mean
to
steven's
point
right.
I'm
still
somewhat
lost
what
you
think.
Idiomatic
code
in
the
ui
looks
like,
because
I
think
I
buy
the
argument
that
if
you
want
to
do
something
that
is
potentially
you
know
involving
a
weight
that
might
be
expensive
and
you
go
back
and
forth.
People
might
tax
run
that,
but
the
people
who
do
that
they
kind
of
know.
A
You
write
your
code
and
then
you
cross
your
fingers.
If
nothing
bad
happens
right
and
that's
probably
what
90
of
people
do
in
winforms
like
or
wpf
for
that
matter
or
you're
doing
something
back-end
related,
in
which
case
you
know,
somebody
else
encapsulates
this
thing
makes
it
ui
nicely
and
then
has
some
events
that
automatically
run
the
ui
to
it.
So
you
can
wire
it
up
without
breaking
your
finger
like
I'm,
I'm
somewhat
like
you
know,
I'm
not
trying
to
say
like
this
is
not
used
from
the
ui.
I.
A
A
E
D
B
E
E
A
G
B
E
A
That's
what
I
thought
and
then
I
think
the
other
thing
we
said
is
this
like
three
theoretical
modes,
and
we
said
we
only
need
one
of
them
and
I
think
the
one
we
said
we
want
to
have
is
the
one
it
should
complete
immediately
for
each
period
that
was
missed,
but
only
once
right.
It
wouldn't
fire
for
every
single
period.
That
was
that
was
fixed.
That
was.
B
We
probably
want
to
rename
the
constructor
to
match
the
type,
so
it
compiles
seems
like
a
reasonable
thing.
Yeah,
it's
very
nitpicky.
I
have
often
wished
that
c.
Sharp
the
language
allowed,
what
we
just
call
it
in
il
and
you
just
named
it
dot
c
tort
that
way
you
could
copy
and
paste
with
yeah
more
easily
but
yeah
whatever.
B
F
A
F
Lookups,
when
accessing
struct
values
in
dictionaries,
so
for
today,
both
of
those
patterns
require
like
double
lookups
and
in
case
of
structs.
It's
copied
away
and
trying
to
get
the
the
value.
So
the
three
methods
proposed
are
on
collections,
marshall,
which
is
a
unsafe
class
that
provides
methods
success
like
data
representations
of
collections,
so
the
first
one
and
they
differ
in
terms
of
how
they
respond
when
the
key
is
not
found
in
dictionary.
F
The
upper
part
is
just
like
background
reading,
sorry,
so
just
yeah
just
a
little
down.
I
can
look
here,
but
just
so
well
on
this
on
same
page,
okay,
so
yeah
the
first
one
gets
value.
You
pass
the
key
and
then
it
throws
the
key
not
found
exception.
If
the
key
is
not
in
dictionary,
the
next
one
try
get
value
ref,
so
this
one
will
return
will
announce
to
see
if
it
exists
or
not.
F
C
F
C
F
Yeah,
that's
correct,
not
extension
methods
with
acceleration
methods
will
be
able
to
provide
the
same
sort
of
pattern
for
get
our
ad,
but
it
wouldn't
be
any
more
performant
because
we
don't
have
access
to
non-public
service
area,
but
that
was
considered
as
well
I'll
talk
about
that
later
later.
On.
B
B
B
H
B
Like
really
my
my
iffyness
on
it
is
that
now
we
have
the
try
pattern
and
the
ref
return
try
pattern
and
I
I
would
like
to
avoid
two
patterns.
If
we
can
what's
the
reason
for
not
just
for
getting
rid
of,
try
get
value
ref
and
having
just
an
out
bool
on
get
value
ref.
Is
it
that
much
more
overhead
that
we're
concerned
it's
going
to
impact
that
fast
path
or
like?
Why
have
one
that
throws
an
exception
at
all.
F
Yeah
I'd
argue,
it's
perhaps
not
necessary
to
have
one
that
throws
the
exception.
I
guess
it's
just.
It
was
just
options
as
far
as
like
what
the
possibilities
are
about
these
sage
patterns.
Maybe
there's
some
scenarios
where
you
want
an
exception,
but
that
has
some
costs,
so
it's
probably
not
the
best.
I.
B
D
B
A
A
F
You
you
expect
the
key
to
be
there
and
it's
an
exception
to
it.
It's
just
a
value.
It's
just
a
question
of
how
often
that
happens
and
if
that's
like
a
primary
scenario,
I
think
from
the
discussions.
Most
people
are
leaning
toward
the
last
one
as
like
what
is
desired,
like
especially
in
the
struct
case,
just
create
default,
and
then
I
can
modify
it.
F
A
H
They're
they're
for
extremely
performance,
oriented
places
where
you
basically
want
a
span,
but
can't
get
a
span,
so
I
don't
think
we
want
to
do
delegate
or
anything
else.
That
can
add
those
overheads,
because
when
you,
when
you
get
down
to
cases
like
these,
like
just
like,
where
we
added
list
as
span,
you
are
likely
close
to
counting
cycles
for
some
of
your
algorithms.
B
H
B
B
Right
so
the
last
one
is:
I
want
this
bucket
to
exist,
but
tell
me
if
you
just
had
to
initialize
it
and
then
the
other
two
espec,
if
we
just
get
rid
of
the
try
on
the
middle
one
like
get
rid
of
the
word,
try
but
keep
the
method
as
described
the
those
are
give
me
the
thing,
but
don't
allocate
like
don't
cause
a
any
sort
of
re-bucketing
to
have
to
happen.
If
it's
not
there.
B
H
H
B
H
F
H
Places
in
dogs,
not
necessarily
in
the
bcl
but
other
places
where
the
tri
pattern
does
not
return
bool
it
returns,
for
example,
a
class
where
null
is
does
not
exist.
It's
it's
a
tri
pattern
that
does
exist
in
the
ecosystem,
and
that
does
occur,
especially
in
performance
oriented
code.
Do
we
have
any
of
those
I'm
not
sure
if
we
ourselves
have
them,
but
I
don't
think
this
is
too
far
of
a
concept
from
tri-get.
B
From
a
patterns
purity
perspective,
I
definitely
would
prefer
that
we
not
use
the
word.
Try
whether
it
be
we
it
just
is,
and
I'm
doing
a
thing
and
you
have
to
measure
my
output
or
that
it's
we
come
up
with
a
word.
That's
not
try.
Yeah,
I
mean
it
almost
feels
like
it
should
be
unsafe,
get
value
ref.
If
we
have
to
compare
against.
Unfortunately,.
H
B
A
Yeah,
I
mean
I
kind
of
agree
with
that,
because
the
thing
is
it's:
on
collection,
marshall,
it's
not
an
extension
method.
It's
in
the
interval
services
namespace.
So
I
mean
I
can
go
with
almost
anything,
I'm
even
okay
with
you
know,
going
try
get
radiograph
where
we
can
go
get
radio
ref
on
my
ref
like
I.
I
don't
think
it
matters
realistically.
B
Yeah,
I'm
just
I'm
really
just
concerned
that
we
have
I'm
aware
that
the
ecosystem
sometimes
uses
tri,
for
if
I
return
null,
that
meant
it
failed,
but
that
we
do
have
our
our
you
know,
guidelines
and
the
guidelines.
We
have
everything
that
talks
about
a
try
is
a
bull
returning,
emitter
and
I'm
concerned
of
well.
H
It's
also
a
case
where
I
would
argue
that
the
that
us
returning
bool
for
reference
types
is
wrong
in
not
performant,
and
if
we
could
go
back
and
change
it,
I
would
have
argued-
and
you
know
I
wasn't
eight
years
old
at
the
time
I
would
have
argued
we
should
have
had
anything
that
returns
a
reference
type
return
t
and
the
tri
pattern
probably
should
have
returned
nullable.
Instead.
B
B
B
B
H
B
H
A
Yeah,
I
think,
to
just
pop
up
right,
so
I
mean
it
doesn't
really
matter
what
the
better
concept
would
have
been
20
years
ago,
because
you
know
the
problem.
Is
we
shipped
that
pattern
20
years
ago
and
that's
used
pervasively
right
so
now
the
argument
is
more.
You
know
what
is
more
consistent
right
and
we
argue
for
consistency,
because
it's
less
cognitive
load
right
so
like
it's
like,
I
I'm
inclined
to
agree
with
tanner
that
you
know
you
know.
A
C
A
B
Mean
yeah,
I'm
just
opposed
to
the
word.
Try
we
have
a
pattern
and
if
we
want
a
new
pattern,
it
needs
a
new
name.
I
like
get
value
or
null
ref
that
for
a
couple
reasons
one
it's
very
clearly
saying
what
it's
doing.
Two:
it
avoids
the
try
issue.
Three.
It
tells
you
exactly
what
you
need
to
compare
to
unsafe
dot
null
ref,
four
it
matches
with
the
or
in
the
next
method.
So
it's
consistent
with
that
and
five
it
matches
with
what
link
uses
first
or
default.
B
B
E
B
E
A
F
B
H
B
A
C
A
H
A
C
B
Clear,
it's
really
it's
get
or
add
value
ref
or
I
guess
get
her
create
value
right.
I
don't
know
because
get
her
get
her
ad
flash
get
or
create
is
what
we're
really
doing,
and
then
you
get
the
value
ref
but
yeah.
I
think
steve
had
a
reasonable
name
somewhere
in
the
middle
here
yeah.
Can
somebody
repeat
that.
A
B
B
A
H
H
H
A
B
B
Well,
but
the
the
or
add
has
to
go,
do
work
and
unsorted
dictionary.
It
has
to
go
resort
things.
However,
it
does
that
okay,
yeah,
fair,
the
the
peaking
of
just
getting
the
value
ref
is
probably
if
we
could
easily
add
it.
If
we
wanted
to
the
the
getter
add
is
specifically
the
one
that
makes
me
think
we
would
hold
back
on
on
sort
of
dictionary
until
we
had
a
justified
use
case.