►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
This
seems
to
object
all
right
so
good
morning,
everybody
we
are
back
with
another
set
of
api
reviews.
Let's
start
with
this
one
here
who
wants
to
give
us
an
overview.
A
Oh
sorry,
so
the
it's
in
the
it's
in
the
invite,
and
I
think
it
should
also
pop
up
on
youtube
any
second
now,
basically,
what
is
shared
right
now
by
jeremy,
it
is
four
five,
six,
eight
nine
in
the
runtime
repo,
it's
the
add
runtime
api
to
load
too
hot
yeah
to
load
hot
reload
deltas.
B
Well,
I
guess
I
could
speak
on
it
either
me
or
lexi,
for
both
I
mean.
I
guess
you
just
want
kind
of
an
overview.
This
is
my
first
api
review.
B
Actually
at
the
higher
level,
hot
reload
is
the
ability
to
basically,
you
know,
change
your
code
without
actually
using
the
debugger
on
the
fly,
and
it
involves
a
bunch
of
pieces
which
it
starts
with,
like
a
like,
a
watcher
that
that
uses
roslyn
to
get
all
the
you
know,
a
file
watcher
or
something
to
watch
for
edits
in
the
project
then
uses
roslyn
to
build
these
deltas
based
on
you
know
which
assembly
you're
starting
with
and
then
some
ipc
to
send
it
to
the
target
process
that
now
calls
this
api
to
apply
the
edits.
B
It's
a
lot
like
the
api
is
a
lot
like
the
existing
enc
debugger
high
core
debug
apply
changes
or
pi.
I
think
it's
called
apply
changes
because
I
don't
know
multiple
api,
so
it's
similar
to
that,
but
it's
in
proc
and
it's
of
course
managed
yeah
and
that's
the
details
of
what
we're
proposing
right
now
and
it's
gone
through
a
lot
of
discussion
already
on
in
this
issue
I
mean
I
I
don't
know
I
did
go
to
a
lot
of
details,
but
I
don't
know
if
that's
enough
of
overview.
A
A
Yeah
because
they're
both
extensions
over
assemblies
right
yeah-
I
think
that's
that
makes
sense.
So
the
design
that
you
have
right
now
is
basically
just
talking
about
the
metadata
delta,
il
delta
pdb
delta.
B
Well,
I
guess
that's
just
the
way
a
delta
is,
I
mean
it's
sort
of
a
the.
The
actual
deltas
are
to
me
they're
kind
of
a
black
box
that
roslyn
gives
us.
I
mean
the.
D
B
Isn't
really
I
mean
it's
defined
in
roslyn,
I
guess
I
haven't
actually
ever
seen
a
spec
for,
and
it's
just
always
been-
you
know
divided
up
in
the
metadata
and
I
o
and
and
tv,
and
so
I
don't
know
if
I
could
go
into
any
more
details
than.
A
Yeah,
I
guess
my
question
is
more
like
is
that
is
that
kind
of
like
a
fixed
layout,
or
are
we
very
likely
to
you
know?
Eventually
we
add
one
more
overload
that
has
to
take
like
a
different
kind
of
delta,
but
as
long
as
we
are
confident
that
that
is
the
final
shape
you
want
and
we
think
span
is
good
enough.
Then
it
seems
like
a
fine
api.
B
Yeah
yeah
and
as
far
as
I
know,
it's
I
think
I
think
it
was
asked
even
on
the
issue
about
the
format
of
the
of
the
of
that
of
the
delta,
both
the
il
and
the
metadata.
A
A
We
added,
I
think,
in
five
old
times,
for
a
four
or
five
time
frame
or
whatever,
because
volcan
wanted
some
il
emit
apis,
where
they
basically
take
raw
bytes
rather
than
the
the
ref
emit
data
structures,
and
that
was
all
part
of
the
normal
ecmo
555
metadata
already
so
yeah.
As
long
as
there
is
a
documented
format,
and
we
are
confident
that
the
format
itself
doesn't
change
so
much.
I
think
it
seems
like
a
fine
way
of
doing
it.
C
Is
there
a
more
out
of
the
way
place
that
this
can
live
like
if
this
is
really
only
intended
for
the
the
ide
etc?
It
doesn't
really
need
to
be
an
extension
method
on
a
type
that,
yes,
we
don't
want
most
people
to
be
using
assembly
as
a
type,
but
if
you're
using
reflection,
it's
there.
A
A
E
F
C
Chat
suggests
and
sounds
familiar
to
me
that
the
newest
vs
intellisense
defaults
are
ext,
that
it
searches
all
reference
assemblies
across
all
namespaces
for
extension
methods,
and
this
starts
with
a
so
it'll,
be
at
the
top,
like.
I
think.
F
A
A
C
Api
you
accidentally
play
or
something
it's
just
one
of
those
like
is
you
know,
is
there
somewhere
other
than
an
extension
type
and
that
you
have
to
invoke
it
via?
You
know,
static
call
when
you
have
to
really
have
been
looking
for
it
to
find
it.
If
we
don't
think
that
there's
really
a
bad
ux
here,
I'm
just
relaying
questions
from
the
chat
in
case
no
one's
reading
the
text,
but
why
does
it.
E
A
I
guess
you
could
I
mean
my
question
would
be
like:
how
is
it
different
from
the
other
one
we
already
added,
which
takes
a
pointer,
which
is
arguably
worse
than
what
this
is
doing.
But
I
don't
know
like
I
mean
I
think
practically
if
we
do
that,
we
probably
have
to
find
a
type
for
this,
because
you
probably
wouldn't
want
to
ponder
on
assembly
extensions,
because
it
would
be
a
weird
place
to
put
it.
C
Yeah
I
mean
the
the
difference
from
you
know:
try
get
raw
metadata,
is
you
know
the
output
format
of
that
is
in
one
of
the
ecma
docs?
I
don't
know
if
this
one
is
like.
E
So
again
speak
about
the
format
id.
We
don't
have
the
format
explicitly
documented,
but
it's
by
the
extension
of
the
ecma
format.
I
basically
like
it
will
be
kind
of
half
a
page
to
the
exma
specs
to
describe
this
format.
This
is
referencing.
Everything
else
from
back
must
back
right.
So
fair
enough.
A
A
Well,
because
a
type
called
assembly
extensions,
it
kind
of
implies
that
it
houses
extension
methods.
I
mean
that's
part
of
the
reason
why
jeremy
generally
doesn't,
like
extension
methods
being
on
the
type
called
extensions,
because
it
limits
the
ability
to
make
static
methods
on
that
type,
because
it's
always
real.
C
A
C
A
Yeah,
I
I
guess
that's
fair.
I
mean
in
that
case
I
retract
my
earlier
comment.
It
just
seems
weird
to
me
that
we
have
do
I
get
one
matter.
That
is
an
extension
method
and
we
have
this
one
as
non-extension
method.
That
just
seems
odd.
I
mean
it
probably
doesn't
break
anybody
realistically,
but
it's.
It
just
seems
like
an
odd,
odd
choice.
B
Yeah,
actually
it's
that's
always
been
the
case
with
enc.
If
we
leave
it
up
to
rosalind
to
really
filter
out
the
root
edits,
I
mean
there
is
some
checking
on
the
you
know
if
the
format
is
just
way
off
or
invalid.
It'll
it'll
return
an
error
which
the
api
will
throw
an
exception,
but
in
general,
if
it's
what
we
call
a
root
edit,
if
we
leave
that
up
to
rosalind
to
detect
and
not
even
call
a
gun-
and
that's
always
been
the
case-
and
there
is
edits
that
will
cause
your
app
to
crash.
B
C
I
guess
part
of
my
the
feeling
that
I
have
that's
what
I
expected
and
it's
the
feeling
that
I
have
that's
a
little
different
between
try
get
metadata,
which
is
passive,
you're
you're
asking
for
stuff,
and
it's
giving
it
to
you,
and
this
is
an
edit
and
you
call
the
edit
and
you
give
it
gibberish,
and
now
the
process
goes
away.
It
just
feels
a
little
more
like.
Maybe
it
should
be
a
little
harder
to
call.
E
But
you
know
it's
not
that
different
from
assembly
load
file
right
assembly
load
from
stream
right.
If
you
pass
garbage
to
assemble
from
stream,
it
will
probably
fail
on.
You
know
that
file
format
exception.
But
if
you
kind
of
carefully
craft
the
garbage,
then
your
process
will
die
as
well
because
of
the
you
know,
right.
A
Yeah,
given
that
you
are
asked
to
provide
three
byte
arrays
that
have
to
pass
some
sort
of
validation
at
least
to
be
applicable
at
all,
like
you
would
almost
have
to
attack
the
process
right.
It's
not
something
where
you,
you
know
pass
in
three
innocent
strings,
and
then
you
know
the
process
suddenly
dies.
A
E
A
C
I
think
I
slightly
prefer
the
smell
of
having
a
non-extension
method
in
the
type
named
extensions,
given
that
we
don't
expect
people
to
call
it,
then
the
smell
of
this
shows
up
in
intellisense.
You
know
ever
so.
I
would
prefer
to
not
have
this,
even
if
we
leave
it
on
the
assembly.
Extensions
type.
E
H
C
A
J
Cool,
so
the
most
similar
api
to
this
for
and
what
this
api
is
is
we
have
a
read-only
sequence
of
bias
and
we
want
a
pipe
writer
to
be
or
sorry
pipe
reader
to
be
built
from
that.
Our
existing
api
is
pipereader.create
from
a
stream
instead
of
a
stream.
This
takes
a
read-only
sequence.
It's
also
conceptually
related
to
another
api
proposal,
which
was
create
a
stream
from
a
read,
only
sequence,
but
that's
been
backlogged
for
a
while.
So.
J
Yeah
and
if
you
guys
are
curious
about
the
others
here,
I
can
pay
seven
chat,
but
that's
not
what's
up
for
reviews.
So
basically,
the
purpose
of
this
api
is
that
when
you're
writing
tests
that
use
a
pipe
reader
and
typically
you're
writing
some
sort
of
parser,
you
need
to
fill
the
pipe
reader
with
data
and
today
you
knew
up
a
pipe
and
then
you
write
the
data
as
a
pipe
writer
and
that's
just
a
lot
of
ceremony.
It's
not
very
efficient.
J
A
J
Yeah
I
mean
you
could
do
that,
and
it's
also
useful
for
people
who,
just
assuming
that
you
started
with
the
read-only
sequence,
and
you
want
to
stream.
E
J
J
But
I
think
that
direct
conversion
makes
sense,
because
pipereader.read
async
is
going
to
return
that
read
only
sequence,
exactly
on
the
first
read
and
then
based
on
how
much
he's
like
continuing
examined
subsequent
reads:
might
return.
A
A
I
know
the
poster
having
this
a
api
as
well,
but
like
I
mean,
if
we
ever
add
the
other
api,
it
seems
like
we
should
also
make
sure
they
actually
bypass
the
in
the
live
stream.
If
you
can.
J
Yeah,
I
mean
that'd
be
nice
to
have,
but
you
know,
as
it
stands,
the
read-only
sequence
as
stream
api
doesn't
exist
yet,
and
I.
G
C
C
J
K
J
J
Maybe
yeah
so
that
goes
more
between.
So
I
haven't
like
looked
at
all
the
read-only
sequence
constructors
prior
to
this
api
review,
because
I
didn't
think
we'd
be
talking
about
that,
but
yeah,
I'm
not
sure
how
difficult
that
is
at
the
moment.
Like
you
said,
I
don't
think
it's
that
difficult
and
there's
no
like
perf
concern
like
the
manual
way
of
creating
it.
I'm
sure
would
be
fine
as
far
as
performance
goes,
and
I
don't
think
it'd
be
that
difficult.
A
C
J
C
C
C
A
read-only
memory
overload
in
the
future
would
be
a
compile-breaking
change,
because
now
you
would
have
two
possible
implicit
conversion
targets.
I
mean
we
could
solve
that
with
more
overloads
amusingly
but
yeah.
So
as
long
as
binaries
can't
go
to
sequence,
we
could
add
the
read-only
memory
thing
later
or,
but
until
then
somebody
can
just
say:
pipereader.creative
new
read-only
sequence
of
some
read-only
memory,
and
that's
this
isn't
the
type
that
everyone
interacts
with.
So
that
seems
fine.
J
So
yeah,
that's
the
other
thing
to
bring
up.
I
would
say
no,
so
the
pipereader.crate
from
stream
has
some
options
like
memory
pool
and
so
forth
that
aren't
relevant
when
you
already
have
the
read-only
sequence,
so
I
cannot
foresee
any
options
that
you'd
be
interested
in.
F
J
H
C
Okay,
so
we
have
some
very
horribly
named
types
in
in
crypto.
That's
just
a
given.
C
So
the
type
rfc
2898
derived
bytes,
which
is
implements
one
of
the
two
algorithms
from
rfc
2898,
the
other
one's
called
password
drive
bytes.
We
did
a
great
job
there.
Most
people
who
use
this
type
ins
instantiate.
It
call
it
once
asterisk,
meaning
sometimes
they
call
it
twice
and
then
dispose
it
and
it
turns
out
like
it's
just
a
pure
function,
and
so
the
proposal
here
is
to
add
static
versions
of
this
function.
C
The
the
asterisk
of
when
people
call
it
twice
is
our
because
we
have
an
instance
to
type
basically
runs
as
a
stream.
The
more
you
call
like.
So
if
you
call
get
one
sorry,
git
bytes
one
get
bytes
one
that
produces
the
same
two
byte
sequence,
that
it
would,
if
you
called
git
bytes
two
as
a
static
function.
It
wouldn't
do
that
because
it
has
no
notion
of
previous
position.
C
So,
as
for
the
scenario
in
asp.net,
we
actually
call
this
function
quite
a
bit
and
if
you're
calling
the
regular
streamified
function,
that
jeremy
mentioned
earlier,
where
you
instantiate
the
type
call
git
bytes
and
then
dispose
of
it,
paying
the
cost
of
the
internal
instance
to
maintain
all
of
that
state
for
you,
even
though
you
don't
need
the
state,
because
you're
just
going
to
call
it
once
and
then
be
done
with
it.
These
static
methods
are
considerably
faster
than
the
instance
methods,
because
the
static
methods
don't
attempt
to
maintain
that
state.
C
C
At
the
top
of
this
that
basically
there
are
two
main
functions
that
are
being
there's:
one
main
function
being
proposed,
which
is
it's
pbk
df2
of
a
password
assault,
an
iteration
count,
a
hash
algorithm
and
an
output
link
that
varies
of
the
password
is
bytes
or
a
string.
If
it's
a
string,
we
assume
utf-8,
but
the
algorithm
actually
runs
over
bytes
and
then
it's
and
spanify.
All
of
that
so
well,
it
looks
like
there's
a
lot
of
things
being
proposed.
It's
really
one
thing's
being
proposed
with
one
overload
and
then
spanified.
A
C
Well
then,
the
name
that
the
instance
has
is
get
bytes,
which
okay,
maybe
it's
not.
You
know
the
super
best
of
names,
but
there
you
know
we
have.
You
know
git
bytes,
you
know
derived
key
derive
like
there
are
a
lot
of
names
that
we
could
come
up
with
and
in
in
the
discussion
on
this.
No
one
had
a
good
name,
so
kevin
threw
up
this
straw,
man
and
I
shrugged
and
put
in
the
proposal.
A
C
I
feel
like
we
generally
don't
mix
static,
in
instance
overloads
in
the
same
method
group.
I.
D
C
Do
only
when
they
do
the
exact
same
thing,
and
these
don't
do
the
exact
same
thing.
So
it's
a
bit
weird.
A
But
why
do
you
care?
Because
I
mean
at
a
given
point
in
time:
the
user
only
sees
one
of
them
right,
because
you
either
invoke
it
on
aesthetic
or
on
an
instance
right,
and
if
you,
if
you,
I
think
on
an
instance,
I
don't
think
you
see
aesthetics
in
intelligence
and
so
same
thing
applies
that
if
you
invited
as
aesthetic
you
wouldn't
see
the
instance
one
so
at
any
given
point
in
time,
user
would
only
ever
see
get
by
it's.
You
know
either
takes
an
indoor.
It
takes
five
arguments
right,
which
I
mean.
C
A
Yeah-
and
I
think
fundamentally
like
if
you
invoke
it
as
aesthetic
it
kind
of
makes
sense
that
it's
not
streamed,
so
I
I
think
it's
kind
of
obvious
from
the
use
side
which
behavior
you're
getting
so
I
don't
think
you
would
be
super
confused.
I
mean
it
certainly
seems
weird
to
call
it
a
static
method.
A
C
So,
coming
coming
back
to
what
jeremy
had
mentioned
earlier,
rfc
2898
actually
defines
a
whole
suite
of
algorithms.
Of
that
suite
pbk
df2
is
one
member
of
the
algorithm
family.
In
theory.
In
theory
we
could
add
the
other
three
or
four
algorithms
onto
the
same
type
in
the
future,
and
the
naming
would
actually
make
sense.
We
would
call
them
pbkdf1
derive
bytes
or
pbmac
one
dot.
You
know
generate
hash
or
something
like
that
and
they
they
all
fall
under
the
auspices
of
rfc
2898.
granted.
I
don't
ever
see
us
doing
that.
C
C
Its
own
type
make
a
new
type
name.
That
does
the
same
thing
as
the
existing
type,
except
for
it
would
be
like
a
more
modern
implementation,
one,
that's
one
one
that
we
would
basically
tell
people
like
if
you
don't
need
to
use
the
rfc
2898
derived
bytes
type
at
all,
don't
use
it
use
this
other
thing.
Instead,
that
is
better
faster.
We
can
give
you
a
better
implementation.
A
C
C
A
C
Wasn't
even
looking
at
that
that
was
just
yeah
independent,
it's
apparently
the
obvious
thing.
A
C
Yeah,
so
I
think
in
my
in
the
notes
that
are
just
off
the
top
of
the
screen
that
is
when
I
was
like
here
are
the
reference
signatures.
I
had
just
called
it
pbk
df2
in
that
one.
C
C
C
I
mean
we'd
have
the
fun.
How
do
we
feel
like
casing
it
all
caps
or
just
capital
p,
but.
C
Indeed,
yeah,
so
I
guess
the
real
question
then,
is
if
we,
so
if
we're
just
going
to
name
it
as
a
static
verb,
pbk
df2,
do
we
want
to
make
a
new
type
to
hold?
It
called
key
derivation,
or
do
we
want
to
put
it
on
the
existing
type,
because
people
who
know
where
to
look
for
it
already
know
where
to
look
for
it.
A
D
A
So
in
that
case
I
mean,
I
think,
putting
the
existing
types
works.
For
me
I
mean
I
don't
know
enough
about
rfc
2898
if
that
to
know
whether
that's
a
good
type
name,
but
it
seems
a
bit
weird
to
say
that
if
that
is
housing,
a
bunch
of
algorithms,
it
would
be
more
logical
to
put
it
on
this
type
than
introducing
a
separate
type,
because
then
it's
like
well,
why
are
the
algorithms
on
this
one,
but
not
that
one
in
the
answer
as
well,
because
one
can
stream
the
other
one
can't.
C
Levi
out
of
curiosity,
do
you
know
what
else
is
on
the
key
derivation
type
from
asp
data
protection,
just
pbk
df2?
That's
it!
Okay!
C
Yeah,
like
I
think,
if,
if
we
get
to
a
point
where
we're
either
adding
other
things
from,
I
guess,
if
we're
adding
just
other
things
from
rc
2898,
we
can
keep
putting
them
on
the
same
type.
But
once
if
we
start
adding
more
static,
one
shots
that
then
maybe
we
would
just
take
the
hit
of
yeah
there's
two
ways
of
doing
this
and
see
also
reflection
and
and
duplicate
it.
C
C
A
So,
in
terms
of
the
actual
methods
you're
proposing,
my
understanding
is
that
the
first
three,
I
guess
are
all
no
sorry.
The
first
two
are
basically
giving
you
new
data
back
and
then
third
one
is
basically
the
normal
pattern
that
we
have
to
do
with
span
based
and
then
same
is
true
for
the
second
three
and
the
difference
there
is
just
instead
of
taking
them
expands,
you
just
take
them
as
strings.
I
guess.
C
D
C
C
A
C
There's
no
such
thing
as
the
destination
not
being
large
enough:
the
destination
can
be
too
small.
Zero
makes
no
sense,
but
the
algorithm
can,
I
feel,
like
it,
runs
up
to
two
to
the
53
minus
one
bytes
so
longer
than
you
can
have
a
span
with
the
current
version.
Of.Net.
C
C
A
C
E
A
C
I
mean
so
it
depends
on
what
you
mean
for
utf-8,
the
thing
that
we
do
with
the
text
right
now
is
we
run
it
through
encoding.utf8,
and
then
we
call
the
byte
one,
because
the
algorithm
is
only
defined
on
bytes.
The
reason
we
expose
the
byte1
is
platform
compatibility
with.
If,
if
someone
somewhere
had
a
pbk
df2
that
used,
you
know
unicode
instead
of
utf-8,
then
you
would
wouldn't
be
able
to
replicate
that
with.
A
Yeah,
I
guess
my
question
is:
if
somebody
wants
to
give
you
the
password
as
text
and
they
happen
to
use
utf-16,
then
the
existing
text
one
makes
sense.
If
they,
if
they
happen
to
have
in
utf-8,
then
there
would
be
a
functional
difference
between
you
know,
converting
that
by
that
utf-8
string
to
a
byte
array
versus
treating
the
utv8
string
as
a
byte
array
right.
A
I
see
yeah
well,
I
was
not
thinking
about
performance
right
like
if
we
wanted
to
optimize
the
utf-8
case,
and
presumably
we
would
like
to
have
a
method
that
takes
that
directly
but
yeah.
My
point
was
just
that
bytes
is
already
taken,
but
I
guess
that's
just
the
nature
here,
so
we
would
have
to
have
right.
D
A
Yeah
to
me
the
casing,
one
is
like
I
don't.
I
just
think
practically
speaking
casing,
wouldn't
matter,
because
you
would
find
it
if
you
just
search
for
it
and
yeah
I
mean
intellisense
will
fix
if
you,
if
you
don't
have
it.
It
just
seems
weird
to
go
all
caps
here
unless
somebody
feels
strongly,
but
it's
crypto,
so
either
one
will
work
right.
C
I'm
I'm
still,
you
know
putting
my
foot
down
on
it's
if
it's
three
or
more
characters
and
an
acronym,
it's
first
letter
capitalized
only
unless
it's
a
proper
noun.
A
A
D
Yes,
so
for
this
one,
if
you
remember,
we
have
activity
source
class
which
it
has
overloads,
is
called
start
activity
and
start
activity
is
just
creating
and
starting
the
activity
in
the
same
time.
So,
if
you
call
this
start
activity,
you
will
not
have
any
chance
to
do
anything
before
I
mean
like
before
starting
the
activity
we
got,
we
got
the
scenarios
that
some
people
need
to
make
sure
that
if
the
activity
started,
sorry
if
it
was
activity
created,
so
they
will
have
a
chance
to
add
some
stuff
to
the
activity
before
starting
it.
D
I
see,
and
of
course
I
mean
create
activity-
will
go
through
the
sampling
mechanisms
that
we
have
already
with
the
start
activity.
So
the
parameters
we
passing
here
it
would
go
through
the
listeners
and
the
listeners
at
the
end
will
decide
if
they
need
to
create
the
activity
or
not.
So
it's
possible
that
somebody
called
create
activity
and
they
got
null
if
nobody
interested
to
create
such
activity.
A
D
D
The
the
only
difference
between
these
two
overloads
that
proposed
is
is
a
parent
context,
so
one
of
them
is
taking
activity
context
and
the
other
one
is
taking
string
and
we
have
to
support
both
because
we
are
encouraging
people
to
use
activity
contacts
in
general,
but
in
the
http
cases
the
http
header
will
have
just
a
string,
so
they
need
other
overload
that
takes
string.
D
About
the
naming,
so
I
I'm
proposing
create
activity,
but
some
other
people
saying
that
we
should
be
explicit
about
the
naming
telling
like
no.
This
will
create
activities
that
is
not
started,
which
is,
if
you
use
lock
and
document,
they
propose,
create
unstarted
activity,
name
instead
of
create
activity.
D
C
C
It
will
save
the
when
someone
asks
for
the
well.
Why
can't
I
have
everything
except
the
kind
defaulted
like
I
could
with
start.
I
just
want
to
create
it
and
set
two
things
on
it
and
then
call
start.
Why
do
I
have
to
go
completely
rewrite
the
call,
so
I
think
we
should
just
use
whichever
pattern
we
think
is
the
right
one
for
start,
which
presumably
is
the
newest
one
and
use
that
as
the
basis.
D
D
C
C
D
C
So
maybe
I
think,
maybe
I
simply
think
we
should,
on
the
first
proposed
on
the
of
the
new
proposals
on
the
one
that
takes
activity
context
parent
context.
Maybe
we
should
just
default
that
one
to
null
and
now
you
have
a
two
argument
or
a
two
parameter
version,
and
then
they
can
be
expanded
as
needed,
and
then
I
don't
know
if
this
is
worth
actually
creating
the
proper
overload
that
doesn't
have
any
of
the
default
arguments.
C
That
is
the
recommendation.
Once
you
have
either
two
or
more
or
more
than
two.
I
don't
remember
what
we
said,
but
two
was
the
boundary
case
off
by
one
error.
Is
there.
D
C
Think
but
we
didn't
do
that
for
start,
so
maybe
we
don't
need
to
for
create.
I
don't
know
how
user-friendly
these
apis
are
supposed
to
be.
D
C
Well
simply,
we
we've
learned
from
usability
studies
that
there
are
people
who
get
confused
when
intellisense
shows
them
that
there
are
default
parameters
like
all
the
square
braces
and
the
signature
being
very
long,
and
that
that's
why
we
have
a.
I
don't
remember
what
strength
of
guideline.
It
is
probably
to
consider
that,
once
you
have
two
or
more
than
two
parameters
that
are
defaulted,
that
you
make
a
proper
overload
that
just
gets
rid
of
all
the
default
parameters.
F
C
A
D
A
A
I
mean
I
kind
of
agree
with
what
you
said
eric,
because
if
you
see
create
and
start
next
to
each
other,
I
think
it
will
be
obvious.
I
mean
if
unstart
could
be
a
verb.
That
would
be
probably
preferred
but
like
it
would
be.
You
can't
really
do
that,
but
you
can't
say
unstart
activity
that
would
be
very,
very
weird
so
and
create
unstarted
activities
seems
overly
viable.
A
C
If
the
activity
source
type
had
like
80
members
on
it
create
and
start
would
be
far
enough
apart
that
there
may
be
room
for
confusion.
If
somebody
does
the
dot
and
then
just
starts,
you
know
hitting
down
down,
but
I
think
there's
only
five
so
create
and
start
are
pretty
much
always
guaranteed
to
both
be
visible
to
you,
so
I
think
create
it.
Create
activity
as
a
sufficient
name.
C
A
C
But
I
I
don't
see
it
being
very
confusing,
since
we
explicitly
used
start
for
the
one
that
created
a
started.
D
Yeah
for
this
one,
the
proposal
here
is
just
adding
extra
prompter
for
the
overload
that
we
exposed
during
sex.
I
mean
it's
new
exposed
overload,
so
we
think
we
have
the
freedom
to
change
it
a
little
bit.
So
basically,
we
are
adding
what
we
call
it
id
format
to
it,
and
this
will
give
will
give
the
ability
to
choose
id
format
inside
the
activity
while
creating
and
starting
it.
D
D
And
unfortunately,
I
mean,
like
you
know,
in
dot
net
core.
The
default
is
w3c,
because
this
is
what
we
need
the
direction
moving
forward
and
then
the
whole
framework,
the
default
is
the
hierarchy,
so
we
have
different
defaults.
So
the
the
request
here
is
to
have
the
ability,
while
creating
the
activity,
to
specify
the
specific
format.
D
So
you
ensure
that
you
ensure
that
getting
that
specific
format
while
creating
the
activity
also
to
tell
more
about
like
we,
have
a
static
method
which
is
you
can
set
the
global
state
for
the
format
I
mean
you
can
specify
the
global
format
for
the
whole
process.
D
D
D
Sell
the
property
yeah
I
mean
they
I
mean
for
the
other
one
for
the
create
they
can
add
the
format
after
creating
it
before
starting
the
activity.
So
they
can
do
that.
So
we
don't
have
to
add
it
to
the
parameters
here.
But
for
here
I
mean,
like
you
know
it's
important
to
add
it
here
because
like
if
you
start
this
activity,
you
will
not
have
a
chance
to
set
the
id
format
at
the
time.
K
Yeah
so
technically
it's
enough
for
us
to
have
that
overload
from
the
previous
issue,
because
then
we
can
change
the
activity
edit
format
to
whatever
we
want
and
start
the
activity
later.
K
K
D
Yes,
I
mean
like
in
actually
we
were
discussing
another
issue
a
couple
a
couple
of
days
ago
regarding
this:
they
want
to
migrate
to
to
use
activity
source
instead
of
manually,
creating
the
activity
and
part
of
it.
They
are
getting
the
appearance,
they
are
getting
apparent
from
the
http
header
and
they
will
not
be.
D
They
will
not
be
ensuring,
like
you
know
what
they
are
getting.
It
will
be
always
w3c,
I
mean
it
can
be
darker.
So
so
I
think
I
think
yeah
I
mean
like
moving
forward
forward.
I
mean
we
should
we
should
recommend
w3c
all
the
time,
but
but
we
in
the
same
time,
I
think
we
should
still
support
the
old,
hierarchical
idea.
If
anybody
need
it.
D
C
Well,
the
the
previous
proposal
create
method
is,
I
guess,
is
this
a
nuget
package,
or
is
this.
D
C
Like
the
the
activitysource.createactivity
api
is
completely
new
if
it
wanted
to
always
use
w3c
instead
of
using
the
global
that
would
like
you
had
to
change
your
code,
you
should
have
tested
it.
K
A
A
A
Shorter
change,
but
that
means
you
have
to
upgrade
something
right
so
that
so
the
concern
is
always
when,
when,
when
you
like,
the
problem
with
full
framework
is
really
the
in-place
update
thing
where
you
haven't
really
done
anything
and
then
suddenly
your
app
has
new
behavior
right.
If
you,
if
you
have
to
rebuild
your
app
or
upgrade
some
package,
I
mean
I
mean,
presumably
you
test
it
for
your
ship,
that's
just
to
customers
right
and
if
you
don't
then
well.
A
C
C
It's
not
just
the
behavior
changed
or
simply
recompiling
with
no
changes
cause
the
behavior
change,
but
you
had
to
make
a
change
and
then
now
it
behaves
differently.
D
K
K
A
A
K
Just
to
give
you
some
context:
open,
telemetry
comes
and
changes
the
entire
global
static
default
for
all
apis,
like
in
its
study
constructor,
so
like
on
practice.
D
D
D
D
C
D
C
Callers
aren't
really
getting
the
the
convenient
syntax
benefit
because
they're
specifying
everything
they
may
as
well.
Do
it
in
three
lines.
So
if
you
it's
modifying
an
existing
thing
to
add
more
tweakables,
I
it
seems
fine
to
me,
but
if
you
yourself
don't
want
it,
then
I'm
fine
with
saying.
A
K
A
K
Say
that
like
if
we
had
the
previous
proposal,
I
wouldn't
follow
this
issue
and
outside
of
that,
look
at
it
as
you
like.
D
Oh
okay,
so
you
are
fine.
I
mean
like
to
use,
create
activity
yep,
okay,
so
I
I
was
saying
we
we
shouldn't
go
with.
D
D
A
D
A
D
A
A
C
C
So,
instead
of
before,
where
we
had
like
add
email
address
which
took
an
email
address
and
an
optional
encoding
type,
we've
simplified
it
such
that
all
of
the
easy
to
use
methods
now
just
take
the
string
value
and
if
you
want
to
do
something
complicated,
there's
the
add,
08
or
owed
value
value
and
then
a
nested
enum
of
which
encoding
type
do
you
want,
and
there
are
only
really
four
options
so
like
we
were
overly
except
like
we
were
going
to
throw
on
a
lot
of
inputs
from
the
previous
one.
C
This
one
is
like
these
were
really
the
only
legal
inputs
anyway,
and
we
did
it
as
nested,
because
we
don't
expect
anyone
to
really
ever
call
it
outside
of
you
know
me
kevin
and
maybe
levi
for
writing
tests.
C
A
Yeah
I
mean,
generally
speaking,
I'm
not
a
huge
fan
of
like,
if
you
I
mean
it,
it's
if
like
for
things
like
you
know,
struct
helpers,
that
are
part
of
the
pattern.
I
think
it's
fine
for
for
each
because
people
never
have
to
issue
the
type
name,
but
it
is
a
bit
weird
to
say
x,
509
distinguished
name
builder,
dot,
encoding
type,
but
it's
so
it's
quite
a
mouthful
to
type
right.
C
C
So
this
is
a
little
bit
of
ugly
for
the
0.1
percent
to
make
it
so
they
don't
just
shoot
themselves
in
the
foot
while
trying
to
do
it.
A
Sure
I
mean
I
I
mean
looking
at
the
name
space
I
mean
if
you
propose
a
top
level
tight
end.
That
would
be
fine
with
me
too,
like
if
you
call
that
I
don't
know
x509
distinguished
name,
encoding
or
something
it
seems
also
fine,
I
mean
the
natives
is
full
of
types
called
x,
509,
something
so
having
one.
C
C
Personally,
I
would
rather
not
have
it
than
have
it
as
a
another
top
level
type
sure,
because
the
encoding
types
aren't
really.
They
aren't
really
really
part
of
distinguished
name
builder.
They
really
come
from
asn
1
and
so
they're
really
system
formats,
asn
1
universal
type
number.
But
since
we
can't
expose
that
via
the
ref,
it's
here's
the
limited
subset
that
we're
the
only
legal
values
and
for
this
context
and
like
now,
you
don't
need
to
go
work
with
the
asn
writer
yourself.
C
C
This
the
enum
is
used
as
a
switch
on
a
set
of
encoding
classes
that
are
internal
to
system
formats,
asn
1
for
formatting
things
according
to
the
way
that
strings
are
formatted
in
asn
1..
The
easiest
one
is
utf-8
because
that's
utf-8,
I
guess
bmp
is
unicode
that
can't
leave
the
basic
multilingual
plane.
Sorry
ucs
ii,
yes,
bmp
string
is
ucs2.
C
C
But
the
thing
that
you're
testing
is,
if
I
use
the
asn
encoding
type
principle
string-
and
I
re
recover
this
after
sending
it
to
my
partner-
do
they
crash
because
they
couldn't
handle
a
printable
string
like
this
is
really
except
for
complicated,
interrupt
things.
This
is
really
a
test
generator
method.
A
I
mean
if
we
don't
really
care
about
the
enum
like.
Why
would
we
just
take
it
as
an
int
and
then
just
say
yeah?
We
only
support
the
wages,
0
12,
19,
20
and
30,
and
if
you
need
anything
else,
then
too
bad
file,
a
bug
like
if
you
really
think
it's
just
a
very
super
advanced
pass-through
api,
where
somebody
wants
to
do
something
super
advanced
and
might
as
well
just
take
an
end
right.
C
C
C
So
the
the
reason-
the
reason
I
asked
is
like
right
right
now,
like
the
simple
fact:
is
everyone
just
uses
bouncy
castle
for
stuff
like
this,
and
I'm
I'm
curious
as
to
what
qualifies
this
for
inclusion
in
the
core
sdk.
F
C
Where
we
can
take
either
a
string
or
the
x500dn,
sorry,
the
string
version
of
the
x500dn
or
the
or
the
x500
distinguished
name
object,
and
especially
once
you
end
up
with
the
possibility
of
having
quotes
inside
people,
mess
up
the
the
x
500
dn
building.
And
so
it's
making
it
easier
to
use
certificate
request.
C
C
C
I
I
see
that
kevin
wrote
that
at
the
very
beginning
of
the
issue
as
well,
but
I
I
was
having
a
little
bit
of
trouble
understanding
how
this
tied
back
to
existing
framework
functionality.
H
C
C
A
K
Hey
that's
mine
indeed,
so
basically,
this
proposal
stems
from
like
many
requests
to
basically
be
able
to
add
more
options
when
configuring
a
wearables
task
available
in
particular,
so
primarily.
K
Should
I
just
wait
until
you're
done,
you
know.
C
A
C
K
Okay,
I
mean
emo.
If
you
feel
like
it,
I
can
keep
going.
K
Sure
yeah,
so
basically,
we've
had
like
many
requests
from
people
to
be
able
to
expose
further
options
when
configuring
task
availables.
Currently
the
only
option
we're
exposing
is
a
flag
to
basically
disable
capturing
the
current
context.
K
K
So
this
is
basically
adding
a
bunch
of
more
things,
so,
first
of
all,
it
gives
users
the
ability
to
pass
a
cancellation
token
specify
a
timeout,
and
then
we
have
a
few
other
options,
for
example
suppressing
exceptions
forcing
asynchrony
when
the
you
know
always
sort
of
execute
the
continuation
asynchronously
and,
of
course
the
existing
continuum
captured
context
parameter
might
be
worth
pointing
out
that
the
cancellation
token
requirements
stem
from
a
request
to
provide
a
task
combinator
that
accepts
a
task
and
a
cancellation
token.
K
That
gives
back
a
task
that
has
cancellation
and
we
kind
of
decided
to
not
do
that,
and
instead
work
on
the
a
weightable
level,
because
I
guess
in
that
in
that,
in
that
case
the
api
more
clearly
communicates
the
fact
that
it
is
the
awaitable
we're
canceling
rather
than
the
task
itself,
which
you
know,
people
might
reasonably
expect
that
for
some
reason,
so
the
core
of
the
proposal
is
basically
exposing
a
new
struct
called
a
weight
behavior
whose
default
parameters
when
you
create
a
default
instance
are
as
specified,
and
then
you
can
just
you
know,
set
a
bunch
of
parameters
and
call
a
configure
weight.
K
J
Before
we
get
into
the
individual
parameters,
can
I
just
ask?
Is
there
a
reason
we'd
prefer
this
can
configure
weight
struct
as
opposed
to
like
separate
extension
methods?
Does
it
enable
like
new
capabilities
or
allow.
C
Things
to
be
written
in
a
better
way,
so
there's
two
things
you
might
be
asking
one
of
them
is:
rather
you
know
what
about
just
lots
of
different
overloads
of
configure
weight
that
take
various
combinations
or
you
might
be
asking
about
sort
of
the
the
with
cancellation
with
timeout
method.
That
takes
one
of
these
things
and
produces
a
new
task
for
the.
C
Is
there
one
of
those
that
you're
asking
about
or
something
else
both
actually
so.
C
One
of
the
reasons
we
sort
of
went
this
way
was
just
the
sheer
number
of
combinations
here
that
are
that
are
relevant,
or
you
know
one
overload
that
ends
up
having
just
a
ton
of
optional
parameters
and
so
kind
of
at
that
point,
you
kind
of
you
just
have
a
struct
and
you
can
you
can
specify
them
all
or
which,
whichever
ones
you
want
and
also
add
to
it
over
time.
If
there
are
additional
options
we
want
to
add,
we
can
add
them
here.
C
It's
pretty
clear
that
you're
configuring
the
await
operation
itself
with
cancellation,
whereas
if
you
say
task
dot
with
cancellation,
there's
a
fear
that
it
suggests
that
you're
actually
canceling
like
you're,
somehow
modifying
that
task
to
be
able
to
cancel
it,
and
so
there's
sort
of
a
user
experience.
Aspect
of
we
want
to
make
it
clear
that
that's
not
happening.
F
F
Yeah
yeah
yeah,
okay,
so
I
understood
it
correctly,
so
I'm
a
little
concerned
that
someone
using
this
api
might
confuse
that
and
put
their
cancellation
token
in
the
wrong
place.
K
I
think
that's
a
valid
concern
that
comes
with
this
type
of
api,
but
on
the
other
hand,
I
believe
everybody
has
at
some
point
found
the
need
to
do
this,
and
in
fact
we
actually
do
that
in
our
own
tests,
like
we
have
helper
methods
in
our
tests
that
implement
exactly
that
thing,
and
you
know
I've
had
good
reasons
to
use
this
in
the
past.
So
well
I
mean
there
is
this
risk
right.
F
I
I
almost
wonder
if
we
name
it
something
other
than
configure
weight.
I
do
know
yes,
these
are
valid
use
cases,
but
I
think
the
message
that
we
tell
people
is
your
operation
itself
should
support
cancellation.
It
should
support
timeouts,
and
I
just
worry
that
exposing
this
in
such
a
easily
viewable
standard
place
would
confuse
people
and
perhaps
cause
them
to
you
know,
have
very
inefficient
cancellation.
That
just
leaves
an
operation
hanging
out
there.
That
sort
of
thing.
C
So,
of
course,
we
want
the
underlying
operations
to
accept
the
cancellation
token,
and
we
obviously
won't
be
able
to
pass
it
there.
I'm
struggling
to
from
a
user
expect
experience
perspective
to
understand
the
confusion,
though,
with
the
await
aspect
like
it's
the
whole
config
the
reason,
because
the
name
configure
weight
was
actually
chosen
a
decade
ago
was
because
of
the
idea
that
we
wanted
to
make
it
clear.
Someone
was
actually
configuring
the
await
the
the
actual
weight
operation
and
not
the
underlying
task,
I'm
struggling
with
a
way
that
makes
that
any
more
clear.
F
No,
no,
I
understand.
I
just
know
that
this
is
something
people
have
trouble
with
today
and
if
we
add
something
that
increases
confusion,
that
that
concerns
me.
C
I
I
I
get
it
I
mean,
I
think
you
know
we
don't
want
to
make
it
more
confusing.
On
the
other
hand,
we
know
that
lots
of
people
do
this
in
a
lot
of
places.
In
fact,
the
number
one
use
of
task.one
any
is
to
implement
this
and,
what's
more,
they.
F
C
A
I
mean
the
one
thing
I
would
say
is
like
I
I'm
not
concerned
that
this
is
an
api
people
stumble
on
and
use
heavily
because,
especially
in
the
way
it's
proposed,
I
mean
I
have
a
hard
time
finding
a
way
that
is
more
ugly
than
what's
proposed
right
now,
right
people
already
hate.
F
F
If
I
see
this
new
overload
pop
up,
I'm
going
to
be
like,
oh,
I
can
put
my
cancellation
token
here.
Cool.
C
That
yeah,
we
can
also
we
can
try,
and
you
know
we
can.
We
can
ship
an
analyzer
to
say
you
know,
clippy
pops
up
and
says
you're
passing
your
cancellation
token
into
configure
weight,
but
the
the
task
you've
got
you
you're,
calling
await.stream.read
a
thing.
You
should
pass
your
cancellation
token
in
there.
Instead,
I
love
that
idea.
C
C
The
analyzer
that
says
you
had
a
cancellation
token.
We
will
already
warn
in
that
situation.
It
just
won't
be
warning
that
you
are
also
passing
it
into
this
configuration,
but
maybe
seeing
that
would
be
enough
to
to
move
it
or
maybe
re-update
the
fixer
for
that
to
remove
it
from
the
configuration
instead
or
so
I
don't.
K
Know
on
that
point
there
have
been
asks
in
this
thread
from
folks
to
basically
provide
sort
of
other
overloads
that
accelerate
certain
parameters,
so,
for
example,
a
configure
weight
that
you
know
only
accepts
a
cancellation
token
or
a
timeout.
I
take
it
from
this
conversation
that
we
might
want
to
avoid
that
approach,
because
it
might,
you
know,
offer
a
less
obtuse
way
to
pass
a
cancellation
token
to
the
waiter.
C
G
This
as
emo
said,
is
kind
of
the
ugliest
way
possible,
and
I
realize
it's
kind
of
intentional,
but
I
think
people
we
want
to
make
this
discoverable
to
some
extent
and
we've
made
it
almost
impossible
to
discover
without
somebody
you
know,
I,
I
have
a
feeling
we're
going
to
get
a
flood
of
of
posts
on
stack,
overflow
or
somewhere,
like
that.
That's
like
how
do.
G
C
I
guess
what
I'm
saying
is
why
why
we
think
this
isn't
discoverable,
I
I
actually
don't
think
it's
that
ugly.
I
mean,
maybe
maybe
it's
I'm.
You
know
off
the
eye.
The
beholder
in
my
eye
is
very
different,
but
it's
it's
spelling
out.
You
know.
Yes,
it
is
longer,
but
it's
saying
I
want
to
configure
this
await
operation,
and
here
is
how
I'm
configuring
it.
F
C
G
Yeah
I
mean
I
honestly,
I
don't
know
why
we
wouldn't
just
call
it
with
cancellation
or
with
timeout
they're,
always
going
to
have
the
potential
issue
that
somebody
confuses
what's
happening
and
passes.
The
cancellation
took
him
to
the
wrong
place,
but
I
you
know,
I
don't
think
we've
there's
a
way
to
eliminate
that
and
I
actually
don't
think
it's
that
big
of
a
problem,
because
most
people
are
simply
going
to
say
you
know
if
there's
a
cancellation
token
as
part
of
the
api,
their
first
option
is
going
to
be.
K
It's
worth,
if
you
have
exposed
this
api,
then
writing
a
correct
with
cancellation
like
method
becomes
a
one-liner
because
you
just
express
it
as
an
async
method.
C
F
Yeah,
I
agree
with
steven.
I
I'd
like,
I
think,
configure
weight
is
probably
the
best
option.
I
would
just
think
if
we
could
do
this
like
hide
it
extra
somewhere
in
some
static
methods
that
aren't
an
extension
on
these.
F
G
A
I
mean
one
thing
we
can
do
to
make
it
slightly
less
ugly,
like
I
I
I
mean
unless
we
assume
that
the
list
of
things
on
my
weight
behavior
will
be
50
at
some
point.
I
actually
think
it
would
be
better
to
just
have
overloads
of
optionals
and
then
just
do
the
intellisense
hiding
trick
remove
optionals,
if
we
add
more
things
to
it,
because
then
at
least
the
call
set
is
not
quite
as
robust
like
this
like
to
me.
A
A
With
the
with
corey's
concern
that
this
is,
you
know,
super
popular
api
place
because
you
know,
even
if
you
have
an
optional
parameter
with
like
three
or
four
of
them,
maybe
they
have
to
call
them
with
the
call
on
syntax.
I
think
that's
sufficient.
The
turn
for
people
to
not
just
accidentally
stumble
over
that
and
if
they
read
something
on
stack
overflow,
that's
just
plain
wrong.
Well,
there's
nothing
we
can
do
about
it.
Right,
like
like
wrong
advice,
will
always
be
wrong.
A
C
I
think
I'd
like
to
disagree
with
that.
I
think
we
should
do
this
and
then
consider
adding
simple
or
consider
adding
non-struct-based
overloads
for
convenience,
but
that
this
is
really
the
essence
of
and
and
talking
with
steve
in
the
past.
I
feel
that
that's
actually
what
configure
weight
was
supposed
to
have
been
originally
was
either
flags
or
a
struct
of
here
are
all
of
the
options
to
modify
how
a
weight
is
going
to
work.
I
C
But
that
he
lost
in
the
api
review
and
it
got
turned
into
a
boolean
and
that
this
is
this
is
the
way
forward.
If
we
add
five
more
options,
they'll
go
on
here
and
we'll
figure
out
what
convenience
overloads
to
add,
but
for
the
the
code
you
will
have
to
go
through
and
change.
The
least.
If
you
know,
if
you
have
a
in
my
library,
we
always
call
configure
a
weight
with
the
following
in
behaviors.
You've
defined
that
static.
Once
you
pass
it,
we
add
more
options.
You
change
that
you
pass
that
like
it.
C
I
think
that
we
want
the
struct
one
and
the
configure
weight
is
right.
In
fact,
for
everyone
who
doesn't
know
configure
weight
does
not
return
a
task.
It
returns
an
awaitable
but
the
which
is
where
all
the
widths
start
dying
immediately,
because
there's
now
nothing
to
bind
on
anymore,
but
the
yeah,
I
think,
yeah
it's
this
plus
convenience
overloads,
and
then
we
can
get
into
details
like
I'm
upset
about
the
default
of
continue
on
captured
context
and
don't
know
what
suppressed
exceptions.
C
Right
and
then,
when
we
add
another,
if
we
add
another
thing
in
the
next
release,
that
was
a
forced
overload
anyway,
and
we
may
as
well
just
add
destruct
and
again,
if
we
add
a
parameter
and
you
care
about
the
behavior
of
that
parameter,
you
have
to
find
every
call
site
and
update
it
in
the
next
release,
as
opposed
to
changing
the
one
static
struct
that
you
use
for.
This
is
how
my
library
does
awaitables.
G
Yeah,
I
disagree
with
that.
I
think
that
first
of
all
like
when
you,
when
you
throw
all
these
things
in
somebody's
face,
they
feel
like
they
need
to
understand
what
all
their,
what
all
these
are
going
to
do,
whereas
most
of
the
time
I
really
just
want
to
use
one,
and
maybe
two
of
these
things
right.
You
know
I,
the
by
far
most
common
thing
that
people
are
going
to
want
to
do
here
is
say,
add
a
calculation
token
or
add
a
timeout.
G
Now
you've
also
got
the
issue
that
well,
if
you
add
a
cancellation,
can
you
add
a
cancellation
token
and
a
timeout,
and
does
that
compose
I
mean
I.
I
think
that,
like
it's
much
easier
to
use,
if
you
have
and
again
we
can
call
it
configure
a
weight
with
cancellation
or
something
like
that
or
configure
a
weight
cancellation,
or
something
like
that.
I
don't
really
care
that
much
about
what
the
name
is,
but
I
think
I'd
much
rather
say
dot
configure
await
cancellation.
G
F
I
I
would
point
out
that
I
think
that
actually
needing
to
set
any
of
these
is
going
to
be
pretty
rare.
So
it's
probably
not
the
worst
thing
that
it's
a
little
ugly
to
use.
K
Okay,
I
had
another
question:
we
have
configure
a
weight
not
only
on
task
value
test,
but
also
on
is
incremental,
and
we
also
have
with
cancellation
method
there.
But
my
first
question
is:
would
all
of
these
apply
to
is
inconvertable
or
would.
D
K
Implement
configurability,
taking
away
behavior
on
highest
income,
numerable
and
other
some
other
configure
ways
that
I
don't
know
about
that
might
be
affected.
C
So
it's
worth
pointing
out
that
that
with
cancellation
is
it
actually
does
effectively
affect
the
enumerable
enumerable
in
that
it
whatever
you
pass
as
the
cancellation
token
there
is,
is
threaded
through,
so
that
that's
another
reason
in
my
mind
that
it
should
be
that
we've
we've
used
that
name
for
something
and
we
shouldn't
use
it
here.
K
K
C
F
C
I
don't
know
if
that's
a
good
idea,
because
if
say
that
you
wanted
to
mutate
one
of
these
things,
the
the
typical
way
that
you
would
do
it
is
because
it's
a
value
type,
you
would
say
var.
My
new
instance
equals
old
instance
and
then
my
new
instance
dot.
Some
property
equals
new
value.
Doesn't
that
fail
within
it.
H
H
C
A
A
H
Especially
if
we
think
people
are
going
to
create
this
in
statics
ever
then
they'll
likely
create
it
as
a
static
read
only
in
which
case
you
end
up
with
weird
behavior.
If
the
struct
is
mutable
and
you
try
and
mutate
a
value
because
it's
not
going
to
mutate,
like
you
think
it
does,
you
want
to
use
the
initializer
syntax,
which
is
also
why
we
recommend
don't
use
structs
and
if
you
do
use
trucks,
make
them
immutable.
C
A
I
mean
my
other
question:
is:
where
does
the
struct
actually
go
right?
Because
if
you
put
it
in
literally
task,
was
it
system
setting
tasks?
I
mean
the
name
only
has
a
handful
of
types
like
you
in
a
certain
way.
You
promote
this
concept
even
further.
By
doing
that,
but
that's
a
different
problem.
I
guess.
A
F
Yeah,
I'm
more
thinking
of
the
call
site
of
when
you
call
configure
weight.
The
the
difference
is:
does
this
get
passed
by
reference
or
by
value.
H
C
I
mean
depends
on
who
writes
it.
I
imagine
steve
would
get
it
down
to
two
longs.
C
D
C
F
K
F
Yeah,
I
think
in
practice
we
can
get
it
away
with
an
int
because
we're
just
going
to
transform
this
to
milliseconds.
At
some
point.
C
F
H
And
even
if
it
is
milliseconds,
we
track
time
time
in
terms
of
one
hit.
100
nanosecond
ticks
and
you
very
quickly
get
over
the
4
billion
marker.
K
I
mean
for
what
it's
worth
in
task.delay,
even
though
it
does
accept
a
time
span,
parameter
that
quickly
gets
converted
to
milliseconds
anyway.
So.
K
C
C
C
Yeah
I
mean
if
it
yeah
my
looking
at
it.
I
was
already
thinking
of
how
big
it
was
going
to
be
and
at
when
I
thought
it
was
too
long
on
linux
at
least.
I
think
it
would
just
pass
that
as
concurrent
registers
or
adjacent
registers,
but
if
we
packed
it
in
the
fields
tightly,
but
that's
not
worth
doing,
I
guess.
G
C
There
it
can
be
done
in
a
few
places.
One
of
the
things
that
we've
done
in
the
past
is
when
we
have
apis
that
takes
fans,
for
instance,
because
legit
doesn't
optimally
pass
span
across
an
abi.
What
we'll
do
is
we'll
deconstruct
it
back
into
a
ref
t
and
a
length
call
an
actual
workhorse
method
with
those
as
parameters
mark,
the
original
span
consuming
method
as
aggressive
inlining
and
then
from
the
code
gems
perspective.
There's
never
any
stacks
filling
going
on.
C
D
C
Be
I
could
be
wrong
in
this,
maybe
I'm
being
really
optimistic,
but
my
hope
is
that,
if
you're
using
this,
things
are
happening
that
are
way
more
expensive
than
anything
that's
happening
here.
So
if
you're
you're
setting
a
timeout
like
we're
going
to
be
creating
a
timer
if
you're
setting,
you
know
a
cancellation
token
we're
doing
additional
allocation,
at
least
for
the
async
completion
case,
if
you're
setting
suppressed
exceptions,
probably
because
you're
expecting
exceptions
to
be
thrown,
you
know,
so
my
hope
is
that
this
level
of
hyper
optimization
won't
matter.
G
Probably
true
in
general,
but
the
the
case
where
it
may
not
be
is
the
already
completed
case.
Sure.
C
C
Mentality
is,
if
someone
wanted
this,
you
know
this
functionality
for,
say
I
think
innumerable
ice
for
each
over
and
these
42
over
90.
Second
overall
is
just
an
expansion
into
a
you
know:
a
a
try
catch
and
a
while
move
next
loop.
Someone
could
always
do
the
expansion
themselves
and
then
use
this
on
the
individual
weights.
So
we're
not
like
blocking
anything,
but
we
could
certainly
make
that
easier
by
adding
the
overloads
there
too.
A
All
right-
and
so
what
I
heard
earlier
sorry
so,
basically
the
other
thing
is
the
the
signature
would
still
be
the
same
as
the
existing
configure
weights,
but
it
would
still
return
a
configured
task
away.
They
would
have
configured
major
tasks
available
and
I
think
what
I
heard
was
that
we
would
just
take
a
weight
behavior,
as
is
without
in.
K
Actually,
it
would
return
a
new
type
of
available
called
in
this
case.
Configured
cancel
cancelable
task
available
and
corresponding
a
waiter,
so
it
would
return
a
different
type.
A
C
C
Named
method
is
for
that
purpose,
but
you
don't
want
to
you
don't
want
like
this
is
the
any
usage
of
this
is
the
rare
case,
and
we
don't
want
to
below
the
common
case
with
a
much
larger
struct.
A
C
C
C
I
mean
I,
I
think
we
need
to
do
something
here.
I
think
this
is
gotten
to
the
point
where,
like
the
code,
people
have
to
write
without
this
support,
in
particular
for
cancellation,
timeout
has
become
just
really
really
messy.
You
create
a
new
something
and
you
call
a
weight
task
dot
when
any,
with
a
task,
dot
delay
that
takes
a
cusp,
a
new
cancellation,
token
source
that
you
created,
and
you
have
to
remember
to
dispose
that
and
you
check
which
one
test.
task.
C
when
any
returned
and
the
boilerplate
for
that
is
just
really
big
and
people
get
it
wrong.
They
forget
to
dispose
the
cancellation,
they
forget
to
cancel
the
cancellation
token
or
they
don't
pass
one
into
the
task
delay
at
all
and
then
you're
leaking
timers.
So
like
this
feels
like
we
need.
This
is
really
the
right
time
to
do
something
about
this.
C
I
do
believe
configure
weight
is
the
right
way
to
do
it
from
a
naming
perspective.
If
later
on,
we
find
some
one
percent
case
where
someone
really
did
want
to
pass
around
a
new
task
that
contained
the
time
out
of
the
cancellation
token
as
well.
We
could
always
add
those
two,
but
I
do
think
the
99
case
of
what
we've
seen
people
want
this
for
is
just
directly
awaiting
I
care
less
about
whether
it's
optional
parameters
to
an
overload
or
a
struct.
C
I
don't
think
we're
going
to
be
adding
a
ton
more
to
this,
but
I
wouldn't
be
surprised
over
the
next
few
releases.
Another
few
things
trickled
in
we've
already
had
a
couple
issues
open
for
people
wanting
additional
things
in
there.
C
So
that's
why
I
think
what
that
sort
of
logic
is
why
we
landed
on
the
struct
if
we
want
to
pass
it
by
hand,
I
think
that's
fine.
If
we
want
to
expand
this
now
or
later
for
innumerables
and
disposables,
I
think
that's
fine,
but
I
don't
think
it's
critical
any
passing
by.
C
C
K
C
If
it's
not
read
only
would
be
the
wrong
thing
to
do,
sir
yeah.
So
what
one
benefit
of
in
is
that
it
allows
you
to
chain
right.
So
if
you
have
a
method
that
takes
in
my
struct
that
calls
another
method
that
takes
in
mice,
trucks
like
you
can,
the
runtime
can
literally
just
pass
the
same
ref
under
covers
over
and
over
and
over.
You
can't
do
that
with
a
with
regular
bivalve
semantics.
C
H
The
the
the
main
harm
within
is,
if
it's
not
read
only
you
can
easily
get
into
situations
where
you
cause
hidden
copies
that
can
partially
be
solved
with
mutable
structs
by
marking
individual
methods
as
read-only.
Likewise,
there's
sometimes
confusing
semantics,
because
c-sharp
decided
to
not
require
in
at
the
call
site,
meaning
you
can.
H
You
can
still
call
this
via
like
new
new
configuration
without
having
to
create
an
explicit
value
and
then
pass
by
in
so
you
can
get
into
some
weird
scenarios
where
you
think
you're
passing
a
particular
thing,
but
you're
actually
passing
a
a
a
copy
of
that.
C
Only
I
do
have
one
other
concern
we
haven't
talked
about,
but
we're
also
over
time.
You
know,
should
we
keep
going
or-
and
I
think
we
should
resolve
this
because
we're
very
close
to
it
now.
Okay,
one
other
issue.
I
have
is
specific
to
the
suppress
exceptions
thing.
So,
basically
the
suppress
exceptions,
option
which
is
important,
because
I
mean
it's
something
well,
it's
something
people
have
frequently
asked
us
for
with
tasks
in
particular
the
that
basically
means
that
someone
goes
back
afterwards.
C
You
see
you,
you
await
task,
dot,
suppress
exceptions,
and
then
you
check
the
task
manually
afterwards
to
see
if
it
failed
or
not,
and
you
do
something
custom,
you
usually
use
it
because
you
want
to
avoid
throwing,
and
so
you
want
to
be
able
to
check
manually,
that's
fine
for
test
for
value
task,
that
one
in
particular
means
that
we're
encouraging
you
to
check
the
value
task
after
you've
already
awaited
it
and
in
general,
that's
a
no-no.
C
So
we
can
deal
with
that
by
saying
well,
suppress
exceptions
is
special
and
the
implementation
won't
have
actually
kind
of
completed
its
weight
on
the
task.
You
you
sort
of
it's
up
to
you
to
call
you
know,
to
get
the
results
or
get
the
exceptions
from
it,
but
a
we
don't
expose
a
dot
exception,
property
on
value,
task
and
b.
C
C
If
that's
the
use
case
yeah,
I
was
also
going
to
ask
what
it
does.
If
the
t
is
a
non-nullable
value
type
just
default
of
t
yeah,
it
would
be
default
for
t,
so
basically
the
flow
would
be
you've
awaited
and
then,
if
my
answer
is
default
of
t
in
value
task,
you
still
don't
know
if
that
was
because
it
succeeded
or
not
and
asking
the
question
is
violating
the
contract
right
so
that.
F
C
C
G
C
C
Reason
I
bring
up
is
even
though
I
was
promoting
the
struct
route,
in
which
case
we
would
be
sharing
the
same
struct
between
task
and
value
task.
If
we
didn't
go
the
struct
route
and
we
instead
went
to
just
have
a
bunch
of
optional
parameters,
the
configure
weight
we
exposed
for
value
task
could
just
not
have
suppress
exceptions
that
could
just
not
be
an
option.
C
G
A
A
C
A
C
K
C
Is
probably
really
only
true
if
you're
trying
to
do
you
know,
force
async
or
whatever,
and
so
maybe
you
have
like
three
different
options:
you've
predefined,
but
that
you've
you're
making
it
easier
to
read
because
you've
named
the
thing
instead
of
like
great.
This
took
six
lines
of
code
because
I
hit
my
terminal
links
with
every
single
one
of
these
property
names.
A
Yeah,
I
would
have
probably
just
defined
another
extension
method
over
task
of
a
task
and
do
basically
what
you
just
described
in
there,
but
yeah
I
mean,
because
I
mean
I
think,
people
who
take
offense
to
configure
a
weight
or
to
take
offense
to
the
longest
of
the
of
the
the
method
name
itself.
So
I've
seen
people
doing
configure
weight
faults
as
an
extension
method,
so
they
can
save
like
20
characters
because
they
use
it
freaking
everywhere.
A
But
I
think,
based
on
what
steven
said,
I
think
the
idea
is
you
would
not
use.
You
know
these
advanced
options
on
every
single
async
await.
You
would
do
it
like
in
very
specific
places
where
you
probably
want
very
specific
behavior
right,
where
maybe
the
stashed
weight
behavior
doesn't
help
you
because
well,
there's
a
particular
cancellation
token,
a
particular
timer
that
you've
got
from
an
argument
which
you
now
have
to
use
right,
in
which
case
you
probably
have
to
you
know.
You
know.
I
think
the
best
you
can
do
is
now
define
the
extension
method.
C
Yeah
once
it's
yeah,
once
it's
custom,
behaviors
like
that,
each
call
is
either
going
to
just
use
the
classic
configure
weight
false
or
is
going
to
have
different
values.
For
each
of
these,
then,
the
to
me,
the
struct
argument,
goes
out
the
window,
because
reusability
across
multiple
calls
was
the
benefit
ahead.
To
me.
A
Yeah
to
me
the
big
argument
of
not
using
the
weight
behavior
structure,
so
we
don't
have
to
put
it
in
the
task
in
space
because
it's
relatively
clean,
it
seems
like
it's
a
utilitarian
type
that
we,
you
know
putting
on
everybody's
face.
The
only
dancer
with
that
option
is
now.
We
have
basically
four
configure
weight
methods.
You
know
not
even
thinking
any.
A
H
Then
they
start
causing
it
because
they
all
become
passed
by
reference.
Basically,
if
you
hit
a
get
over
five,
I
think
it
is
on
all
platforms.
A
K
C
F
I
C
K
A
Now
I
think
to
me
to
a
certain
extent,
the
problem
that
we
have
here
is
intrinsic
right,
because
you
you
there's
a
difference
between
the
operation
and
the
awaiting
set
operation,
and
I
think
that's
just
yeah.
We
can't
really
hide
that
entirely
and
I
think
to
stephen's
earlier
point.
I
think
we
have
to
establish
configure
weight
terminology
which
is
the
best
attempt
we
had,
but
I
don't
know
to
me
renaming
cancellation
token
into
something
else
is
just
you
know
you
make
it
even
harder
to
describe
what
you're
doing
there.
K
A
A
Like
I
mean
the
the
one
downside
of
strapping,
the
type
is
that
you
definitely
don't
get
in
behavior
right
at
that
point,
you
basically
have
to
either
have
specialized
overloads
or
just
lift
with
the
fact
that
you
pass
12
arguments
all
the
time
right
I
mean
I
kind
of
buy
steven's
argument
that
some
of
the
ex
operations
here
are
so
expensive
that
it
probably
doesn't
matter
but,
like
you
certainly
make
it
now
really
hard
to
do
the
optimization.
C
Based
on
steve,
pointing
out
the
difficulty
of
suppress
exceptions
with
value
task
and
now
the
type
can't
be
used
across
the
two
I
mean
we
can
make
two
types,
but
I
I
think
that
I'm
now
in
favor
of
it's
just
parameters
and
we
make
the
overloads
as
we
see
fit,
for
a
combination
of
perf
and
usability.