►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello,
everyone,
it
is
10
a.m,
ish,
redmond
time
on
a
tuesday.
So
it's
time
for
more
api
reviews.
A
We
have
a
return
to
a
blocking
item
that
we
may
or
may
not
finish
in
a
two-hour
window
and
someone
who
shall
remain
anonymous
unless
they
anonymize
themselves
decided
that
we
needed
a
gavel.
So
I
called
this
meeting
to
order
all
right
rate
limit
apis
five,
two:
zero,
seven
niner.
B
Okay,
so
I
think
to
kind
of
start
off
is
so
the
two
main
changes
since
the
last
api
review?
Are
I've
changed
a
bunch
of
names
to
center
rate
limits
and
things
that
make
sense
for
rate
limits
and
changing
the
permit
leads
from
a
struct
to
a
abstract
class
which
mitigates
a
bunch
of
the
issues
we
identified
last
time.
So
not
sure
if
we
want
to
take
a
look
over
everything
or
we
just
want
to
look
at
those
specific
changes.
C
So
what
might
be
helpful
is
repeating
what
you
said
yesterday,
email
like
what's
the
plan
for
six
and
then
I
think,
maybe
we
can
maybe
just
to
prove
what
you
currently
have
under
the
you
know,
with
the
caveat
that
it's
a
preview
right
and
then
we
can
maybe
adjust
names
as
as
we
progress
or,
for
example,
maybe
if
you
have
more
performance
measurements
and
you
come
back
and
say,
hey
the
class
was
a
mistake.
We
allocate
too
much
on
hot
paths.
B
Yeah,
so
in
terms
of
the
plan,
just
fyi
is
that
we
started
to
review
all
of
our
commitments
for
60,
and
this
was
identified
as
a
potentially
risky
item
and
we
didn't
want
to
rush
the
design
or
the
implementations,
because
we
want
to
still
have
a
high
quality
release.
So
the
decision
there
is
that,
instead
of
shipping
it
as
part
of
asp.net
core
in
6.0,
we
will
be
shipping
it
as
a
preview
package
out
of
band
out
of
asp
labs.
But
we
will
still
preview
these
abstractions.
B
C
C
B
Sounds
good,
so
I
think
just
to
start
that
conversation
off
from
last
time
when
we
discussed
the
namespace.
The
proposal
then
was
to
put
it
under
system
runtimes
and
it'll
be
a
new
sub
area
under
that.
So
what
I've
currently
put
in
the
proposal
is
system.
Runtime
rate
limits,
any
thoughts
about
that.
E
E
A
G
I
mean
the
reason
I
originally
suggested
system.
Threading
was
because
there's
sort
of
two
categories
here
right,
there's
the
the
concurrency
limiter
one
and
the
key
example
there
is
semaphores
and
that's
all
about
concurrency
is
all
about.
We
sort
of
we.
We
merge
the
concepts
of
threading
and
concurrency
into
one
name:
space
called
threading,
even
though
lots
of
stuff
related
to
concurrency
isn't
exactly
manipulating
threads,
so
concurrency
kind
of
fits
there
and
then
for
all
the
rate
stuff.
G
It's
all
you
know
timers,
and
you
know
how
many
things
are
allowed
to
happen
within
a
given
period
of
time.
We
also
have
that
in
threading,
so
it
seemed
like
all
of
this
stuff
sort
of
naturally
maps
to
that
same
category
stuff,
even
though
the
concept
of
thread
doesn't
show
up
here.
C
I
mean
the
question
is
like
I
think
the
reason
why
I
suggested
this
one
time,
because
I
looked
over
all
the
other
names
and
no
other
names
fit
and
usually
like
we
try
to
avoid
adding
you
know
top
level
name
spaces
unless
there's
a
really
new
concept
that
that
deserves
that,
and
so
I
would
agree
that
threading
or
maybe
run
time.
But
if
nobody
else
likes
one
time
then
maybe
it's
just
threading
are
the
only
really
good
candidates.
B
Yeah,
so
it's
I
mean
it's
very
often
related
to
io,
but
theoretically
it
doesn't
have
to
be
specific
to
ios.
A
Yeah,
so
I
rate
or
threading
makes
sense
to
me
it
for
the
reasons
that
steve
said
it's
that's
where
we
put
all
of
the
stuff
that
has
to
do
with
the
notion
of
time,
time
passing
and
two
things
contending
for
the
same
resource
and
that's
if
we
go
back
to
the
previous
name
of
this,
it's
you're
both
asking
for
the
same
lease
and
one
of
you
gets
it,
and
one
of
you
doesn't
so.
C
A
G
Have
in
here
is
concepts
about
rate
limiting,
and
maybe
I'm
maybe
john.
You
can
tell
me
if
I'm
wrong,
but
for
tasks
and
channels
like
those
are
really
one
type
in
each
of
those
namespaces
and
then
a
whole
bunch
of
types
that
are
in
support
of
that
one
type.
Whereas
here
it
feels
like
there
are
multiple
abstractions
and
multiple
concrete
implementations
of
those
abstractions
and
factories,
and
so
it's
more
like
a
whole
bunch
of
things
that
are
working
together
as
a
system,
whereas
other
namespaces
is
like
one
thing
and
a
bunch
of
things
supporting
it.
B
B
There
will
be
different
implementations
of
them,
which
are
public
as
well,
so
in
terms
of
like
supporting
one
class
or
not,
I'm
not
sure
how
to
interpret
that,
because
in
in
the
ray
limiter
case,
for
example,
there
is
that
rate
limiter
like
main
abstraction,
but
there
will
be
several
implementations
of
it.
Is
that
similar
to
the
case
for
channels?
I'm
not
to
certain?
I
mean.
G
G
So
but
it's
you
know,
this
is
we're
talking
about
ing
versus
s,
so
it's
not
the
the
biggest
deal
to
get
a
perfect
parallel
drum.
C
I
mean
if
we,
if
we
wanted
to
go
that
path
of
the
plural,
then
I
would
probably
call
it
rate
limiters,
because
the
core
type
is
rate
limiter,
not
a
rate
limit,
but
I
think
then
I
mean
you
could
say,
given
the
types
that
you
have
here,
that
the
core
type
is
rate
limiter
and
everything
else
is
in
support
of
that.
That's
probably
not
completely
crazy,
but
it
seems
that
effectively.
C
It's
always
two
things
that
somebody
would
have
to
deal
with
by
the
rate
limiter
and
the
permit
lease
right,
and
somebody
who
extends
that
would
always
extend
both
of
them,
which
right
I
mean
to
a
certain
extent.
I
yeah,
I
think,
to
me
rate
limiting,
makes
a
bit
more
sense,
because
I
feel
like
once
you're
done
with
all
your
abstractions
and
your
utility
types
that
you
will
add
over
time.
C
G
B
B
B
That
will
depend
on,
I
guess
some
of
the
support
we
want
to
provide.
I
don't
I
haven't
proposed
any
factory
kind
of
patterns
yet
because
so
far
it
seems
like
every
specific
implementation
should
just
be
newed
up,
but
if
we
take
a
look
at
the
specific
implementations
and
feel
like
they
need
factories,
we
might
do
that,
but
but
I
I
would
say
that
right
now,
let's
assume
that
there
is
no
factory
and
you
just
knew
up
the
individual
rate
limiters.
B
E
G
G
Opinion
I
was,
I
was
asking
purely
because
I
think
it
was
either
eric's
point
or
maybe
jeremy's
point.
You
know
when
you
use
system,
threading
tasks,
the
99
cases,
you
type
task
dot
and
then
for
channels
it's
channel
dot.
I
was
wondering
if
there
was
a
similar
thing
here:
rate
limits
and
then
rate
limiter
and
then
rate
limiter
dot
whatever,
but.
B
Yeah,
I
think,
for
now
that's
not
going
to
be
the
case
so
ray
limiting,
does
sound
more.
I
guess
appropriate.
E
C
H
C
C
D
C
B
To
have
them
separate,
so
I
think
the
difference
there
is
whether
you
have
overloads
of
a
choir
versus
having
extension
methods.
Is
that
yeah?
B
I
mean
I
I
didn't.
I
don't
really
have
a
great
answer
to
that,
but
is
there
a
preference
for
one
over
the
other?
Yes,
you.
C
So
I
think
the
reason
why
I've
seen
it
in
asp.net
is
people
very
often
think
of
this
as
layering
as
in.
If
I
can
implement
it
outside
the
type.
I
should
I
kind
of
don't
subscribe
to
that
model
because,
first
of
all
like
that,
might
change
over
time
and
then
you're
just
limiting
yourself
if
you're
outside
the
time
and
then
secondly,
because
when
you
build
an
extension
method,
you
you
by
definition,
need
yet
another
type.
C
B
C
B
Our
usual
pattern
is,
if
it's
like,
I
guess,
extensions-
are
almost
thought
of
as
syntactic
sugar
right,
which
we
believe
that
these
were
because,
essentially
it's
not
part
of
the
core
functionality
that
you
need
to
write
in
implementation.
B
But
again,
if
we
want
to
make
those
to
be
just
another
method
on
rate
limiter
and
permanent
leads
themselves.
That
has
a
you
know:
virtual
implementation.
If
that's
the
pattern,
that
is
preferred
and
not
a
runtime,
I
can
make
that
change.
C
C
You
don't
implement
them
every
single
time.
I
mean
default
parameters,
work
to
a
certain
extent,
but
in
this
case
you
could
probably
also
make
it
a
default,
but
you
just
say
the:
what
is
it
the
count?
Whatever
is
defaulted
to
one?
That
would
also
work,
but
I
think
the
the
the
general
pattern,
I
think
so.
C
The
downside,
with
extension
method,
is
just
the
amount
of
moving
pieces
right
and
the
discoverability
right
if
you're,
actually
looking
at
the
dock
page,
it's
just
shittier
when
it's
extension
methods,
because
they're
they're
like
far
away
right,
they
have
they're
in
their
own
category
of
extension
methods
at
the
very
bottom.
Usually
so,
when
you
look
at
one
method,
you
don't
see
them
as
overloads,
so
people
may
not
discover
them
and
then
sometimes
you
put
them
in
different
name
spaces,
and
you
don't
even
see
them
so
like
it's
a
it's
just
like,
I
think
for
me.
C
Extension
methods
make
sense
when
you
add
glue
between
different
technologies
and
they,
you
know,
for
example,
immutable
array
and
link
curious,
for
example,
makes
sense
to
have
them,
as
extension,
methods
in
a
separate
namespace,
but
like
for
things
that
are
in
the
same
name.
Space
and
logically,
are
less
just
overloads.
I
would
just
make
them
regular
methods.
It's
just
easier.
C
B
Yeah
just
one
thing:
I
want
to
double
check
in
terms
of
like
breaking
changes
and
stuff
so,
for
example,
for
perm
lease
extensions
that
is
essentially
kind
of
related
to
the
curated
set
of
metadata
names,
and
if
we
were
to
add
one
later,
adding
these
overloads
should
be
considered.
Non-Breaking.
A
H
A
Method,
yeah,
anything
that
isn't
that's
non-virtual
is
the
same
as
the
same
breaking
scope
as
an
extension
method.
Basically,
so,
if
you
could.
C
Okay,
yeah,
we
don't
really
have.
I
mean
the
only
difference
between
extension
methods
and
instance.
Methods
is
that
instance,
methods
trump
extension
methods
right
so,
but
if
they
both
ship
in
the
same
assembly,
it
makes
no
difference
right.
Your
your
scope
is
the
same,
no
matter
what
I
mean.
I
would
generally
assume
that
you
know
everything
is
up
for
breaking
changes
here
right
because
you
ship
your
first
version,
you
will
get
feedback,
you
will
probably
change
something,
and
so
I
would
just
keep
my
options
open
here
and
say:
yep.
C
Right
I
mean
we
generally,
I
mean
you
can
imagine
cases
where
somebody
breaks,
because
you
had
an
overload.
We
generally
don't
accept
that
as
an
as
a
reason
to
not
add
an
overload,
I
mean
unless
we
know
that
that
common
call
sides
will
now
be
ambiguous,
but
like
there
are
cases
where
you
had
an
overload
that
took
an
object
and
you
had
another
block
that
takes
another
class
right
and
now,
if
somebody
passed
another,
no
it's
ambiguous
or
something
we.
We
generally
don't
care.
C
J
C
And
any
change
you
have
is
usually
source
breaking,
not
binary
breaking
right,
because
the
compiler
breaks
in
the
actual
method.
So
you
know
if
and
if
the
source
doesn't
recompile,
then
it's
you
know
the
danger
is
much
lower
right.
It's
like
worst
case
the
person
has
to
insert
a
cast
number
right,
which
is
also
not
the
end
of
the
world.
H
Right
right,
yeah
I'll
make
note
of
that
extension
methods
to
instance,
methods
so
yep.
A
Cool
all
right,
there's
a
method
called
available
permits,
that's
lacking
a
verb,
so
it
should
be
get
available
permits.
I
B
I
think
I
didn't
quite
get
that
name
incorrect
after
changing
it
from
a
property
to
a
method,
so
I'll
have
that.
D
C
B
So
I
think
the
reason
why
I
used
to
have
as
a
property
is,
I
believe,
semaphore
has-
was
a
current
count.
That's
a
property,
I
think
so.
So
that's
originally
how
I
kind
of
modeled
it
but
yeah
using
it
or
changing
it
to
a
method
is
not
the
end
of
the
world
either.
I
A
So
permit
count,
negative
permit
counts,
don't
make
sense,
so
there's
going
to
be
an
argument
exception.
So
by
using
template
method
pattern,
all
implementations
will
correctly
throw
for
negatives
and
then
no
one
needs
to
validate
it.
D
B
So
the
question
depends
on
the
implementation.
I
I
don't
see
a
scenario
where
negative
makes
sense
like
can
you
even
do
the
same
thing
on
a
semaphore
like.
H
Acquire
negative
numbers
we
do
want
the
ability
to
express,
put
back
in
the
future.
B
That
would
be
done
via
additional
apis,
I
think
so,
essentially
for
rate
limiters
or
let's
talk
about,
for
example,
a
concurrency
limiter
implementation.
B
So
how
it's
done
is
that
there
is
a
private
release,
method
on
it
and
the
permit
lease
that
is
returned,
we'll
call
that
private
method,
but
this
is
not
exposed
to
the
like
user
publicly.
So,
like
users
can't
call
release
on
a
limiter
themselves
and
essentially
that
that's
something
we
kind
of
want
to
prevent.
A
B
Support,
I
think
it's
either
in
here
and
then
the
design
dock.
I
sketched
out
what
partial
acquisition
and
partial
release
would
look
like,
but
yeah
the
the
partial
release
would
be
a
release
method
or
we
can
talk
about
name
but
essentially
a
release
method
on
the
permit
lease
itself
and
you
pass
in
essentially
how
many
you
want
to
release
and
it
keeps
track
internally
of
how
many
permits
you
have
and
how
many
you're
trying
to
release
and
you
can
only
release
as
many
as
you
acquired.
F
B
A
A
C
Yeah
well,
the
problem
with
you
wins
is
just
it's
just
you
I
mean
if
you
could
start
from
scratch.
Maybe,
but
I
mean,
if
you
want
to
get
the
experience
of
using
ewins
for
a
little
bit
deal
with
the
winner
t
apis
for
a
while
and
net,
because
they're
all
unit
based
and
what
ends
up
happening,
because
everything
in
the
net
is
an
end.
You
end
up
having
to
cost
a
lot
like.
C
Acquire
I
mean
my
question
is
like
to
jeremy
jeremy's
like
do
we
think
that
eigenvalidation
is
sufficient
and
normally
I
would
expect
a
core
method
or
this
template
methamphetamine.
You
have
like
overloads
with
different
argument
shapes
and
you
have
like
a
common
worker
where
they're
all
basically
forward
to
that
common
worker.
But
if
the
only
thing
you
get
is
hybrid
validation,
it
seems
a
bit
over
engineered
from
my
taste.
A
I
mean
so
like
in
this
case.
The
argument
is
simple,
and
so
you
know
it
can
be
argued
that
it's
marginal.
There
is
also
once
we
merge
in
the
extension
methods.
If
we
do
it
as
overloads
instead
of
defaults,
the
the
permit
count
is
or
there's
an
overload
of
acquire,
and
if
we
do
it
as
defaults,
then
we
definitely
want
it
using
template
method
pattern,
because
you
do
not
want
a
virtual
with
a
default.
A
A
Yeah,
so
if
you
have
a
acquire
void
and
acquire
end
and
yeah
the
void,
one
just
calls
into
one,
then
it
could
work.
The
int
validation
is
reasonably
simple,
so
it
doesn't
buy
a
whole
lot
here.
There
are
certainly
cases
where
we
have.
What
look
like
simple
methods
that
take.
You
know
a
struct
and
the
struct
has
a
lot
of
consistency
that
needs
to
be
validated,
and
so
I
know
like
for
for
crypto
it's.
A
You
know
like
rsa
import
parameters
of
where
not
all
of
the
types
and
framework
had
the
same
level
of
checking
on
it,
and
sometimes
they
throw
random
exceptions
late.
Sometimes
they
throw
pre-validation
early,
and
that
was
a
thing
to
clean
up
in
the
case
of
these
task
ones,
most
people
implement
asynchronous
methods,
wrong
argument,
validation
according
to
mr
tobe,
should
be
done
before
the
task
is
created.
A
So
if
you
have
a
virtual
that
someone
implements
as
async
and
then
they
do
argument
validation,
they've
thrown
from
within
the
task
instead
of
outside
of
the
task,
which
means
they
did
it
wrong,
and
so
by
doing
the
core
here,
the
argument
validation
happens
in
a
non-async
method.
That
then
says
return
call
another
method,
and
now
you
have
properly
encapsulated
inside
and
outside
the
task.
A
C
C
G
I
I
don't
know
that
it's
worth
this
separation
for
that.
If
there
was
a
ton
of
argument,
validation,
then
maybe,
but
there
are
plenty
of
places
where
we
have
async
methods
and
we
rely
on
the
implementation
to
do
appropriate
argument,
validation
and
to
do
it
in
a
way
that
makes
sense.
I
I
don't
know
that
this
split
is
warranted
here.
If
that's
the
only
reason
the
split
exists.
A
Yeah,
fair
enough
yeah,
it's
just.
We
have
it's
a
thing
that
I
largely
learned
about
as
the
suggested
guidance
when
revising
the
guidelines,
and
I'm
like.
Oh
my
god,
this
template
method
pattern
thing
is
amazing.
It
would
have
solved
so
many
api
problems.
I've
seen
why
do
we
never
use
it?
So
I
try
and
I
try
and
push
it
a
little
bit.
C
No,
I
think
that
I
mean
the
one
thing
that
I
would
say
is
like
I
I'm
pretty
confident
as
we
are
adding
more
abstractions
and
and
john
and
friends
will
you
know
figure
out
that
the
abstractions
that
they
designed
here
will
not
hold
up
right,
so
I
think
we'll
probably
have
to
change
the
core
at
some
point.
It
would
be
my
guess,
because
this
will
be
the
first
time
that
we
designed
an
abstraction
on
a
whiteboard
correctly.
C
F
C
What
once
we
have
that,
I
think
we
will
probably
find
that
yeah.
Here's
some
complications
where
extracting
the
core
method
would
make
sense,
but
I
think
to
me
just
for
validation.
It
seems
a
bit
I
don't
know
it's
not
just
overengineer
just
makes
the
type
more
complicated
to
understand
to
implement.
I
mean.
I
A
A
You're
implementing
acquire
and
you're
implementing
weight,
async
and
then
the
rest
of
it
is
like
the
base
class
handled
some
stuff
for
you,
so
yeah.
So
if
we
make
acquire
be
a
proper
overload
and
not
a
default
because
you
would
mention
make
it
a
default
parameter,
then
then
I
don't
really
care
it's
just
yeah.
B
Suggestion
what
is
the
cur
prevailing
pattern
in
runtime
in
asp.net
core,
for
example?
We
always
prefer
overloads
instead
of
default
parameters.
C
Basically,
the
the
problem
with
default
parameters
is
that
the
azure
sdk
did
a
bunch
of
usability
studies
where
they
found
that
some
of
their
core
methods
that
you
need,
for
example,
the
connect
method
which
everybody
has
to
call
to
like
establish
a
connection
to
the
server
took
like
12,
optional
parameters
and
people
didn't
realize
that
and
they
tried
to
fill
in
every
single
parameter
and
then
basically
gave
up
halfway
through
the
exercise,
because
he
couldn't
figure
out
all
12
parameters,
and
so
the
the
idea
is
that
overloads
are
generally
easier
to
understand
the
fewer
arguments
they
take
right.
C
And
so.
But
there
are
cases
where
it's
just
you
know,
when
you
have
like
two
to
three
arguments
and
they're
super
simple,
where
they're
insert
names
and
they're
defaulted
to
null
like.
Even
if
people
don't
get
that
they're
defaulted,
nothing
bad
happens,
they're,
parsing,
zero
or
an
empty
string
or
null
or
whatever.
You
know,
comes
to
their
minds,
and
that
tends
to
work
very
well
like.
As
soon
as
you
have
like
12
arguments
or
something.
Then
you
better
have
a
super
simple
overload.
C
That
only
takes
up
to
three
right,
that's
kind
of
roughly
the
the
guidance.
The
other
thing
is
defaults,
only
work
for
literals
right.
If
you
have
like
some
sort
of
complicated
object,
that's
the
default.
You
can't
express
that
with
default
parameters,
but
you
would
have
to
say
well,
it's
it's
null
and
null
means
whatever
the
ambient
default
is
right,
but
yeah.
Basically,
the
default
values
are
baked
by
the
compiler
to
the
call
side
right.
So
you
can't
change
the
default
values
ever.
C
B
So
I
guess
what
I'm
hearing
is
that,
for
I
guess
these
simpler
apis
there's
not
too
many
arguments.
It's
preferable
to
have
overloads.
C
I
mean
to
me
what
I
like
about
default
parameters.
Is
that
they're
documenting
right?
They
tell
you
what
what
they
are,
because
they
show
up
in
intellisenses.
Permit
count
equals
zero,
for
example.
So
you
know
the
default
is
zero.
If
you
have
an
overload,
you
kind
of
have
to
read
the
documentation
so
like
that's.
Why?
For
for
simple
values,
I
personally
prefer
optionals,
because
you
know,
as
I
said,
you
can
see
what
the
actual
value
is.
C
But
the
problem
is:
when
you
have
people
that
don't
understand
that
the
brackets
in
intellisense
being
optional,
they
just
will
pass
in
wages
for
those
right.
They
don't
understand
that
they're
optional
and
that's.
B
Yeah
right,
surab
actually
makes
a
good
point
about
wait.
Hold
on
overloads
are
better
for
gi
constructor
injection,
but
these
are
not
constructors.
H
B
Doesn't
fy
the
emojis
are
tiny
so
to
me
that
just
looked
like,
I
didn't
see
the
wink
it
just
looked
like
a
smiley
face
to
me.
I
see
yeah.
That's
also.
B
B
Yeah,
like
I
mean
we
should
fold
a
prevailing
runtime
pattern,
but
it
sounds
like
if
it
doesn't
matter.
I
guess
I'll
just
pick
one
and
go
with
it.
C
Choice
so
basically
the
idea
is
when
you
have
virtuals.
The
problem
is:
if
you
have
default
values,
everybody
who
overrides
has
to
repeat
those
defaults
and
have
to
have
the
exact
same
defaults,
because
the
problem
is
when
you
have
different
defaults
between
different
overrides
now,
it
totally
depends
on
the
static
type
that
the
person
invokes,
the
method
on
which
defaults
they
are
getting,
which
can
be
very
confusing
and
not
intuitive,
because
people
use
var
all
the
time,
and
they
don't
understand
that.
C
Oh
on
the
base
type
the
default
is
zero
and
on
the
drive
type
it
happens
to
be
three
and
no
like.
Sometimes
I
get
you
know,
I
ask
for
three:
sometimes
I
ask
for
zero
and
it's
super
confusing
right.
So
that's
why
we
said
for
for
virtual,
it's
the
only
party
that
gets
to
define
the
defaults
is
the
base,
and
so
the
only
way
to
really
bake
this
into
the
system
is
by
saying
give
an
overload
that
just
you
know,
literally
hardcodes
the
videos.
B
Fair
enough,
I
think
well
personally,
I
think,
preferring
a
simpler
solution,
maybe
even
without
the
templating.
I
think
that
makes
sense
to
start
off
from
there
and
essentially
based
on
the
feedback
and
implementations.
We
have
see
whether
there's
enough
complexity
to
kind
of
warrant
it.
The
only
thing
I
kind
of
want
to
draw
the
attention
to
is
that
we
do
have
a
default
for
the
cancellation
token.
I
think
that
is
the
common
pattern
we
have
so
just
making
sure
that.
A
So
the
only
thing
that
someone
could
do
differently
in
an
overload
is
not
specify
the
default
and
enforce
it
as
a
formal
parameter
and
that
one
we're
okay
with
so
so
we
cancellation
token
is
permitted
to
be
a
default
in
in
virtuals.
Everything
else
we
think
is
a
bad
idea
to
be
a
virtu
or
a
default
in
a
virtual.
B
Okay,
so
I'm
going
to
put
that
down
as
we'll
prefer
simpler
apis
with
overloads
and
not
have
the
templates
until
proven
that
there
is
significant
value
for
that.
Would
that
be
okay.
F
E
E
E
So
I
kind
of
think
that's
enough
justification.
I
mean
I,
I
don't
think
I
liked
it
at
first,
but
then
you
have
two
reasons
right
and
it's
kind
of
like.
Well,
that's
two
advantages
that
we
don't
have
the
other
way
good
enough,
but
into
a
caller.
They
don't
see
right.
The
callers
never
see
the
core
methods
because
they're
protected.
So
it's
only.
E
F
If
the
main
concern
is
you
know
it's
virtual,
so
some
overrider
could
use
a
different
default
value.
Then
maybe
we
should
just
have
an
analyzer
saying:
hey
you're
overriding
and
you're
using
a
different
default
value
here.
That
seems
like
something
that
reasonably
catch
the
common
scenario
and
then
it's
an
explicit.
B
C
So
this
is
so,
I
basically
removed
all
the
extension
stuff.
I
renamed
the
things
based
on
what
we
said.
I
have
not
undone
the
core
non-core
split,
so
maybe
we
want
to
do
that.
A
Well,
I
think
eric
e
was
now
convinced
that
we
should
make
a
choir,
be
a
default
and
then
keep
acquire
core
so
that
we
have
the
the
don't
have
defaults
and
virtuals.
L
B
A
Be
a
little
easier
on
everybody's
eyes
here:
yep,
okay,
I'll,
drag
this
off
and
look
at
something
with
syntax,
highlighting
because,
despite.
A
What
three
months
now
that
I
haven't
installed
anything
on
this
machine.
A
Undo,
yeah
and
and
they're
on,
you
know
this
machine
over
here.
B
Yeah,
I've
personally
have
converted
to
using
vs
code
for
most
of
those
purposes.
A
Yes,
you
saw
resharper
and
you
saw
resharper
in
fact
not
being
able
to
figure
out
where
system
private
core
lib
lives,
because
for
some
reason
we
break
that
every
other
month.
So.
A
Right,
so
all
right
so
permit
lease.
Oh,
I
guess
there
is
the
the
two
other
tri-gets
from
the
tri-get
metadata
being
merged
in,
but
right.
B
So
the
idea
with
the
permanent
release,
just
to
kind
of
allow
that
is
this-
represents
a
ownership
of
the
permits
that
you've
acquired
from
the
acquire
or
weight
asic
method
from
the
limiter
and
you
it
is
disposable
so
that
when
you
dispose
it
all
of
the
permits
that
you've
acquired
are
returned
for
rate
limits,
so
time-based
rate
limits.
That
would
be
a
no-op
for
concurrency
limits.
That
is
actually
a
release
on
the
actual
implementation.
B
Yeah
and
the
two
things
on
two
other
things
on
here
is
acquired,
is
represents
whether
your
acquisition
to
acquire
or
wait
async
was
successful
or
not,
and
try
get
metadata.
That
is
the
way
for
the
specific
implementation
of
permit
lease
to
report
back
additional
metadata
yeah.
So
two
common
ones
we've
seen,
are
retry
after
and
reason
phrases
for
failures,
but
if
the
implementation
wants
to
return
additional
metadata
that
they
can.
C
C
If
that's
the
pattern
you
have,
I
think
there
would
be
value
in
making
the
try
get
ones
actually
extension
methods,
because
then
you
could
say
like
yep,
there's
a
you
know,
we,
you
know
the
the
the
core
thing
only
knows
about
metadata
name
and
then
everything
else
is
an
extension.
And
then,
if
you
have
higher
level,
abstractions
or
general
pattern
is
yeah,
you
define
your
own
extension
methods
over
permit
lease
that
you
know
probes.
Whatever
keys
you
have
and
that's
the
pattern
you
have.
I
think
that
would
not
be
terrible.
C
I
think
in
that
case
it
would
be
a
bit
more
warranted
to
extract
these
things
out,
as
extension
methods,
but
I
think
for
the
for
normal
overloads.
I
wouldn't
do
it.
A
Would
require
it
being
virtual.
H
C
B
Right
that
that's
how
I've
done
it
for
the
rate
limiters
right
now
for
a
retry
after.
B
So
that
was
a
consideration,
but
I've
left
it
as
object
to
be
the
most
general.
But
are
you
I'm
guessing?
What
you're
trying
to
propose
here
is
try
get
metadata
of
t
and
then.
C
C
Seems
like,
if
I
know
the
metadata
name,
then
I
also
know
the
type
right,
yeah
yeah
and
I
mean
worst
case.
You
return
null
because
or
a
default
of
t
right
because
you're
like
well
you
because
it's
like
yeah,
I
couldn't
find
them
because
basically
now
you're
querying
for
both
the
the
name
and
the
type
and
if
they,
if,
if
one
of
them
doesn't
match,
then
you
just
return
false
right.
A
M
A
Time
span
and
then
pass
the
key
for
reason.
Then
that's
this
doesn't
make
any
sense
and
then
that
would
throw
a
something
exception,
very
specific
exception
type,
because
that's
a
you
should
know
that
these
two
thing
that
that
this
combination
would
never
succeed.
C
I
think
that
makes
sense.
I
think,
if
like,
if,
if
that's
the
pattern
you
want
to
do,
I
think
you
want
a
generic.
I
mean
sorry,
that's
the
wrong
word
here,
a
method
that
doesn't
take
a
generic
parameter
that
allows
you
to
enumerate
the
metadata
just
for
the
for
diagnostics
reasons
right.
If
I'm
standing
on
a
perm,
at
least
in
the
debugger,
it
would
be
kind
of
neat
if
I
could
find
out
what
metadata
is
on
that
type
right
and
it's
a
bit
hard.
A
C
A
Well
or
you
just
say
metadata
name
and
it's:
it
stores
a
string
and
a
type.
A
D
C
L
B
C
B
Right
so
the
additional
data-
I
don't
want
to
give
a
explicit
list
because
some
of
them
are,
I
mean
durron,
is
on
this
call
as
well.
So
you
can
chime
in
and
correct
me
if
I'm
wrong,
but
a
lot
of
these
values
are
numbers
so
think
of
them
as
either
ins
or
flows
for
essentially
like
a
percentage
of
a
limit
currently
being
used
up
or
something
like
that.
B
So
there's
they're
very
often
numbers,
but
some
of
them
could
also
be
pretty
customly
defined
by
each
limit,
some
of
which,
I
think,
are
defined
by
different
services.
So,
for
intents
and
purposes,
it's
very
custom
for
each
service
implementation.
B
B
So
yeah,
so
that's
kind
of
why
so
far
I've
been
trying
to
keep
it
as
generic
as
possible,
but
yeah.
I
think
we
can
have
a
essentially
specified
for
the
well-known
ones.
We
can
definitely
specify
both
the
key
and
the
type
of
the
return
value,
but
we
need
to
make
sure
that
it's
simple
to
add
a
essentially
metadata
key
like
custom
name
and
any
type.
Essentially.
C
Yeah
the
way
I
would
do
it,
you
would
have
a
static
class
metadata
name.
That
is
non-generic.
That
is
basically
your.
You
know
your
enum,
you
know
accessor
if
you
will,
but
you
have
your
retry
after
and
and
reason
phrase
on,
and
then
you
have
your
read-only
struct
metadata
name
of
t
that,
basically,
you
know
just
takes
the
name
as
it
does
today,
because
the
t
is
basically
just
part
of
the
type
and
then
the
the
actual
properties
would
be.
C
You
know,
type
this
metadata
name
of
time
span
and
metadata
name
of
string.
C
No,
my
understanding
was
that
you
want
some
sort
of
like
collection
of
common
ones
that
everybody
shares
and
so
having
a
centralized
place.
Where
you
can
have
your
conventions,
I
think,
would
be
useful
because
you,
you
want
multiple
rate
limiters
to
use
both.
You
know
well
to
use
the
retry
right.
You
don't
just
want
one
of
them
to
use
the
particular
retry
right.
C
N
M
M
What's
what's
the
cost,
though,
because
an
abstract
virtual
is
just
an
extra
dictionary,
lookup
right,
yeah.
J
It's
you,
you
basically
start
doing
weird
things
with
a
v
table
at
runtime
and
it
gets
very
expensive
very
quickly,
especially
if
you
start
having
multiple
different
types
in
here
then
you're
you're,
paying
for
every
single
possible
allocation
or
every
single
possible
t
that
could
ever
be
put
in
there
like
I've.
I
don't
understand
it
fully,
but
I
know
like
every
single
time
this
has
ever
come
up
in
the
past
like
it's.
It's
always
been.
Please
try
to
avoid
that,
if
at
all
possible.
J
C
Grow
for
the
number
of
t's
that
you
ever
have
metadata
for
right,
which
seems
to
be
bounded
by
you,
know,
time
stand
string,
int
and
then
maybe
float
a
double
and
then
that's
it
right.
You
don't
have
like
a
super
open-ended
set
of
types
here
right.
It's
still
a
very
small
number
of
types
in
practice.
D
A
B
Yeah
thanks
but
yeah.
We
expect
this
to
be
used
in
many
other
places,
so
in
asp.net
core.
We
also
want
to
use
this
eventually
for
kestrel
as
well,
and
some
of
their
data
rate
limits
in
the
bcl.
We
also
have
identified
some
of
the
other
types
that
could
benefit
from
this
channel's
pipelines,
streams
and
things
of
that
nature,
and
we
also
want
to
allow
like
partners
such
as
azure
to
use
this
in
their
azure
throttling
service
acr.
B
A
couple
of
I
think
it
was
was
in
tune,
t
and
and
a
few
other
things.
So
essentially,
this
is
expected
to
be
a
what's
that
term
exchange
type
for
it's.
Actually,
these
rate
limiting
concerns.
M
C
So
when
you
call
try
get
metadata,
is
that
only
on
this
on
the
error
case?
Basically,
when
a
permit
wasn't
granted
so
do
you
expect
that
to
be
super
frequently
or
like
a
little
kind
of
scenario?
Is
that,
like
rare
enough
that
at
that
point,
you
may
throw
an
exception
anyway,
so
the
boxing
is
no
longer
relevant
as
a
as
a
cost.
B
Actually,
I
want
to
clarify
a
little
bit,
so
we
so
far
the
most
common
use
cases
we've
seen
for
a
sound,
essentially
retry
after
and
reason
phrase.
Those
ones
are
only
relevant
when
a
question
fails,
but
there
is
theoretically
no
reason
why
you
can't
create
some
metadata
even
on
the
successful
cases.
B
So
another
thing
that
we
have
seen-
but
it's
not
terribly
as
common-
is
essentially
giving
a
status
of
how
many
of
these
permits
as
a
percentage,
how
many
have
been
used
up
but
yeah
again,
like
that's,
not
terribly
common,
but
it
is
a
use
case
we
have
seen
so
that
would
be
relevant
on
success.
B
So
it
really.
I
don't
want
to
close
the
door
and
say
no,
it's
just
generally
not
used
on
successful
calls,
but
it's
rarer.
C
J
H
C
Out
object
and
then
we
said
well
what
if
we
make
the
t
part
of
the
metadata
name
so
that
when
you
ask
for
it,
you
only
get
back
that
t.
But
then
the
concern
is
it's
a
virtual
generic
which
is
not
just.
M
C
I
mean
one
thing
I
would
do
is
like
if
you're
okay
with
boxing-
I
would
just
say,
let's
have
a
virtual.
That
is
non-generic-
that
that
does
the
boxing
and
then
have
a
non-virtual
one
that
does
the
cast.
That
basically
is
of
t,
at
which
point
you
can
just
trivially
ask
try
get
metadata,
pass
metadata,
name,
dot
retry
after
and
you
already
get
back
the
correct
type.
You
don't
have
to
cost
yourself,
and
then
you
basically
don't
need
the
convenience
overloads
at
all,
because
it's
you
know
a
one-liner.
M
Emo
had
a
suggestion
of,
I
think
it
was
emo,
no,
not
email.
I
don't
know
someone
levi
of
putting
the
the
get
metadata
strongly
typed
version
on
metadata
name.
G
J
That
that
avoids
the
the
explosion
problem,
it
means
that
you
have
to
unbox
as
part
of
metadata
name
of
t
or
metadata
name
of
t
would
have
to
look
for.
Like
an
interface,
I
can
give
you
value
of
t
on
whatever
permit
lease.
It's
wrapping.
M
Well,
then,
it
works
for
anyone's
metadata
and
we
don't
have
our
own
private
collection
of
metadata
names
and
other
people
have
their
own
collection
of
the
things
that
are
important
to
them.
Well,.
J
C
C
A
A
L
C
Which
might
be
okay,
but
that
basically
no
means
that
you
just
have
to.
I
mean,
basically
you
do
you,
I
guess
you
have
to
choice
right.
You
either
just
either
decide
the
caller
has
to
know
the
t,
in
which
case
you
probably
want
extension
methods
like
the
try
get
retry
after
that,
basically
codifies
that
thing
into
the
api
shape,
or
you
end
up
with
something
that
we
have
on
the
screen
right
now,
where
you
say
well,
the
c
is
kind
of
part
of
the
name.
C
L
C
Yeah,
you
basically
don't
need
to
try
get
retry
anymore,
because
when
you
say
premier,
lease
try
get
metadata
and
you
pass
the
metadata
name:
dot
retry
after
it's
already
clear
that
it's
time
span
like
you,
didn't
have
to.
Basically
all
these
extension
methods.
Now
that
you
would
have
to
define
you
can
get
rid
of
because
it's
part
of
the
metadata
name.
L
D
H
Methods,
one
quick
thing:
I
think
it's
out
key
question
mark
of
metadata.
L
A
Weird
that
once
once
it's
generic,
actually
I
don't.
J
B
Yeah,
because
something
there
didn't
look
right,
but
okay,
yeah.
I
F
H
J
Metadata
name
of
t
should
have
a
non-nullable
parameter
and
name
most
likely
fair
enough.
The
property
is
still
nullable
because
it's
a
struct.
No,
that's
that's
fine!
You
can
still
make
it
non-nullable,
because
if
you,
if
you
have
default
of
t
and
you
just
start
accessing
properties
like
that's
on
you
right,
if
you
have
like
default
of
string,
it's
going
to
return
null.
A
C
G
G
It
was
an
interface
mapping
which
is
a
struct
that
contains
four
reference
fields
and
as
l
you
never
create
one
yourself
and
every
time
you
get
it
back
from
from
the
run
time,
all
the
fields
are
always
initialized,
so
we
decided
alright,
well
we're
better
off
just
saying
pretending
that
they'll
never
be
null
because
in
the
99.99999
case
they
won't
be.
I
don't
know
what
the
case
is
here.
Are
you
creating
these
things
yourself.
B
Right,
those
are
the
two
most
common
cases,
but
we
want
to
have
the
extensibility
where
somebody,
the.
J
M
A
M
C
I
I
A
I
mean
okay,
it
I
I
put
it
there
just
because
it's
if
most
of
what
you're
doing
is
metadata
name
dot,
a
well
known
name,
that
it
seems
like
that
that
people
will
have
the
the
finger
motor
memory
of
its
metadata
name
dot.
The
thing
I
want
and
then
you
call
create
when
the
thing
you
want
doesn't
exist,
but
we
can
get
rid
of
it
whatever.
J
A
C
That's
a
good
point.
I
mean
like
these
keys
like
if
you
instantiate
them
every
single
time,
you're
doing
something
wrong
right,
like
nobody
like.
Even
if
you
have
custom
ones,
you
would
expect
somebody
to
define
aesthetic
type
of
the
common
ones
on
it
as
well
right
so
yeah.
Ideally
they
you,
you,
don't
pay
for
them
every
single
time
you
use
them.
M
C
A
C
A
Okay,
I
guess
we
don't
need.
I
equatable
once
we're
out
of
struct.
J
A
L
A
C
M
H
H
C
J
B
Yes,
but
I
think
in
this
case
like
it,
doesn't
really
make
sense
that
null
is
significant,
like
storing
a
value
of
null
is
the
same
as
not
having
that
metadata
at
all.
As
I
would
argue,
I
mean
like.
A
A
A
C
I
think
I
think
the
idea
here
is
that
there's
a
loose
contract
between
the
caller
and
the
provider
right,
and
so
it's
all
convention
based.
So
I
think
the
common
code
wouldn't
care
right.
The
common
code
just
say
if
you
happen
to
have
a
reach
right
reason.
I
can
do
something
useful,
but
if
you
don't
have
one
or
it's
not
well,
then
I
don't
know
what
to
do
with
it
right.
So
you
would
probably
not
distinguish
these
two
right
right
I
mean
the
question
remains
is
like.
A
J
A
If
you're
doing
the
not
null
when
true
yeah
yeah
yeah
yeah-
and
I
guess
yeah-
that's
actually
a
reasonable
point
is,
if
you.
A
H
A
D
C
C
L
M
D
M
M
A
A
It's
sort
of
up
to
you
like
I
was
actually
going
to
ask
does:
should
we
even
still
leave
this
as
public?
That's
a
good
point,
or
is
this.
M
A
Protected
abstract,
try
get
metadata
and
that
all.
A
D
Yes,
no
and
I
think,
okay,
another
thing
you
consider
if
you're
trying
to
make
things
private
in
public
or
protected.
So
if
retry
after
returns,
true
within
all
time
span,
and
then
you
call
the
generic
tri-get
method,
does
that
like
throw?
Does
that
return
false
like
it
can't
return,
can't
give
you
a
null
time
span
at
that
point.
D
M
A
Again,
that's
that's
the
question
of
who's,
calling
it
like.
If
it's
protected,
then
all
public
callers
are
calling
the
generic
version.
Their
nullability
is
determined
by
the
nullability
of
the
property.
That
was
there,
the
or
at
least
highly
suggested
by
it.
The
right,
because
if
it
says
it's
returning
a
time
span
null
made
no
sense.
The
null
is
gone.
A
L
C
I
mean
the
one
that
I
already
said
like
I.
I
think
you
wanted
a
non-generic
enumeration,
so
you
can
dump
all
the
things
that
are
in
there
at.
C
F
C
You
know
the
tri-get
metadata
name.
That
is,
that
is
non-generic.
That
gives
you
back
object.
Question
mark.
L
A
C
C
E
L
A
A
read-only
projection
over
your
dictionary
or
you're
just
willing
to
return
your
whole
dictionary.
This
is
one
call
and
if
you
have
12
metadata
things
that
you
support,
then
saying
you
gave
me
abstract,
give
me
all
your
names
and
I
can
go
ask
for
the
value
for
each
one
of
them.
That's
thirteen
calls
to
return
the
object,
plus
the
yield
enumerator.
C
C
B
A
A
A
C
L
C
C
A
With
that,
so
on
the
one
hand
this
feels
property-ish.
On
the
other
hand,
it
feels.
A
At
least
debuggerly
expensive
you
hit
f10,
it.
L
C
C
A
A
A
C
K
C
To
I
think
for
the
I
think
for
the
enumeration
you
would
use
yield
when
you
actually
ask
for
the
values
because
that's
easier
to
implement.
But
that's
why
I
said
like.
I
don't
think
that
you
would
actually
implement
get
all
metadata,
because
if
all
you
do
is
yield
return
x,
yield
return
y,
then
you
might
as
well
just
let
let
it
go
through
the
trigger
metadata
path.
B
That
calls
into
try
get
metadata
with
string,
and
then
it
casts
it
to
the
type.
A
Yeah
yeah,
it's
just
a
hard
cast
well
because
I
need
to
do
the
assignment
as
well,
and
so
it's
too
it's
curly,
but
how.
L
B
I
mean
so
so
far
I
haven't
even
put
count
as
one
of
the
curated
set
of
like
values,
because
that
is
pretty
much
only
relevant
if
you
are,
if
you
want
to
do
partial
acquisition
or
partial
release
yeah,
we
don't
do
that
right
now.
So
there's
no
reason
for
a
count.
It's
all.
L
L
A
M
B
So
that
I
think
I
had
like
these
static,
like
failure,
things
before
so
essentially
like
permanently
stop
success
permanently,
stop
fail,
no
like,
essentially,
both
of
them
would
know
up
for
certain
things.
It's
probably
best
to
leave
that
for
the
implementation,
because,
for
example,
in
failure
cases
they
might
want
to
create
different
types
of
metadata
on
it
and
in
success
cases
you
might
want
to.
You
might
want
to
actually
have
fields
that
helps
you
dis,
dispose
or
release
the
resources
back,
yeah.
B
A
H
A
Think
right
now
that
is.
F
D
Been
disposed
or
whatever,
but
yeah.
J
No,
I
mean
I
mean
the
pattern
like
oh
protective
method,
that
takes
a
bull
blah,
blah
blah.
J
A
G
G
J
K
You
act
like
disposing
matters
or
something
is
get
available
permits
what
what
estimated
account
was.
Yeah.
B
That
is,
I
believe,
in
the
comment
in
the
a
proposal
I
mentioned.
This
is
mostly
used
for
diagnostics.
D
B
It's
the
equivalent
on
the
semaphore
is
essentially
current
count
right,
so
essentially.
B
B
A
A
L
L
Yeah,
I
think
it's
gonna
be
fuzzy.
It's
really
distributed.
B
B
Right
but
it's
probably
it.
B
B
M
B
Is
partial
acquisition
which,
right
now
we
don't
support
because
there's
no,
we
haven't
identified
any
use
case
for
that.
B
You
so
another
thing
that
you
I
mean
you
could
do
is
wait
for
that
amount
right.
B
B
Five
then
it
will
I
mean
with
the
current
set
of
apis.
What
that
would
do
is
it'll
always
just
fail,
and
then,
if
you
keep
on
trying
with
10,
then
you'll
keep
on
failing.
But
if
you
try
a
smaller
amount,
you
might
succeed.
So.
M
So
yeah
I'm
using
this
to
limit
to
rate
limit
a
stream
and
I
have
a
4k
buffer
should
I
try
to
require
4k
and
then,
if
that
fails,
try
to
acquire
2k.
Or
do
you
see
the
problem,
especially
because
some
some
protocols
might
rely
on
that
2k
at
the
front
being
sent
before
it
returns?
Some
additional
data
to
you
that
sort
of
thing.
B
Yeah,
I
think
so
originally
how
we
envisioned
a
partial
acquisition
is
that
on
the
acquirement
method,
you
also
indicate
whether
you
are
you.
You
are
okay
with
it
returning
essentially
as
a
smaller
amount
than
you
asked
for
so
there's
another
bully
on
there,
or
I
mean
we
can
just
make
a
different
method
like
acquire
partial
or
something
like
that,
and
then
on
the
permanent
lease.
B
That
is
where
you
use
the
metadata
to
communicate
how
many
you
actually
acquired
so
so
that
is,
that
is
our
thought
of
how
partial
acquisition
would
work,
and
if
we
feel
that
that
is
a
scenario
we
want
to
support.
We
can
add
that
api
as
well,
but
yeah.
I
didn't
include
that
in
this
proposal
yet,
but
it
yeah
it
just
depends
on
whether
we
think
we
should
include
that
as
a
essentially
the
first
iteration
of
this
api.
M
B
Can
start
with
this
and
then,
as
the
prototype
evolves
essentially
for
streams,
we
can
have
a
different
proposal
that
adds
those
capabilities.
It
shouldn't
conflict
with
these
apis
it'll
just
be
an
in
addition.
A
Yeah
it
feels
like
when
slash
if
you
ever
support,
partial
or
partial,
acquire
partial
release
any
of
those
things
you're,
probably
going
to
want
the
lease
to
tell
you
how
much
it
acquired
so
yeah.
Should
that
already
be.
B
So
it's
a
so
so,
for
example,
is
a
choir
is
literally
a
field
on
permanent
lease
and
the
the
decision.
B
What
we're
trying
to
kind
of
make
here
is
whether
count
should
be
something
like
is
acquire,
or
it
should
be
similar
to
all
the
extra
metadata
that
we
currently
have
for
retry
and
reason
phrase.
A
I
mean
I
could
be
wrong
but
like
that
would
be
the
only
way
that
you
could
extend
it.
If
you
shipped
right
now
and
you
were
stable
and
then
you
added
this
partial
support
and
you
wanted
to
let
somebody
get
the
data
back
now.
You
basically
just
have
to
describe
anybody
who
supports
partial,
should
add
support,
for
you
know,
metadata
name,
dot,
current
permit
count
and.
F
B
Well,
I
was
going
to
say,
like
essentially
have
a
virtual
count
and
by
default
it
goes
into
the
metadata
to
look
for
it.
But
if
you
you
know
use
like
in
your
implementation,
you
could
just
store
it
as
a
field.
B
Yeah
and
that
would
that
would
work
yeah.
Essentially,
it
allows
you
to
kind
of
make
it
an
additive
api
that
we
can
add
later,
but
it
doesn't
require
us
to
have
to
put
it
on
all
permanent
leases.
B
M
Can
we
at
least
say
that
before
this
thing,
ships
we'll
have
a
prototype
with
a
stream,
and
hopefully
that
will
drive
if
it
this
property
would
be
useful
or
not?.
B
Fair,
but
even
if
it
becomes
useful
in
stream
does
it
mean
we
should
have
that
on
every
permanent
lease.
A
A
A
I,
like
that's,
why
I
asked
the
question
of:
should
it
be
exposed
and
how
do
you
want
it
implemented,
but
I
guess,
since
we
have
about
10
minutes
left,
I
don't
think
we've
actually
talked
about
the
name
permit
lease.
A
Does
anyone
like
I'll
throw
out
just
as
a
straw
man,
so
that
there's
a
thing
to
compare
it
against
rate
lim,
at
least
so
that
its
rate
limiter
returns
a
rate
line,
at
least
I'm
fine?
I
don't
have
super
objection
to
permit
lease.
It
just
feels
like
it's
a
it's
a
more
general
name
than
the
rest
of
the
api
around
it.
I
guess
metadata
name
is
also
we
might
want
to
think
about
as
like.
If
you
just
see
this.
A
Should
we
give
it
affinity
to
its
name
space
instead
of
just
the
name
space?
So
those
are
the
two.
M
L
L
L
B
B
It's
yeah,
especially
because
it's
already
in
the
rate
limiting
namespace,
like
I
think,
that's
fine,.
F
A
Well
right,
so
the
the
real
the
two
concerns
are
one
you
have
a
bunch
of
usings
at
the
top
of
your
file,
and
now
you
have
something
in
the
middle.
That's
talking
about
a
metadata
name
and
you
you
no
longer
have
the
knowledge
that
that
metadata
name
came
from
rate
limiting
and
the
other
is
if,
if
two
things
that
you
would
have
usings
for
in
the
same
file
have
the
same
name.
A
M
B
Is
that
a
I?
I
hope
that
doesn't
add
another
like
dependency
on.
I
guess
this
is
essentially
like.
Do
we
need
to
create.
L
H
So
I
think
that,
let's
see
so
we
cover
the
naming.
B
F
B
Yeah,
so
two,
I
think
things
I
I
just
wanted
to
confirm
a
little
bit
more
one.
Is
that
just
a
note
that
we
also
should
take
a
look
at
the
generic
rate
limiter?
Essentially
the
aggregated
limiters
of
t
key.
B
I
think
before
we
ship
this
as
well.
Although
it
is
you
know
a
parallel
set
of
apis,
but
that
would
be
a.
B
Oh
actually,
sorry,
maybe
just
not
exactly
before
we
ship
this,
but
we
should
consider
the
impact
of
having
these
two
types.
We
can
ship
a
preview
package
as
is,
but
we
should
kind
of-
I
guess
what
I
meant
is
before
we
ship
rtm
version.
We
should
kind
of
work
out
what
that
looks
like.
B
L
Okay,
we
we
should
figure
out
the
generic,
as
I
guess
the
next
api
review,
because
we're
done
though
well
I
like.
D
B
I
mean
there
will
be
a
little
bit
more
for
specific
implementations.
I
think,
but
yeah
at
least
the
abstractions,
I
think
is,
is
in
good
shape.
One
other
thing
I
want
to
call
attention
to
is
last
time
we
did
have
some
discussions
on
whether
these
like
permit
counts
should
be
into
or
long.
B
The
reason
why
we
said
in
is
sufficient
is
we
expected
a
scaling
factor
so
essentially,
if
you
regularly
obtain
four
kilobytes
at
a
time,
instead
of
you
know
doing
4000
or
4096,
you
would
scale
that
back
somehow,
but
then
it
essentially
means
these
limiters,
like
the
count
are
very
abstract
and
it's
up
to
the
implementation
too,
or
it's
up
to
the
user
to
define
what
each
permit
or
each
count
means.
B
And
I
just
want
to
make
sure
that
that
is
still
essentially
what
we
think
is
fine,
oh
and
one
more
thing,
because
you
changed
it
to
from
permit
lease
to
rate
limit
lease
before
I
had
those
counts
as
permit
counts.
Maybe
we
should
name
those
differently,
as
well
as
the
arguments
inside
acquire
acquire
core
weight,
async
and
all
that.
A
A
Well
that
one's
weird,
because
the
permit
count
of
zero
is
supposed
to
be
allowed
to
be
passed
to
acquire
to
test.
If
the
thing
is
already
at
capacity,
I
think
right
and
then
that
would
be.
M
M
Wouldn't
testing
for
capacity
just
be
calling
get
available
permits.
It
would
give
you
the
same
exact
guarantees
right
so.
B
It's
a
little
bit
different
acquire
of
xero
will
give
you
a
permanent
lease
which
may
have
metadata
on
it
and
weight
async
of
zero
means
if
there
are
no
available
permits.
Let
me
know
when
a
replenishment
of
those
permits
occur
but
don't
acquire
any
of
them.
M
Says
zero
by
read:
yes,
okay,
it
makes
sense,
and
we
we'd
prefer
that,
rather
than
having
a
get
metadata
on
the
rate
limiter.
N
B
Yes,
because
metadata
is
generally
tied
to-
or
I
mean
it
makes
sense
to
tie
to
elise.
M
A
When
discussing
the
argument,
validation
and
and
I
had
answered
that
I'd
remembered
that
zero
was
a
designed,
valid
parameter
so.
D
A
All
right,
so
I
will
fly
through
the
notes
that
I
took
namespace.
We
changed
it
back
under
system
threading
and
now
it's
system,
threading
rate
limit
or
system
threading
rate
limiting.
A
We
got
rid
of
all
the
extension
methods
we've
made,
get
available,
permits
or
available
permits.
We
get
available
permits,
we
discussed
between
overloads
or
default
parameters
for
acquire
and
weight
async
and
went
with
defaults.
A
A
A
We
will
spend
at
least
an
hour
debating
that
if
we
want
to
debate
it,
so
no,
we
cannot
revisit
it
today
and
open
question
about
renaming
the
permit
count,
parameters
given
the
name
of
the
type
and
then
an
open
question
slightly
as
to
whether
metadata
name
is
overly
general
and
then
I
pasted
the
things
in
is
there
anything
that
we
talked
about
that
didn't
get
written
down.
B
Well,
I
think
we
need
to
review
the
implementation
apis
as
well.
Oh.
B
The
abstraction,
I
think
is,
is
good.
We
can
talk
about
the
implementations
of
which
I've
I
have
samples
for
concurrency
and
token
bucket,
but
essentially,
I
think
those
are
representative
of
all
four
which
I
have
samples
for
in
asp.net
branch,
but
I'll
probably
move
it
to
asp,
labs
and
link
it
here.
C
B
I
mean
as
soon
as
possible
would
be
nice,
but
depends
on
like
that,
because
people
are
picking
me.
B
Asking
right,
oh,
I
mean
I
think.
Ultimately,
the
decision
is
up
to
you,
but
essentially
the
implementations
at
least
two
of
them,
which
I
think
is
representative
of
all
of
them,
is
ready
to
be
reviewed.
So
yeah.
C
C
Yeah
because
I
think
like
once
we
start
talking,
it
will
take
two
hours.
So
I
probably
like,
let's
do
next
tuesday,
then
so
we
can
at
least
have
one
meeting
in
the
interim
where
we
can
unblock
some
other
people
in
the
middle
and
then.
C
A
All
right
sounds
good
okay,
so
I
will
hit
post
and
we're
not
done
so
needs
work
just
so
the
tool
picks
up
something
feel
free
to
pop
it
back
to
ready
for
review
in.
You
know
like
half
an
hour.
A
Thank
you
and
okay.
So
yes,
as
our
discussion
just
said,
the
next
meeting
will
be
thursday
10
a.m.
Redmond
time
where
we
will
be
talking
about
the
backlog
which
has
other
red
things
in
it
now
hooray.
A
All
right,
having
recently
read
the
section
on
robert's
rules
of
order
of
how
a
chair
is
supposed
to
end
a
meeting.
I
observe
that
we
are
over
time
and
I
declare
this
meeting
adjourned.