►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
B
So
the
idea
is
to
suggest
to
detect
cases
where
the
user
using
two
over
to
lower
and
just
change
it
to
upper
required
to
lower
invariant.
B
B
I
think
I
left
a
few
examples.
Use
this
example
below.
C
D
C
E
C
Ask
my
standard
question:
how
is
that
different
from
obsoleting
these
apis,
if
you're
in
a
winforms
application
or
other
ui
based
application
like
you're,
going
to
want
to
call
this
most
of
the
time?
That's
that's
the
problem.
I
think
when
you're
displaying
something
to
the
user
when
you're
intending
to
operate
in
that
user's
native
language,
there's
you
you
generally
want
these
apis
to
be
culture.
Aware!
That's!
Why
string
was
culture
aware
to
begin
with
because
it
was
meant
for
these.
C
C
F
A
A
No,
but
like
it's
kind
of
like
yeah
yeah,
I
guess
that's
fair,
but
then
yeah.
I
think
if
you
still
have
the
api
and
you
still
call
the
api
in
certain
scenarios
or
imagine
scripting
right
in
scripting,
it
would
actually
squiggle
it
right,
but
you're
also
not
very
likely
to
care
in
scripting
either
right.
C
C
A
It
I
mean
that's
an
interesting
question
right,
so
one
thing
we
could
decide
to
say
I
don't
know
how
much
metadata
we
have,
but
you
could,
for
example,
say
based
on
project
type.
We
only
turn
it
on
when
you're
in
a
class
library
context,
for
example,
because
well
most
class
libraries
probably
don't
know
which
context
they're
running
in
right
and
then
in
this
case
you
would
say
well,
please
please
make
a
decision
which
culture
you
want
to
use,
but
if
you're
in
a
ui
or
if
you're
in
an
exe
project,
we
just
don't
care.
A
A
D
Yeah,
it's
just
it
just
needs
to
be
a
warning
can
be
just
like
the
info.
I
mean
because
because
I'm
seeing
I
mean
the
main
goal
here
is,
if
somebody
doesn't
understand
the
behavior
of
the
two
other
two
lower,
while
not
passing
any
parameter,
they
can
shoot
themselves,
and
this
is
the
case
that
we
need
to
help
them
obsolete
yeah.
I
mean
like
I,
I
wouldn't
mind
obsolete
if
you
need
to
yeah,
but
but
what
I'm
hearing
that
other
people
is
is
using
it
and
they
understand
it.
D
A
E
C
But
yeah,
I
think
that
there
are
a
class
of
people
who
would
want
to
say
that
in
a
particular
project
they
don't
want
any
of
the
weight.
Was
this
culture
aware
or
not
calls
and
that
they
either
wanted
to
be
explicit
or
that
they
really
wanted
everything
to
be
invariant
or
really
wanted
everything
to
be
culture
and
sure
making
a
fixer
for
them?
Is
nice
all
right?
C
C
G
C
C
Should
we
just
have
a
switch
for
the
entire
application,
which
says
all
of
the
by
default
culture
where
apis
are
now
ordinal
or
invariant,
and
if
you
want
the
old
behaviors
just
to
flip
the
switch
back
on?
Well,
I
wasn't
talking
about
changing
the
behavior.
I
was
talking
about
flagging
things
beyond
too
low
or
too
upper,
as
maybe
you
want
to
call
a
different
method
yeah.
I
guess
it
would
just
be
a
different
way
of
approaching
the
same
problem
so
that
you
don't
need
to
create
analyzer
after
analyzer
after
analyzer.
A
A
So
it's
the
basis.
Does
that
mean
so
because
I
mean
you
know
in
my
class
libraries
I
would
actually
like,
if
I
could,
just
you
know,
control
dot
and
convert
my
two
upper
to
you
know
two
upper
invariant
or
something
to
to
avoid
the
typing
right
or
even
be
able
to
do
a
fix
all
but
like
it
seems
like
in
order
for
me
to
have
that
experience,
you
would
have
to
have
an
analyzer
that
at
least
reports
it
with
a
you
know
very
low
severity
right.
A
C
C
A
A
I
think
we're
adding
value,
but
I
am
somewhat
hesitant
to
say,
like
you
know,
we
generate
a
warning
and
project
types
where
it
literally
adds
zero
expressiveness,
because
all
you
do
is
turn
people
off
from
the
analyzers
right
if
you're,
building
a
wpf
app
and
it
flex
too,
lower
you're,
like
I
don't
care
man
like
it's
totally
fine
here,
and
so
I
think,
unless
we
can
scope
it
I'd,
you
know
I
would
consider
the
fixer,
but
not
the
warning.
Basically.
A
Yes,
that
would
basically
be
that
right
I
mean
you
could
also
argue
that
you
know
info
may
make
it
more
discoverable
that
you
can
at
least
turn
it
on
if
you
wanted
to
in
your
project
time,
but
I'm
not
sure
people
care
enough
to
do
that.
A
Yeah
I
mean
to
steven's
earlier
point.
It
does
seem
like
something
we
maybe
want
to
have
a
holistic
review
on
like
how
much
do
we
care
about
the
you
know,
culture,
specific
apis
and
what
you
know.
How
do
we
want
to
promote
this
right?
Because
I
I
do
think
if
we
could
scope
it
by
project
type,
it
might
be
actually
more
useful,
but
then
it's
probably
also
not
enough
to
just
scope
it
on
on
either
the
dll
project
or
not,
because
not
all
the
other
projects
are
created
the
same
right.
A
Some
things
might
be
user
controlled.
Some
things
might
be
test
projects
right,
in
which
case
you
probably
also
don't
want
to
have
a
turn
on
by
default,
and
I
don't
know
whether
we
have
even
the
right
information
in
ms
built
to
even
identify
what
kind
of
thing
you're
building
really.
G
Warnings
that
a
library
could
include
and
that
the
asp
web
types
would
turn
on
by
or
would
include
by
default.
I
don't
know
if
our
sdks
do
that,
but
that's
the
best
that
I
can
imagine
with
the
tech
that
I
understand.
A
H
C
The
default
visibility
should
be
hidden
that
there
should
be
two
fixers
or
two
suggested
fixes,
rather
one
for
go
to
the
invariant
and
another
four
pass
culture
info
dot,
current
culture,
just
to
make
all
the
all
your
warnings
go
away
and
then
the
as
a
follow-up
nice
to
have
as
a
for
a
pm
email.
Maybe
we
should
look
and
see
if
there's
a
way
that
we
can
get
analyzers
opted
in
by
default,
based
on
project.
A
A
H
A
D
Yeah,
so
this
is
regarding
logging,
so
in
dot
net
5
we
have
allowed
the
login
to
opt
in
to
to
produce
like
logging,
some
tracing
context,
information
inside
the
logging
scopes
so
the
way
to
to
opt
in
I
mean
to
to
have
this
activity
tracking
options.
I
mean
to
add
it
to
the
to
the
builder
login
builder,
and
you
enable
this
and
you
will
get
this
inside
the
box.
I
mean
like
span
id,
trace
id
parent
id
interested
and
and
trace
flat.
D
So
the
ask
here
is
people
need
to
add
some
more
stuff
to
opt
into
more
stuff.
If
you
need
to
this
is
the
tags
and
the
baggage?
So
basically,
the
ask
here
is
just
to
add
this
extra
true
values
and
handle
this
in
the
score,
but
somebody
opted
into
for
this
tags
of
baggage.
So
we'll
start
we'll
start
adding.
I
mean
like
producing
this.
D
C
D
C
A
A
F
Yeah
I'll
take
this
one,
so
I
found
this
just
by
going
through
and
annotating
different
flexion
apis,
and
so
the
issue
here
is
when
you're
using
reflection
emit
to
build
up
an
enum.
A
No,
I
mean
it
makes
perfect
sense.
I
think,
starting
with
net
standard
two,
when
we
basically
gave
up
on
the
reflection
split,
the
goal
was
to
add
all
the
apis
back
and
then
with,
I
think,
with
three
with
two
one.
I
think
we
tried
to
add
back
all
the
perfection
emit
so
yeah.
That
was
the
intent,
but
we
clearly
overlooked
this
api
so
makes
perfect
sense
to
me.
F
F
I
I
think
so
like
we,
we
explicitly
have
it
in
the
api
compat
baselines
and
I
thought
I'll
go
back
and
look
real
quick,
but
I
thought
this
was
the
only
one
I
saw
in
api
baselines.
A
A
F
It
wasn't
overloads
it's
just
straight
up
properties
that
aren't
there
I'll
paste
the
link
in
the
chat.
A
A
A
A
A
F
A
H
C
Yeah
in
in
one
o,
we
were
okay
with
things
being
in
the
input,
but
not
in
the
ref,
and
then
I
think
we
missed
shipping.
We
missed
putting
a
couple
things
that
were
supposed
to
be
public
as
public
and
then
I
feel
like
it
was
eric
st
john
changed
the
thing
to
to
produce
the
also
validate
the
other
direction
that
if
it's
public
in
the
impul,
it
should
be
public
in
the
ref
or
you
have
to
suppress.
A
A
Okay,
then,
how
about
this
I'll
just
say
it's
the
proof,
but
I
added
a
comment
that
we
should
also
you
know
either
document
or
address
the
other
violations
in
the
baseline
file,
because
it
seems
like
whatever
is
left
in
their
baseline
file,
at
least
for
me.
It's
not
clear
what
some
of
these
things
exist,
that
you
know
that
might
be
bugs,
or
that
might
be
because
it's
by
design,
but
we
will
probably
have
the
question
in
the
future
as
well
by
the
damn
it.
F
A
A
Actually
did
I
actually
market
the
proof,
or
did
I
just?
I
think
I
did
right
yeah.
I
did
allow
using
support
drive
after
attribute
on
interfaces.
Yes,
I
can
probably
talk
to
that
one.
A
So
we
added
those
attributes
to
annotate
version
specific
apis,
and
the
thing
is
that
on
the
xamarin
side,
they
also
have
interfaces
that
are
part
of
the
ios
bindings,
and
so
they
map
them
to
interfaces,
because
that's
the
most
logical
thing
to
map
some
of
the
you
know,
mac
specific
apis
to
so
it
makes
sense
to
actually
put
a
marker
on
the
interface
itself.
That
says
this
is
a
platform
specific
thing.
A
The
reason
we
haven't
done
this
initially
is
because
our
rationale
was
an
interface
like
there
is
no
like
I
mean
by
definition,
there's
no
code
behind
an
interface
so
like
that
can't
be
platform
specific,
but
because
of
the
way
the
bindings
work,
it
would
be
beneficial
for
them
if
they
could
mark
the
interface
itself
now,
just
because
we
allow
that
doesn't
mean
we
should
use
it
everywhere
else,
but
I
also
don't
feel
like
that
should
be
disallowed.
A
A
Yeah,
so
I
don't
exactly
know
how
you
knew
them
up.
I
I
assume
you
don't
use
them
up,
you
just
get
them
from
somewhere
else
and
then,
when
you
use
them,
you
know
you
want
to
have
checking
that
says.
Well,
you
can't
use
that
guy
because
you're
running
on
the
wrong
platform
right,
and
so
you
can't
do
that
unless
you
are
able
to
put
the
app
the
attribute
on
the
interface
itself.
I
It
might
also
depend
on
if
the
interface
is
annotated
with
the
special
com
attributes
that
allow
you
to
new,
open
interface
like
you
do
for
office.
C
A
Yeah,
it's
kind
of
the
same
with
abstract
base
types
right
like
there
might
be
abstract
base
types
where
it
makes
sense
to
add
an
attribute
and
then
there's
others
where
it
wouldn't.
So
it's
probably
like
one
of
those
ways
like
yeah.
We
allow
it
on
the
attribute,
but
it
doesn't
mean
you
should
apply
it
on
every
on
every
interface.
C
C
I
would
vote
for
the
latter,
because
an
implementation
can
do
more
than
one
thing,
and
it
would
be
weird
to
say
that
the
implementation
itself
doesn't
work
on.
You
know
some
os,
so
maybe
I
have
a
class
which
is
I
windows,
interface
and
imac
interface
right,
my
class
works.
It's
just.
One
of
the
two
interfaces
is
not
relevant
to
you,
yeah,
that's
the
behavior
that
I
want
as
well.
I
was
just
making
sure
that
we
were
saying
that
this
belonged
to
the
interface
and
not
flowed
with
the
type
hierarchy.
D
C
C
Another
way
to
think
of
it
is
say
that
I
knew
up
a
list
of
t
and
then
start
using
methods
like
add,
remove
count
so
on,
like
I'm,
not
actually
using.
I
list
of
t
I'm
using
list
of
t.
It's
just
those
methods
happen
to
implicitly
implement
the
interface,
but
from
the
caller's
perspective,
like
I'm,
not
touching
the
interface
at
all.
C
A
I
mean
intuitively.
I
would
say
that
if
you
mark
an
interface
with
this
attribute,
the
analyzer
should
probably
warn
when
you
derive
from
that
or
when
you
implement
the
interface
and
don't
have
a
restriction
on
the
type
itself
now,
if,
if
that
is
by
design,
I
think
it's
okay
to
suppress,
but
I
have
a
hard
time
thinking
of
cases
where
that
would
be
useful,
because
it
seems
like
at
that
point
you're
you're
not
really
consistent
with
what
you're
saying.
A
But
it
also
seems
to
me
that
in
the
cases
where
you
would
want
to
apply
the
attribute,
you
probably
don't
have
any
real
public
types
implementing
that
interface.
So
it's
probably
a
non-concern,
but
I
think
at
least
for
me
it
would
make
sense
to
say
if
you
implement
this
interface,
you
have
to
mark
yourself
as
being
platform
specific,
at
least
for
the
version
number
or
a
higher
version
number
right.
C
D
C
Risk
my
my
original
comment
was
was
more
along
the
lines
of
like
if,
if
I'm
using
an
app,
if
I'm
as
a
caller
calling
into
a
types
regular
instance,
members
who
also
happened
to
implement
an
interface
which
was
marked
as
not
supported
like
I
don't
want
the
analyzer
or
anything
else
to
have
to
go
out
of
its
way
to
figure
out
like
well.
Did
this
method
actually
like
happen
to
also
fit
into
this
v
table
slot
blah
blah,
because
that's
just
creating
unnecessary
work
for
something
that
doesn't
add
value
to
me
as
a
caller.
I
So
I'd
think
that,
from
the
perspective
of
should
it
flow
to
the
implementer
of
the
interface,
I
don't
think
it
should,
because
you
could
imagine
that
a
type
supports
an
interface
with
explicit
checks
in
its
own
implementation
that
allows
it
to
handle
both
unix
and
windows
simultaneously.
For
example,.
I
A
It
would
be
weird
if
we
mark
an
interface,
but
then
don't
mark
the
implementations,
because
that's
probably
a
bug
because,
as
levi
said,
depending
on
how
the
call
sites
look
like
the
compiler
may
not
see
the
api
call
through
the
interface,
you
might
end
up
seeing
it
to
the
base
type
of
to
the
to
the
drive
or
to
the
implementing
type.
In
which
case
you
no
longer
get
a
warning
which
would
be
odd.
C
So
yeah,
it
sounds
reasonable
to
me
to
say
that
we
want,
if
you
are
a
type
that
is
implementing
an
interface
that
has
restrictions
that
then,
if
you
don't
have
some
notion
of
more
restrictive
restrictions,
that
it
gives
a
warning
and
you
have
to
suppress
it.
I
think
in
in
the
long
term,
we
may
find
that
we
need
another
attribute
that
you
can
put
on
a
type
that
says,
ignore
the
supported
attributes
from
the
following
interface.
So.
H
C
Don't
end
up
with
you
suppressed
it
once
and
then
you
added
another
interface
and
now
you've
lost
the
warning,
because
you
only
meant
to
suppress
it
for
that.
First
interface,
that
you'd
added,
because
you
don't
get
to
put
the
pragma
suppress
around,
I
don't
think
you
get
to
put
it
around
the
interface
name
on
the
right
side
of
the
colon.
I
think
it
goes
around
the
type
definition,
so
the
left
side
of
the
cool
one,
but
I
don't
think
there's
going
to
be
enough
of
this-
that
it
matters.
A
About
the
only
thing
I
would
add
is
we
should
probably
do
the
same
thing
for
unsupported
device,
part
from
attribute
guide
because
it
seems
like
if
we
do
it
for
one.
We
should
do
it
for
the
other
and
I
think
there's
one
more
right.
There's
the
obsoleted
os
platform
or
how
do
we
call
it.
I
So
with
the
introduction
of
interface,
that
just
leaves
a
return,
value
parameter
generic
parameter
and
delegate
that
aren't
allowed
right
and
delegates,
the
only
one
that
I
could
think
of
that
might
be
reasonable.
Just
from
the
perspective
of
you
can
use
delegates
in
interrupt
scenarios
with
a
special
attribute
that
might
make
them
apply
to
a
single
platform
that
would
be
the
unmanaged
function
pointer
attribute
that
impacts
how
it's
marshaled
to
native.
A
A
I
A
I
That
probably
depends
some
libraries
want
to
expose
one-to-one
bindings
and
others
expose
abstractions
over
them.
I
think
winforms,
for
example,
leans
towards
the
public,
the
public
surface
area
being
more
of
an
abstraction,
like
their
delegates,
are
over
a
ref
message
m
rather
than
actually
taking
in
the
the
handle
and
the
uint
message.
A
I
mean
the
only
thing
why
I'm
somewhat
hesitant
to
add
delegate
heroes.
I
mean
what
you're
saying
makes
sense,
but,
like
my
concern
is
we
have
to
know
think
about
what
that
means
for
the
analyzer
like
basically,
what
kind
of
code
path
would
we
now
have
to
start
to
flag,
because
today
we
don't
look
at
delegates
in
that
sense,
and
it
might
make
more
sense
to
you
know
not
allow
it
now
so
that
if
later
on,
we
do
add
the
analyzer
to
do
this.
A
F
A
A
A
C
So
I
can
speak
to
this
one,
so
we
currently
have
a
sequence.
Equal
method
for
span
read
only
span
on
memory
extensions,
but
it's
constrained
to
t
by
credibility,
which
means
we
can't
then
delegate
it
to
to
it
from
places
like
link
where
we
don't
have
such
a
constraint,
and
we
just
use
you
know,
compare
of
t
or
equality
compare
t
dot
default.
C
C
I
mean
you
can't
have
a
constraint
only
overload,
I
don't
think,
but
if
it,
if
we
made
sequence
equal
of
t
that
took
you
know
some
spans
and
an
eye
comparison
or
I
compare
or
whatever,
then
we
could
constrain
it
differently
and
now
now
it
has
a
different
signature
right.
So
that's
what
I've
suggested
is
taking
the
the
actual
compare
to
use.
As
the
last
argument.
C
C
I
think
that
would
result
in
worse
code
for
reference
types.
We
can
do
the
right
thing
internally,
sharing
implementation
with
unsafe
code
and
blah
blah
blah,
I
think
yeah.
I
think
we
would
just
leave
the
the
current
one
as
is,
and
then,
if
you
want,
if
you
have
a
non-equatable
type
but
you've
written
an
equality,
compare,
then
you
just
call
the
three
argument:
one
okay,
and
if,
if
the
type
is
not,
if
the
type
doesn't
implement
inflatable
then
pass
nolan
will
use
equality,
compare
default
right
and
then
hopefully
it
does
the
right
thing.
C
C
C
C
And
then
the
other
related
question
I
had
was,
I
didn't,
run
into
the
situation,
but
I
wanted
to
raise
it
and
that
is.
We
also
have
these
memory
extensions
dot
sequence
compare
to
so
we
can
consider
as
long
as
we're
doing
these.
We
could
do
a
similar
thing
for
those
and
take
an
I
comparative
t,
but
I
didn't
have
a
use
case
for
that.
So
I
didn't
add
it.
C
What
does
compare
of
t
dot
default
to
similar?
It
looks
for
I
compare
of
t
implementation
and-
and
it
has
some
built-in
knowledge
of,
if
you're,
comparing
null
against
non-null
like
what
does
that
mean
in
terms
of
less
than
zero
or
greater
than
zero?
I
don't
remember
what
it
decides
and
if,
if
you're,
just
comparing
arbitrary
objects,
that
uses
like
the
hash
code
or
something
I.
C
Object,
compare
t
dot,
no
idea
what
it
does.
I've
never
tried
to
use
it
because
the
the
regular
equality
compare
of
tdot
default
eventually
just
goes
to
object.equals
right,
like
as
a
fallback,
but
like
I,
I'm
racking
my
brain
trying
to
figure
out
how
on
earth.
This
would
have
a
consistent
ordering
between
two
arbitrary
objects.
C
There's
it
passes,
equality,
compare
or
a
compare
of
t
dot.
C
If
you
don't
pass
one
of
these
comparison.defaults,
which
then
you
know
if
it's
it
tries
to
use
the
I
compare
I
comparable
or
yeah,
I
comparable
of
t
implementation
on
the
type
and
if
it
can't
find
it
not
comparable
with
t
or
I
comparable
whatever
it.
I
think
it
ends
up
throwing
an
exception.
A
G
A
Yeah
the
comparable,
basically
only
like
the
the
the
comparable
like
one
of
the
operands,
is
especially
the
this
one,
and
so
the
comparer
is
the
one
that
takes
both
arguments
right.
So
you
do
so
either
the
type
itself
implements
are
comparable
or
you
have
to
pass
in
the
comparer,
which
basically
takes
both
arguments
right.
That's
the
pattern.
G
C
G
C
I
muddied
the
waters
I
was
suggesting
we
add,
I
I
wasn't
saying
getting
the
complete
story,
I'm
proposing
the
two
overloads
that
are
shown
here,
there's
no
problem
with
them.
What
I
was
commenting
on
was,
if
we
didn't
add
that
last
compare
argument,
then
we
would
need
to
come
up
with
a
new
name.
Basically.
G
H
C
C
The
generic
one
that
you
don't
meet
the
constraint
should
not
be
eligible,
so
you
either
have
an
exact
match.
If
you
are,
if
you
meet
the
constraint
or
the
default
parameter,
I
mean
granted.
Levi's
test
will
tell
all,
but
I
think
it
should
work
yeah.
It
looks
like
it's
working
just
fine,
so
in
that
case
we
could
add
equals
null
at
the
end
of
each
of
those
and
just
kind
of
have
the
best
of
both
worlds.
Yeah.
C
C
G
Yeah-
and
I
think
steven
pointed
out
that
could
result
in
work
performance
for
reference
types
right,
because
it'll
happen.
C
If
we
went
through
the
default,
compare
we're
not
going
to
at
least
the
way
the
current
system
works,
we
wouldn't
be
able
to
de-virtualize
all
the
way
through
yeah.
I
wonder
if
we
were
trying
to
avoid
doing
implicit
equality,
comparisons
on
structs
and
that
we
said
we
only
wanted
this.
If
you
said
yourself
was
said,
you
were
comparable
yourself.
C
I
mean,
and
if
that's
the
case,
then
we
would
not
add
the
third
parameter,
because
we'd
make
you
go
out
of
your
way
to
do
more
things.
I
I
don't
know,
what's
bad
about
letting
someone
say
how
they
want
things
compared
yeah
like,
I
think
it's
good
to
add
the
overlap.
The
question
is
the
constraint
on
the
current
one
and
do
we
want
the
the
defaulted
parameter
and
all
that.
G
So
two
thoughts
on
that.
One
again
is
what
does
link
do
like
if
you
do
a
group
buy
or
something
like
that?
Does
it
work
on
on
structs
that
that
don't
provide
I
equatable
and
two
is
if
we
didn't
want
to
prevent
that,
how
would
we
do
that
without
making
other
scenarios
more
difficult?
G
I
mean,
I
think,
the
a
very
simple
scenario
here
that
it
seems
worth
enabling
is
just
t
is
some
reference
type,
possibly
object,
and
I
just
want
to
do
a
I
want
to
find
out
if
the
span
contains
the
same
set
of
reference
types
or
not,
and
in
that
case
there's
no
point
in
me
supplying
my
custom.
Compare.
I
just
want
to
do
the
default
reference
comparison.
G
C
Yeah,
my
I'm
just
thinking
out
loud.
If
the
reason
we
have
the
I
equatable
constraint
is
to
avoid
the
destruct
the
relatively
expensive
implicit
struct
equals,
because
people
using
spans
are
obviously
caring
about
performance,
so
they
don't
want
the
trap.
Then
that
would
mean
we
wouldn't
default.
The
last
parameter
and
hey
you
explicitly
called
this
one
that
is
doing
things
you
didn't
get
the
fast
one
like
that
was
on
you,
but.
G
H
G
G
I
think,
but
it's
also
you
know
you
can
write
your
a
really
stupid,
equatable
implementation,
sure
if
you've
written
a
struct
that
doesn't
have
I
equatable
and
you're
using
sequence,
and
you
do
any
kind
of
equation:
equality,
operation
on
it
and
the
performance
sucks,
because
you
get
the
default
implementation.
I
think
that's
kind
of
on
you.
C
C
Did
we
did
we
also
implicitly
approve
compare
to
at
the
same
time,
or
do
you
want
to
reserve
that
for
a
different
talk,
I
I
didn't
have
a
need
for
it,
so
I
didn't
add
it.
Maybe
we
hold
off
until
we
do
sounds
good.
A
A
A
So
we
said:
okay,
let's
have
a
read
only
struct.
We
need
to
decide
what
we
do
with
the
weight
behavior
or
whether
we
just
basically
remove
the
type
itself
and
just
have
named
arguments.
A
C
Yeah,
I
think
they're
are
basically
three
high-level
options
being
considered.
One
is
two
of
what
you
described
so
one
is
you
have
a
struct?
You
pass
the
struct
in
to
a
configure
weight.
The
other
is
you
have
overloads
of
configure
weight
that
take
all
the
arguments
that
you
care
about
for
that
particular
thing,
and
then
the
third
is
going
back
to
the
a
bunch
of
individual
with
methods
with
cancellation
with
timeout.
C
You
still
need
configure
a
weight
for
some
of
these
things
because
they
can
only
be
about
the
await,
like
continue
on
capture
context
for
safe
sync,
suppress
exceptions,
so
that's
sort
of
in
addition
to
rather.
C
C
The
idea
that
continuations
should
continue
on
the
captured
context
or
not,
there's
no
way
to
build
into
task
itself,
a
way
to
say
all
continuations,
regardless
of
what
whether
the
task
is
completed
or
not,
should
run
asynchronously
and
there's
no
way
to
build
into
task
itself.
All
awaits
on
this
task
should
suppress
throwing
of
exceptions.
C
E
G
C
I
mean
you
know
force.
They
think
you
could
basically
effectively
address
by
adding
an
await
task
yield
afterwards.
So
like
there
are
other
ways
to
express
these
things,
but
you
can't
build
them
into
the
task.
There's
no
way
to
like
create
a
task
that
embodies
those
concepts,
whereas
in
theory
you
could
build
a
task
that
embodied
the
cancellation
token
or.
C
C
So
it
comes
down
to
like
whether
we
want
to
try
and
build
some
all-inclusive
struts
that
we
can
add
more
stuff
to
in
the
future
and
potentially,
if
we
think
I'll,
try
and
reserve
my
opinions
or
biases.
If
we
think
that
the
configurate
approach
would
help
with
discoverability
or
wouldn't
cause
people
to
think
they
were
somehow
impacting
the
original
task.
C
There's
the
overloads
of
configure
weight
where
we
want
to
be
more
fine-grained
about
either
having
overloads
that
only
offer
a
subset
of
things,
making
certain
combinations
easier
to
express,
not
exposing
options
on
task
like
types
that
don't
make
sense
and
then
there's
adding
the
width
timeout
or
with
cancellation
methods,
potentially,
in
addition
to
a
configure
weight
that
deals
with
those
other
three
things.
C
And
then
you
know
you
can
the
pros,
for
that,
is
you
can
say,
with
timeout,
with
cancellation
on
their
own
use
them
in
any
context
you
want.
The
downside
is
you're,
probably
paying
more
for
that
you're
potentially.
C
Confusing
people
who
think
that
with
timeout
is
somehow
impacting
the
original
task
or
with
cancellation
somehow
back
in
the
original
task.
And
if
you
care
about
those
other
three
things,
you
still
need
a
configuration.
G
Yeah,
I
mean
my
my
main
piece
of
feedback
here
I
guess
is.
I
have
seen
lots
and
lots
of
asks
for
the
cancellation
and
timeout
behavior
and
people
a
people
seem
to
really
want
it
b
when
they
find
out
there's
no
kind
of
like
built-in
way
to
do
this
automatically.
G
They
tend
to
go
off
and
build
something
themselves
and
often
do
something
really
bad,
and
so
I
would
love
to
see
us
have
a
a
way
to
expose
that
discoverable
and
straightforward
to
use
and
the
way
the
api
is
structured
here
where
it's,
you
have
to
effectively
do
dot,
configure
a
weight
and
then
no
and
then
go
figure
out
this
struct
that
has
a
bunch
of
unrelated
properties
on
it
seems
like
it's
unnecessarily
complicated
for
that
that
scenario,
as
far
as
so
there
were
two
other
concerns
you
raised
about
that,
I
think
one
was
perf.
G
I
don't
see
why
the
perf
needs
to
necessarily
be
any
different.
It
could
be
that
if
we
have,
you
know
if
it's
a
like,
when
you
know
or
like
cancel
when
or
something
like
that,
then
it
could.
That
could
literally
just
wrap
the
the
configurate
api
proposed
here.
In
other
words,
we
could
stretch
the
api
in
such
a
way
that
there's
like
a
a
full-blown.
You
know
low-level
api.
That
exposes
every
option
that
you
can
that
we
want
to
which
is
basically
what
you've
got
here.
G
I
think,
and
then
just
some
simple
helpers
on
top
of
that
that
allow
you
to
accomplish
very
you
know,
simple
and
and
common
tasks
like
setting
up
cancellation,
sure.
C
G
That's
true,
the
reason
you
would
want
that
is
because
you
explicitly
want
a
task
as
opposed
to
just
a
random
waitable,
because
you're
going
to
wait
all
or
you're
going
to
do
like
a
when
all
or
when
any
or
something
like
that
on
it.
C
G
C
C
Right,
basically,
we're
scratching
off
that
direction.
Leads
you
to
not
expose
the
width
methods
and
then
you're
back
at
adding
a
method
that
returns
an
awaitable
and
we
have
one
of
those
and
it's
called
configure
weights.
This
is
over,
so
you
know
it.
I
think.
If
we
go
that
route,
I
would
be
hard-pressed
to
come
up
with
anything
better
than
just
an
overload
of
the
existing
thing.
G
Something
like
that
yeah
I
mean
the
other.
The
other
way
you
could
go
is
to
go.
Full
blown
just
expose
each
of
these
as
its
own
individual
method.
I
kind
of
like
that
approach
too,
but
it
seems
like
we.
I
don't
have
a
strong
opinion
on
that.
My
high
order
here
is
just
make
the
simple
thing:
simple,.
C
G
C
F
C
Right,
it's
not
hard,
it's
just
more
kludgy
I
mean,
and
I
say
that,
having
done
that
already
with
what
we
did
for
async
and
new
rules
yeah
for
what
it's
worth,
I
I
have
a
viscerally
negative
reaction
to
the
abandoned
terminology,
but
maybe
that's
just
me.
C
As
a
high
level
concept,
I
think
it's
totally
fine
like
if,
assuming
that,
we
think
that
the
struct
works,
because
we're
okay
with
saying
value
task
throws,
if
suppressed
exceptions,
is
true
or
whatever,
assuming
that
we
think
that
the
struct
has
value
as
the
this
tells
you
all
the
options,
etc
and
or
it's
reusable,
then
convenience
overloads
that
call
it,
for
you
seem
totally
fine
yeah.
I
would
just
want
them
to
actually
be
overloads
like
configure
a
weight.
C
Bool
cancellation
token,
in
addition
to
configure
a
weight,
await,
behavior
or
whatever
sure,
but
I
mean
if
we
ignore
the
fact
that
we
were
adding
the
struck
one.
At
the
same
time,
it
could
be
that
we
had
named
the
thing
abandoned
and
then
we
like,
oh,
let's,
make
the
struck
to
unify
all
these
things
and
configure.
What's
the
best
thing
like
that's,
that's
the
roof
of
the
bike
shed.
I
think
right
now
we're
still
working
on
the
foundation.
G
I
hear
what
you're
saying
I
just
don't
think
that
configure
weight
configurate
seems
if
I'm
a
casual
user-
and
I
see
configure
weight-
I
mean-
maybe
we've
trained
them
already
with
the
configure
away
false
as
exists
today,
but
I'm
not
sure
how
many
people
actually
use
that
in
fact,
I'm
a
user
and
I'm
trying
to
figure
out
hey,
I
want
to
you,
know,
add
some
sort
of
cancellation
to
my
weight
here.
I
think
configure
weight
is
a
scary
name.
That's
going
to
scare
me
off
and.
C
Yeah,
what
I'm
concerned
about
is
you.
You
pass
a
resource
into
the
asynchronous
method.
You
abandon
the
await.
Those
resources
are
still
in
use
like
you've
abandoned
the
away,
but
some
underlying
io
of
our
operations
still
working
on
those
buffers
like
if
you
return
them
to
the
array.
Will
god
help
you
like
you've,
now
corrupted
global
app
state?
Hooray?
C
C
I
raised
one
last
time
that,
like
this,
like
there,
the
suppress
exceptions,
behavior
is
not
ideal
for
value
task,
but
exposing
the
structs
suggests
that
we
want
to
be
able
to
reuse
it
in
multiple
places
right,
but
we
do
have
the
option
of
throwing
if
it's
true,
when
the
value
test
can
figure
away,
we
could
do
that
it.
C
I
guess
it
hints
that
if,
if
one
makes
the
argument
that
the
struct
is
there
because
you're
going
to
be
adding
more
stuff
in
the
future,
potentially
then
the
more
stuff
you
add,
the
more
likely
it
is
that
those
things
won't
play
nicely
with
wherever
it's
being
used.
But
it's
a
slippery
slope.
C
It's
basically
not
wanting
to
have
to
write
the
try
catch
deal
with
the
first
chance
exception
and
the
overhead
of
the
exception
getting
thrown
the
most
often
case
I've
heard
of
when
people
ask,
for
it
is
either
perf,
they
don't
want
the
exception
thrown
or
they
want
to
do
their
own
thing
and
potentially
throw
their
own
exception
afterwards
again
without
the
expense
of
the
thing
being
thrown.
So,
for
example,
if
you're
dealing
with
a
task
that
actually
does
contain
multiple
exceptions.
If
you
await
it,
it
only
propagates
one.
C
So
someone
wants
to
be
able
to
await
it
without
anything
being
thrown
and
then
throw
their
own
aggregate.
Today
you
can
do
that.
You
try
a
weight
t
catch
and
in
the
catch
you
throw
t
exception,
which
will
be
an
aggregate
exception,
but
here
you
know
you're
a
little
bit
more
code
and
there's
a
perf
over
into
it.
C
G
G
It
sounds
to
me
like.
Perhaps
this
is
one
we
should
cut
right.
It
sounds
like
there's
complications
and
the
value
here
isn't
huge.
I
mean
if
it
was.
If
it
was
simple
to
do,
I
would
say
sure:
go
do
it,
but
if
it
if
it
causes
us
pain,
then
why
why
would
we
try
and
do
it
as
opposed
to
just
telling
people
hey
use
tricatch,
that's
what
it's
for.
J
I
would
also
like
to
raise
another
concern
about
the
suppress
exceptions
design
in
particular.
If
I
may,
there
is
another
concern
basically
around,
I
guess
type
safety
in
this
case.
You
know
consider
the
example
where
you
have
a
task
where
the
t
type
is
an
unknowable
reference
type
and
you
await
it
with
suppressed
exceptions.
J
You
know,
lo
and
behold,
the
return
value
would
be
no,
but
you
wouldn't
have
you
know
your
usual
nullability
warnings
apply
to
the
the
the
rest
of
the
async
method,
so
I'm
assuming
that
for
the
use
cases
that
we're
looking
at
it
might
not
be
an
issue,
but
I
I
I
think
it's
certainly
something
we
should
take
into
consideration
as
well.
H
By
the
way,
emo,
I
muted
you
on
teams,
because
your
microwave
was.
C
C
E
C
Yes,
really
really.
What
I
don't
want
is
us
to
add
it
and
it
to
get
on
value
task,
and
it
be
like
well
97
of
the
time
when
someone's
doing
this,
it
didn't
matter,
but
then
that
that
one
percent,
where
the
I
value
task
completion
source
has
released
its
tracking
handle
and
reused
it
and
you're
now
getting
some
other
state.
Once
you
try
to
read
the
exception
like
that,
that's
what
I
really
want
to
avoid.
J
Yeah,
assuming
we
went
down
the
weight
behavior
struck
design,
would
it
perhaps
make
sense
to
expose
separate
structs
for
task
and
for
value
tasks?
That
would
give
us
more
flexibility
in
terms
of
what
behaviors
we
want
to
expose
for
each
of
them.
C
We
could
it
just
it's
one,
more
thing
that
puts
in
your
face
what
kind
of
thing
you're
dealing
with
like
it's
for
the
most
part,
if
you
say
you
know
awaitstream.readasync,
you
don't
really
have
to
know
whether
it's
returning
you're
using
the
overload
that
returns
a
task
or
a
value
task.
But
now
you
need
to
know
because
the
dot
that
you
do
after
it
requires
you
to
pass
a
different
type.
C
C
C
Yeah
yeah,
so
the
two
bowls
that
I'm
wondering
if
this
truck
should
actually
have
like,
should
have
a
copy
constructor.
That
way,
if
you
wanted
to
implement
your
own
extension
method,
you
could
just
change
a
single
property
while
leaving
all
the
rest
the
same.
Well,
I'm
wondering
further,
so
I
mean
like
so
continue
on
capture
context.
C
I
know
people
hate
it,
but
it's
critical
force
they
sync
and
suppress
it
like
suppressed
exceptions.
We
just
said
we're
going
to
get
rid
of
or
say
sync
like
you,
don't
that's
really
like
a
nice
to
have
for
some
very
niche
scenarios.
We
wrote
our
own
a
waiter
at
one
point
to
do
it
on.
I
think
crypto
stream
and
something
else,
and
then
we
like
ditched
it
later.
C
Is
this
the
captured
context
of
the
synchronization
context
or
the
security
context,
execution
context,
synchronization
context
and
task
scheduler?
Would
you
ever
want,
like
an
unsafe
equivalent
that
jumps
off
of
the
execution
context
as
well?
You
can't
well
nothing's
can't,
but.
C
Not
the
waiter
that
flows
it!
It's
the
yes
you're
right,
you're,
right,
okay,.
C
Right
and
and
on
it
like
every
await,
like
the
awaiter
itself,
you
know
has
on
completed
and
unsafe
on
completed
and
99.999
percent
of
the
time.
The
compiler
is
always
generating
a
call
to
unsafe
on
completed
anyway,
so
yeah
not
actually
flowing
at
the
await.
It's
the
builder
that
layers
it
on
got
it
now.
You
could,
potentially
you
have
to
teach
our
builders
to
recognize
visa
waiters
specifically
and
then
look
to
see
whether
those
settings
were
applied
and
you
know
stop
its
flow,
but
that's
a
whole
other
ball
left
sure.
C
The
context
behind
that
question
is,
I
know
that
the
kestrel
folks
specifically
have
been
asking
for
some
much
lower
level
threading
apis
in
order
to
remove
as
much
overhead
as
possible-
and
I
wonder
if
this
struck
were
we
to
keep
it
around-
might
be
an
appropriate
place
to
expose
some
of
those.
Maybe
the
main
point
place
that
we've
been
getting
requests
for
suppressing
execution
context
flow,
which
is
jeff
mentioned.
C
C
Some
long-running
operation
you
happen
to
have
some
expensive
resources
in
async,
local
and
now
that
long-running
operation
is
keeping
that
thing
alive
forever.
Yeah
we
had.
We
had
that
exact
scenario
in
web
sockets
in
asp.net
desktop.
We
actually
had
to
to
dump
the
synchronization
context
as
a
result
of
that.
C
C
Use
async
locally.
Sometimes
it's
done.
You
say
sync
logo.
Sometimes
it's
explicitly
call
executioncontext.suppress
flow
and
restore
flow
around
your
operation
and
sometimes
it's.
We
have
an
unsafe
overload
that
basically
just
doesn't
call
executioncontext.capture
and
in
some
cases
for
more
prominent
apis
we've
explicitly
added
those
that
you
know
strong
requests
yeah,
but.
A
C
I
was
going
down
the
the
argument
of
well
the
last
two,
we
sort
of
said
we
don't
like
the
last
one,
because
it's
problematic
right.
Fourth,
one
I'm
saying
I
had
added
that
to
the
list
in
my
initial
proposal
and
then
convinced
eric
to
incorporate
it
and
now
I'm
suggesting,
but
it's
it's
very
niche
and
it's
possible
to
do
it
in
various
ways
on
one's
own
and
if
you
get
rid
of
those
two
now
you're
basically
left
with
the
existing
the
bull.
G
C
Could
the
the
primary
concern
I
have
with
that
is
that's
one
of
the
things
we
see
people
frequently
get
wrong.
They
you
end
up
creating
a
like
you
say,
like
new
cancellation,
token
source
with
your
timeout,
and
that
just
and
you
say
just
pass
in
dot
token
and
they
they
neglect
to
dispose
of
that
cancellation
token
source
afterwards
and
now
the
timer
is
still
hanging
around.
C
That's
right
and
the
other
benefit,
if
you
happen
to
need
both
a
cancellation
token
and
a
timeout
which
is
rarer.
It
happens,
but
it's
rare
there's
additional
work.
You
would
have
to
do
to
combine
the
incoming
cancellation
token
with
the
cancellation
token
source
for
your
timeout
and
then
you
would
need
to
dispose.
You
know
that
resulting
thing
as
well,
and
so
we
would
we
would
handle
that
internally,
but
yeah
so
yeah
go
ahead.
C
Sorry,
do
we
still
need
this
truck
just
from
the
point
of
view
that
someone
might
need
to
get
the
original
cancellation
token
or
timeout
so
that
they
can
chain?
I
don't
wait.
I
don't
understand
the
question
so
if
I,
if
I
say,
cancel
after
some
time
span
or
some
cancellation
token
and
then
cancel
after
again
a
different
time
span
or
a
different
cancellation
token
am
I
going
to
have
to.
I
guess
I
don't
have
to
chain
those,
because
I
would
just
have
two
cancellations
registered.
Wouldn't
I
okay
never
mind.
H
A
C
C
The
only
difference
well,
there's
a
there
would
be
a
small
perf
difference.
That's
probably
inconsequential
in
that.
You
would
basically
have
to
make
another
trip
through
the
state
machine
to
get
to
the
task
yield,
whereas
it
would
just
sort
of
be
built
in
that's
minor
and
then
the
other
one
would
be.
We
don't
currently
expose
any
weight.
We
don't
currently
expose
the
equivalent
of
a
weight
thread,
pool
basically
that
you
know
like
away
threadful.hop
or
whatever
you
want
to
call
it.
C
That
would
basically
force
your
continuation
to
run
on
the
thread
pool.
That
is
what
task
weight
task
yield
does
unless
there
is
a
synchronization
context
or
task
scheduler
present,
in
which
case
it
will
schedules
for
those
and
so
and
we
don't
have
like
a
weight
test,
dot
yield
dot
configure
await
false,
so
force.
Async
would
basically
be
the
equivalent
of
a
weight,
test.yields,
dot,
configurate,
false
effect.
Okay,
but
again
it's
it's
actually
not
hard
to
add
this
functionality.
C
C
Yeah,
maybe,
instead
of
force
async,
we
want
task.yield
with
a
boolean,
continue
on
capture
context,
so
that
ui
applications
could
use
that
as
an
easy
course.
They
think
we
don't.
C
C
If
we're
cutting
things
off
of
this
struct
and
and
the
only
time
that
there's
a
difference
between
task.yield
and
force,
async
is
ui
applications
or
anywhere
else,
so
there's
a
scheduler,
then
maybe
we
want
to
give
them
the
easy
way
instead
of
the
oh,
this
boilerplate,
but
it
takes
like
50
steps.
C
I
think
what
I'm
finding
my
head
like
walking
back
my
own
comments.
I
I
think
I
basically
once
we
introduced
the
concept
of
the
structure,
I
kind
of
felt
myself
thinking.
Oh,
we
can
just
throw
all
these
other
things
that
people
have
been
wanting
onto
this
without
really
thinking
hard
about,
whether
each
of
them
on
their
own
is
merited,
and
at
some
point
you
get
rid
of
enough
of
them
in
the
struct
becomes
kind
of
superfluous.
J
I
would
say,
though,
I
mean
like
repeating
myself
here,
the
I
I
would
say
that
the
primary
motivation
on
my
side
for
using
a
weight
behavior
is
to
explicitly
make
it
more
difficult
to
pass
cancellation
tokens
or
timeouts
to
the
available.
C
A
C
Right
so
I
think
steve's
current
best
proposal
and
then
we'll
let
steve
and
jeff
box
over
the
name
is
configure
await.
Bool
defaulted
time
span,
defaulted,
cancellation,
token.
C
Time
span
zero,
which
do
you
think
some
people
may
want
to
be
like.
I
wish
you
were
already
canceled
instead
of
zero
for
not
cancelled
well
and
not.
I
don't
know
that
anyone
would
explicitly
pass
a
constant
zero,
but
but
they
are,
you
know,
time
spend
zero,
but
if
there
was
math
being
done
to
subtract
remaining
time,
you
might
end
up
at
zero
fair
enough,
so
that
would
be
configure
weight.
Boolean
cancellation,
token
and
configure
await
boolean
time
span.
Defaulted.
Cancellation,
token.
G
C
Maybe
multiple
over
multiple
chaining,
multiple
methods
together
here,
I
think
it's
pretty
ugly.
E
C
As
is
another
overload
that
you
know
three
overloads
full
cancellation,
token
bool,
timeout,
bool,
timeout
cancellation,
token,
I
don't
have
a
strong
opinion.
The
the
places
that
you
end
up
with
both
of
them
are
usually
some.
You
know
very
deep
somewhere
in
your
code
path
and
you
either
have
been
passed
in
a
remaining
amount
of
time
and
you
have
your
own
sort
of
internal
source
of
cancellation
or
you're
passed
in.
You
know
an
external
source
of
translation
and
your
own
kind
of
limit.
C
You
want
to
apply
or
some
such
thing,
but
I
I
don't
feel
strongly
enough.
A
C
Yeah
I
mean,
I
think
it's
once
we
if
we
decided
to
then
bring
force
async
back
in
that
now
it's
like
we've
decided
the
three
things
were
the
important
things
and
complicated
things
that
use
destruct.
I
mean
we
could
argue
that
other
complicated
things
are
worthy
of
proper
overloads,
but
I
don't
think
we
would
go
full
combinatoric
as
future
options
come
on
board.
A
C
G
C
Yeah,
I
I
I
mean
I'm
probably
colored.
My
view
of
this
is
probably
colored,
but
I
don't
want
to
expose
the
can't
configure
a
weight
method
that
doesn't
take
the
bool.
G
Yeah,
that
seems
fine
is,
do
we
expo
that's.
How
do
we
expose
one
that
defaults
it
to
false
because,
like
it
seems
like
a
fairly
common
scenario
here?
Is
I
just
want
to
set
a
cancellation
token
or
a
timeout?
I
don't
really
want
to
adjust
the
continue,
uncaptured
context
default
behavior
and
I
don't
really
want
to
think
about
it.
Either.
C
A
Well,
I
guess
it
depends
on
how
strongly
a
few
people
know
what
to
pass
in
for
the
first
argument
right,
if,
if
we
think
they
know
that
you
know
they
can
quickly
pick
a
value
that
is
right.
Otherwise,
my
concern
is,
they
will
just
throw
in
some
random
value
right
and
which
point
you
might
be
better
off.
Just
saying
you
know
just
passing
the
only
thing
you
care
about.
C
G
It
seems
like
it's
fairly
clean,
to
have
one
method
that
deals
with
cancellation
and
another
that
deals
with
the
captured
context
and
the
system
chosen
to
call
the
one
that
deals
with
captured
context
configure
weight,
whereas
if
we
called
the
other
one,
you
know
abandon
a
weight
which
I
know
you
hate,
but
if
we
come
up
with
a
better
name
for
it,
then
and
and
chain
them,
but
the
chaining
is
simpler.
Now,
because
we
only
have
a
couple
options,
we
have
fewer
options.
E
G
G
Well,
the
specific
thing
I
was
suggesting
it
buys
this
is:
it
makes
it
easy
to
say
something
like
dot,
abandon
a
weight
cancellation
token
and
not
have
to
think
about
capturing
context
at
all
or
set
captured
context
explicitly
or
deal
with
a
named
parameter
or
anything
like
that.
C
Do
you
then
think
that
we
need
to
support
the
combinatoric
setting
of
all
of
these
options
on
all
possible
waiters
or
sorry
awaitables,
for
because
the
problem
is,
if
you
want
configure
weight,
false
and
the
timeout
either
we
made
it
so
that
you
could
chain
these
things,
which
is
we
can
write
a
some
sort
of
build,
validator
or
analyzer
that
helps
us
not
screw
it
up,
but
it's
a
lot
of
work
that
won't
sustain
itself
versus
if
they're,
all
overloads
of
one
thing.
C
A
I
mean
I'm
not
sure
I
I
don't
think
it's
going
to
be
that
simple
right,
because
it's,
I
think
to
me
the
the
saving
grace
is,
it's
always
sufficiently
ugly
right,
I'm
always
more
concerned
when
something
looks
appealing
and
then
people
kind
of
are
excited
to
kind
of
like
just
do
the
one
thing
and
then
they
screw
it
up,
but
this
one
because
you
have
to
basically
do
it
right
before
you
do.
The
await,
like
the
code,
always
looks
somewhat
ugly.
So
I
I
don't
think
that
people
are
very
likely
to
do
it.
A
G
C
Yeah
for
cancellation
token,
usually
what
happens?
Is
you
create
a
new,
a
new
task,
completion
source
that
will
be
or
you
have
if
you
haven't
you'll,
have
an
async
method
that
returns
a
task
and
you'll
have
a
task,
completion
source
that
you
complete.
When
the
cancellation
token
is,
you
know,
signaled,
and
you
await
any
the
original
task
and
the
cancellation
task.
C
And
then,
hopefully
you
were
able
to
dispose
your
cancellation
token
source
and
you
know
check
which
task
completed
and
throw
the
appropriate
exception
or
return
or
whatever
and
similar
for
timeout
with
a
timer
or
are
generally
with
a
task.delay.
So
task
await
task.when
any
with
the
original
task
and
a
task
created
from
task.delay.
And
then
hopefully
you
remember
that
you
actually
should
have
created
your
task.delay
with
a
cancellation
token.
So
you
construct
a
cancellation
token
source
and
you
pass
that
into
your
task
dot
delay.
And
then
you
cancel
the
cancellation
token
source.
G
C
Well,
normally
you're
you're,
adding
a
timeout
to
things
that
are
going
to
complete
really
fast,
and
you
create
your
time
up.
That's
really
long
like
90
seconds,
and
so
your
operation
completes
really
fast
and
then
your
taskbar
delay
has
a
timer
just
sitting
there
waiting
to
fire
in
90
seconds
and
isn't
going
to
go
away
until
it
fires.
Yes,
you
end
up
with
a
million.
G
Tasks
that
now
that's
a
that's
a
problem
with
well.
G
G
The
the
nice
thing
about
using
when
any
of
this
is
that
it
it
forces
the
user
to
understand
a
little
bit
more,
that
that
the
existing
task
isn't
actually
going
to
be
cancelled.
You're
just
going
to
be
notified
when
the
first
task
of
the
set
complaints.
C
C
C
Yeah,
exactly
it
usually
comes
to
us
with
my
app
is
spending
20
of
its
time
in
timers.
Timers
are
broken
and
we
say
all
right,
we'll
dump
your
timers
and
there's.
You
know
a
million
of
them
that
are
all
from
task
dot
delay
from
a
with
timeout
method,.
G
C
We
could
do
that
there's
another
issue
open
for
when
any
with
a
timeout,
it's
still
non-trivial
boilerplate,
but
it
would
alleviate
that
particular
issue.
It
would
alleviate
needing
to
create
the
cancellation
token
source,
pass
it
to
a
test.delay
and
remember
to
dispose
the
timer.
So
what's
the
complexity
on
the
caller,
not
on
us?
C
C
What
one
one
task
right,
yeah
I
mean
we
probably
want
to
add
an
overload
for
the
one
task,
so
we
don't
create
the
array
to
wrap
one
task
right,
so
part
of
the
complexity
is
you're
now
forcing
someone
to
look
for
to
when
any,
when
they
only
have
one
thing
and
we've
already
talked
about
not
wanting
to
make
people
use
one
any
when
there's
one
thing,
but
you
know
logically
there's
the
second
thing.
That
is
a
timeout.
C
I
just
don't
know
that
people
think
about
it
that
way,
and
then
there
the
complexity
is
then,
if
tasks.when
any
time
out,
comma
t
does
not
equal
t
throw
timeout
exception
else
await
task
because
it
returns
the
task
that
completed
right.
So
that
means
that
the
caller
would
also
have
to
turn
a
value
test
into
a
task.
In
order
to
call
this
api,
yeah,
we've
explicitly
said
we're
not
adding
when
any
for
value
tasks
now
so
now,
maybe.
C
G
C
It
returns
the
task
object,
not
the
task
index.
Okay,
sorry,
but
there's
the
other
problem,
the
problem
with
these
combinators
over
something
like
value
tasks,
because
they
necessarily
need
to
hook
up
a
continuation.
C
If
you
then
force,
and
if
you
then
force
the
user
to
go
back
to
the
thing
afterwards,
you're
setting
up
the
exact
situation,
we
say
shouldn't
be
done
with
value
tasks
which
is
hook
up
two
continuations
or
look
at
them
twice
or
whatever.
We
can.
A
C
That
ourselves,
internally
in
a
configure
weight,
that's
built
into
value
task,
but
it
becomes
sketchy
suggesting
other
people
do
it,
because
what
you
would
want
to
do
then,
is
at
the
original
weight
you
would
probably
want
or
sorry
when
you
get
the
value
task,
you
probably
want
to
turn
it
into
a
task,
throw
out
the
original
value
test,
because
you
don't
want
to
touch
it
anymore.
From
this
point
onward
and.
C
C
That
is
sub-optimal
than
having
used
just
straight-up
tests
in
the
first
place,
I
think,
which
is
what
we
wanted
to
avoid
yeah,
I
mean
we're
walking
a
fine
line
here
like
I
I
get.
There
are
multiple
concerns
being
expressed
and
in
particular
like
we,
we
don't
want
to
encourage
developers
to
use
this
functionality,
because
it
necessarily
means
that
there
may
be
some
ongoing
operation.
That's
using
resources
that
gets
left
behind.
So
we
kind
of
we
don't
want
to
encourage
developers
to
do
it,
but
at
the
same
time
developers
do
do
it.
C
C
C
When
you
say
wrong,
is
it
functionally
incorrect
or
is
it
mainly
a
performance
issue?
It's
generally
a
performance
issue
in
that
they
leak
resources
about
it.
So
the
gc
will
eventually
kick
in
and
clean
them
up
that
their
application
wipes
tougher
well,
not
necessarily
like
timers
are
rooted,
so
these
timers
are
rooted
so
till
the
timer
fires.
It's
not
going
anywhere.
C
C
I'm
trying
to
think
if
there's
never
been
a
quote,
functional
issue
that
I've
seen
assuming
you
don't
consider
leaks,
functional
well,.
D
A
Proposal,
which
is
basically,
we
have
one
overload
of
configure
awaited
text
everything
that
you
can
do,
and
then
we
have
one
overload
per
simple
thing.
People
want
to
do
that.
Just
takes
one
thing,
because
it
seems
to
me
that's
kind
of
the
easiest
thing
for
us
to
evolve
and
it
kind
of
makes
the
call
sides
reasonably
understandable.
A
C
A
Well,
what
I
would
do
is,
I
would
have
one
overload
of
configure
await
that,
takes
everything
where
everything
is
being
defaulted,
including
the
continuum
capture
context,
and
then
I
would
add
two
other
overloads.
Basically
one
for
cancellation,
token,
non-defaulted
and
one
for
time
span
not
defaulted,
and
so
that
basically
no
means,
if
you
just
want
to
suppress,
you
know
either
you
know
capture
context.
You
just
want
to
have
a
time
order.
You
just
want
to
have
a
cancellation
token.
You
only
have
one
argument
you
have
to
pass
in.
A
If
you
want
some
combination
there
off,
you
have
to
deal
with
the
longest
one,
but
then
you
just
pick
the
ones
that
you
want
to
use
and
then
so
this
this
now
means
if
we
add
another,
you
know
a
fourth
thing:
let's
say
our
favorite
one,
the
you
know.
Fourth
async
one
we
would
say
yep
we
would.
We
would
basically
add
another
overload
that
takes
all
four
of
them.
Now
everything
being
defaulted,
the
previous
one.
We
remove
the
defaults
and
then
we
add
another.
A
H
C
G
C
A
I
mean
you
could
I
mean
we
could
also
have
a
very
low
tech
solution
to
this.
We
could
just
define
an
overload
of
configure
a
way
that
we
obsolete.
You
know
editor
browse,
never
detects,
no
arguments
right,
in
which
case
they
can
be.
They
get
a
warning.
If
they
do
it
right,
I
mean
that's
the
that's
one
way
of
doing
it.
A
I
mean
my
only
concern
with
basically
having
you
know,
force
people
to
pass
and
continue
to
capture
context
is
that
you
know
that
they
are
enough
to
pick
a
value
for
this
and,
like
you
know
what
they'll
be
confident
they'll
pick
the
correct
one.
C
A
C
C
But
there
is
yeah,
there
is
a
slight
difference
in
the
amount
of
how
expensive
are
any
of
these
awaitables
compared
to
each
other
steve,
the
cheapest
one
will
be
the
one
we
currently
have,
the
one
that
takes
a
await
behavior.
I
haven't
seen
eric's
latest
prototype,
but
I'm
pretty
sure
it
only
allocates
if
the
task
hasn't
completed
yet
and
if
it
has
completed
its
one
or
two
allocations,
one
of
which
is
a
timer
or
a
timer
to
timer.
C
The
the
size
of
this
truck
is
probably
it's,
I
think.
Well,
it
might
be
the
most
impactful
thing,
because
every
state
machine
that
uses
one
of
these
will
grow
by
the
size
of
that
that
struct
and
is
it
by
the
size
of
the
structure
by
the
size
of
the
struct
times
the
number
of
weights
by
the
size
of
the
struct
times.
The
number
of
unique
awaits
on
unique
types.
C
So,
if
all,
if
you
have
17,
awaits
all
on
task,
they're
all
going
to
share
the
same
awaiter
field,
if
you
have
an
await
on
task
of
hints
and
a
weight
on
task
of
double
and
a
weight
of
task
of
string,
you've
got
three
waiter
fields.
C
Dumping,
the
struct
and
doing
sorry
removing
suppressed,
extract,
suppress
exceptions,
removing
force
async
now
getting
rid
of
the
struct
and
making
some
version
of
long
configure
await
and
then
some
easy
versions
of
you
only
wanted.
One
of
the
three
things
seems
like,
I
think,
where
we
are
and
seems
fine
to
me.
C
So
I
just
summarized
it
was
we
had
two:
we
had
configure
weight
cancellation,
token,
configure
weight,
timeout,
configure
weight,
bool
equals
true
time
span
or
nullable
time
span
equals
null
cancellation
token
equals
default.
H
G
C
A
C
A
Mean
that's
fair.
We
can
always
default
later.
I
suppose
right
I
mean,
like
I
think
it's
it's
probably
like
for
the
current
proposed
ones.
It's
probably
fine.
If
you
have
to
pass
all
three,
because
you
only
call
this
because
you
want
to
pass
two
anyway,
you
might
as
well
just
give
a
value
for
the
third
I
mean
it.
It
will
be
interesting
if
we
do
the
fourth
async
one,
because
this
one
we
can't
realistically
add
as
a
as
a
as
a
you
know,
single
value
overload
because
bool
is
already
taken.
A
C
Yeah,
I
think
that
the
one
interesting
thing
would
be
for
force
async.
Unless
steve
can
tell
me
why
I'm
completely
wrong
is
if
we
can
make
task.yield
get
configure
await
false
behavior,
somehow
attached
to
it
that,
then
we
don't.
C
We
would
never
need
the
force
async,
because
the
answer
would
be
await
task.yield
false
it
would
actually,
it
would
actually
probably
be
a
weight
task.yield
I
misspoke
early
via
weight,
test.yield
and
then
and
then
await
foo
because
you're,
basically
at
least
as
defined
this
force,
I
think
would
have
ensured
that
the
well,
I
don't
know
it's
complicated
anyway.
G
C
We
there
are,
there
are
a
set
of
other
proposals
that
are
basically,
I
want
to
schedule,
a
continuation
to
run
somewhere.
I
want
to
schedule
a
continuation
to
run
on
the
thread
pool.
I
want
to
schedule
continuation
to
run
on
a
specific
stat
task,
scheduler
like
if
that's
something
we
want
to
go
and
explore
further.
We
can
do
that
separately.
H
J
J
C
And
we're
gonna
have
to
shoot
it
down
in
seven,
we'll
have
the
analyzer
that
says.
Are
you
sure
you
want
to
use
this
method?
I
mean
we.
H
C
Why
are
you
doing
this
here?
Are
we
are
going
to
need
to
make
sure
I
I
given
the
overloads
we're
talking
about?
I
don't
think
it
will
fire,
but
we
are
going
to
need
to
make
sure
that
the
the
analyzer
that
we've
added
that
says
you
have
a
cancellation,
token
make
sure
you're
passing
it
we're
going
to
need
to
make
sure
that
it
does
not
fire
for
this.
That
would
need
to
be
updated.
Yeah.
C
C
J
A
So
one
question
I
have
is
so
I
added
this
to
all
four
versions.
Is
that
correct,
so
for
both
tests,
tasks
of
t
results,
major
tasks
invade
the
task
of
t
results,
that's
correct
and
then
the
compiler
service
apis
remain
unchanged
right.
We
still
have
all
these,
it
only
struck
and
they
look
exactly
as
before.
Right,
that's
correct.
C
Yeah-
and
I
will
now
do
the
devil's
advocate,
even
though
I
literally
don't
care
what
the
answer
is:
async
innumerable
and
dispose.
They
think
not!
No!
Okay,
if
you,
oh
so
cancellation
token,
you
know
I
don't
want
to
money
the
waters
if
you,
if
you
want
to
add
a
cancellation
token
and
a
timeout
for
the
individual,
awaits
in
your
loop
or
in
your
dispose.
Like
I
that's
so
niche.
I
really,
I
think
we
should.
C
We
should
force
you
to
write
the
code
out
you
should
you
should
no
longer
use
a
way
for
each.
You
should
do
get
a
numerator
or
get
a
sync
a
numerator
and
while
move
next
async,
okay,
I'm
totally.
C
Especially
because
for
timeout,
if
you
have
a
timeout,
you
probably
are
tracking
elapsed
time
and
if
you
have
multiple
awaits,
you
probably
want
to
change
the
timeout.
That's
employed
on
every
await
to
be
to
factor
in
how
much
time
you've
spent
between
them.
It's
rare
that
you
say
every
await,
even
if
I
have
a
thousand
of
them
gets
a
minute.
You
want
it
to
be
the
first
one
gets
a
minute,
the
next
one.
You
know
I
run
for
a
second,
so
the
next
one
is
one
minute
minus
one,
second
and
so
on.
C
So
I
I
don't
think
we
should
do
that
and
cancellation
token.
I
think
it
gets
too
confusing
whether
the
cancellation
token
is
being
passed
to
the
await
or
to
the
enumerator.
C
Especially
because
we
already
have
a
with
cancellation
method
on
a
get
on
facing
numerables.
A
All
right,
so
I
posted
it.
Hopefully,
people
are
okay
with
what
I
wrote
hopefully
didn't
miss
anything
that
was
vital.
J
A
Right
so
then
I
think
that's
it
then
I
think
next
week
we
will
do
the
json
one,
because
the
we're
sitting
on
the
dom
apis
for
a
while
now,
unless
there's
something
else,
urgent,
that's
what
we're
gonna
do
all
right,
then
I
think
that's
it
for
today.