►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Collection
is
not
a
thread
safe,
so
it's
not
it's
not
a
concurrent
priority
queue,
and
another
point
is
that
it
is
not
stable.
So
if
you
decide
to
enqueue
elements
with
equal
priorities,
it
is
not
guaranteed
that
they
would
get
dequeued
in
the
same
order.
This
is
something
that
is
generally
true
for
most
heap
implementations
out
there
are
there
any
questions
so
far.
A
Cool,
so
that
brings
us
to
the
actual
api
shape.
C
Oh
just
a
point
of
clarification,
sure
did
you
say
finding
an
element
will
be
linear
and
not
log
n.
In
the
initial
explanation,.
A
A
A
Now
heaps
are
not
are
not
they're,
not
search
trees,
so
you
wouldn't
be
able
to
like.
C
A
No,
that's
not
the
case
like
the
heap
property.
The
only
thing
that
it
guarantees
is
that
the
children
of
a
given
node
are
always
larger
than
the
node
itself,
but
nothing.
C
Else:
okay,
okay,
cool.
A
E
A
Okay,
so
maybe
I
should
just
describe
the
api
shape.
As
I
see
it,
you
have
a
priority
q
class
that
has
two
type
arguments,
t
element
and
t
priority.
It
implements
a
couple
of
interfaces.
I
read
only
collection
of
a
tuple
of
element
and
priority.
I
expect
this
to
be
controversial
and
would
like
to
discuss
it
with
you
like
why
it
should
be
a
tuple
instead
of
a
key
value
pair,
also
implementing
eye
collection.
A
It
has
a
few
constructors
so
default
constructors
that
create
an
empty
priority.
Queue
instance:
priority
queue,
constructor
that
accepts
a
capacity
parameter
priority
queue,
constructors.
A
Accept
priority
compet
sorry,
equal
compares
for
the
priority
values
and
also
constructors
that
accept
an
innumerable
of
element
and
priority.
D
B
A
Yeah,
I
wouldn't
object
to
that.
B
B
B
Can
use
nullable
of
and
right
that
if
we
want
to
be
more
clear
or
we
can
leave
it
spread
as
three
I'm
just.
B
But
certainly
with
the
I
enumerable
and
I
compare
since
the
I
comparer
is
already
null
for
the
default
according
to
its
signature,
that
one
could
just
be
a
default.
B
G
A
G
B
B
That's
fair
part
of
why
I
wanted
to
combine
using
that
numbering
scheme.
The
second
and
third
one
is
so
we
didn't
have
a
so.
We
had
a
stronger
affiliation
of
what
the
first
argument
was,
but.
B
That
the
first
argument
is
either
here
is
here
are
all
of
the
values
which
implicitly
has
a
vague
notion
of
capacity,
though,
if
it's
enumerable
and
not
accountable,
then
you
don't
that
really
get
a
notion
of
capacity
out
of
it
and
then
the
second
parameter
is
the
comparer
and
there's
not
an
other
notion
of,
and
the
first
parameter
sometimes
is
a
compare.
G
I
see
it
just
seems
like
for
a
priority
queue.
It
seems
like
just
like
with
some
of
our
other
collections.
Providing
a
compare
is
probably
one
of
the
most
common
things
that
someone
does
with
the
constructor
and
so
having
to
explicitly
either
pass
a
capacity
or
write.
Compare
colon
seems
unnecessarily.
You
know,
that's
fair.
B
B
We
know
that
more
than
we
know
that
two
default
arguments
is
enough
to
confuse
people.
We
know,
but
we
don't
know
if
explicitly
having
a
default.
Constructor
is
better
than
having
a
thing
that
has
one
default.
A
But
the
question
is:
is
there
any
doubts?
Are
there
any
downsides
to
you
know,
making
every
parameter
a
default
parameter.
A
Probably
want
to
keep
the
last
two
separate
because
they
built
the
heap
with
a
completely
except
in
a
completely
different
way,
so
I
wouldn't
understand
the
null
ability
of
that
argument
to
change
how
the
heap
is
constructed.
If
that
makes
sense,.
B
F
A
So
then,
you
have
some
obvious
public
properties,
getting
the
count
getting
the
compare
that
has
been
that
is
being
used
by
the
queue,
I
presume
nothing
too
controversial
here,
then
you
have
the
enqueue
operation
that,
as
the
name
explains,
it
accepts
a
an
element
and
a
priority
and
inserts
these
values
into
the
heap,
which
is
a
login
of
login
operation.
A
Then
you
have
the
peak
operation
that
gives
you
back
the
element
with
the
minimal
priority,
assuming
that
it
exists
again.
This
is
a
01
operation,
then
there's
the
dequeue
method
that
removes
the
element
with
a
minimal
priority
and
gives
it
back
to
you.
That's
an
old
logan
operation.
These
are
the
the
standard
heap
operations
that
I
just
described.
A
Then
we
have
the
tri
variants
for
dq
and
peak
that
can
give
you
back
that
that
first
of
all
do
not
throw
if
the
heap
is
empty,
but
I'm
also
capable
of
giving
back.
The
priority
is
assuming
that
you
need
it.
A
B
When
reading
through
it,
I
was
in
particular
of
trying
to
figure
out
what's
a
sensible
way
of
making
a
well-ordered
priority
queue
out
of
this,
I
was
like
well
if.
B
Could
know
when
I
can
like
recycle
some
numbers,
and
so
I
need
to
get
the
priority
somewhere
and
then
I
saw
the
tri
methods
and
that
solved
my
concern.
I
don't,
I
think
it's
fine
to
have
the
priorities
on
the
tries
and
not
on
the
non-tries.
A
A
A
Cool
then
there's
the
mqdq
operation
that
basically
implements
what
is
otherwise
known
as
pushpop,
which
basically
does
what
the
name
says
it
pushes
and
pops,
so
it
it.
It
removes
the
minimal
element
from
the
queue
and
inserts
the
one
that
you
provide
in
the
argument.
A
This
is
generally
more
efficient
than
doing
the
two
operations
separately
sequentially
because
it
basically
needs
to
sift
through
the
heap
only
once,
and
you
also
get
a
a
slight
benefit.
If
you
know
what
you're
trying
to
enqueue
is
actually
smaller
than
the
minimal
element,
then
it
just
gives
you
back
the
thing
that
you
just
passed
through
the
parameters-
and
this
is
a
generally
useful
operation,
especially
for
certain
algorithms
that
use
priority
queues.
So
I
thought
it
useful
to
add
that
one
as
well.
A
Good
question
maybe,
but
should
it
be
returned
as
an
out
parameter
or
should
we
return
a
tuple.
B
I
mean
if,
if
you
so,
I
think
steve
had
asked
when
people
actually
use
this,
and
you
had
an
example,
but
I
didn't
quite
follow
why
it
was
useful.
But
if
the
belief
is
that
most
of
the
time
no
one
cares
then,
instead
of
returning
the
tuple,
which
has
a
more
complicated
spill
and
a
return
than
having
the
out
be
a
when
you
want
it,
then
you
have
the
extra
cost,
as
an
overload
seems
better
to
me.
If
we're
you
know
caring
about
perf.
B
Sure
I
mean
they're
yeah,
there's
always
a
mild,
a
slightly
more
complicated
risk
of
breaking
changes.
If
you
go
from
non-overloaded
method
to
an
overloaded
method,
but.
B
H
B
H
So
I
have
one
question
from
chad,
which
is
more
high
level
question.
Might
I
want
to
ask
you
now
so
don't
forget
it
and
that's:
do
we
plan
on
having
a
concurrent
priority
queue
because
it
seems
like
queuing
is
one
of
those
areas
that
is
pretty
common
in
multi-threaded
environments,
or
do
we
think
the
concurrent
queues
already
have
an
equivalent
for
that.
G
A
Yeah
and
in
general
there
are
many
applications
where
a
non-concurrent
queue
would
be
very
useful
as
sorry
a
non-concurrent
priority
queue
would
be
useful,
so
you
know
we
might
consider
adding
a
concurrent
version
in
the
future,
but
you
know
that
goes
without
saying
that
we
should
still
love
this
one.
H
B
H
H
G
One
also
has
to
scale
whatever
you
come
up
with
it.
It
has
to
scale
better
than
just
using
lockswood.
So
if
all
you're
talking
about
is
producer
consumer,
I'm
not
sure
that
would
be
a
one
reader.
One
writer,
I
don't
even
know
what
algorithm
one
uses
for
a
concur
for
a
thread:
safe
priority
queue.
B
Yeah,
I
mean
the
scenario
for
threads
of
priority.
Queue
would
be
a
customer
service
phone
center,
where
you
have
priority
customers,
and
you
know
normal
subs
like
us,
and
you
know,
lots
of
phone
calls
come
in
concurrently
and
lots
of
representatives
are
handling
calls
concurrently,
but
that
could
centralize
mutex.
A
Somewhere,
okay,
so
any
other
questions
about
nqdq
in
particular,.
B
B
Yes,
there
should
be
a
remove
independent
of
clear,
because
that
basically
allows
you
to
decide
that
if
you're
willing
to
you
know,
move
something
to
the
back
of
a
different
line
and
you're
willing
to
do
the
linear
scan
to
remove
it.
But
like
there
is
a
you
can
do
update
priority,
you
just
don't
get
to
update
priority
with
any
notion
of
keeping
your
spot
and
it's
more
expensive,
but
it's
expensive
when
you
needed
the
scenario
instead
of
expensive
all
the
time.
A
Yeah,
I
I
mean
the
java
priority
queue,
which
is
very
similar
to
this.
Implementation
also
adds
this
method,
but
you
know,
obviously
it
has
been
strongly
criticized.
It
is
being
cited
as
a
workaround
for
the
update
mechanism,
but
it's
also
been
criticized
for
being
very
slow,
like
I
can't
imagine
that
it
would
really
hamper.
A
You
know
the
extras
algorithm.
For
example,
if
you're
in
is
significant.
H
B
I
B
B
B
I
mean
you
could
make
it
theoretically
faster
by
saying
you
have
to
tell
it
what
the
current
priority
is,
because
that
at
least
lets
you
stop
searching.
But
but
I
may
be
again
like
prashanth,
assuming
a
more
tree-like
implementation,
where
you
can
know
that
you've
not
found
something.
A
A
Couple
of
ways
you
could
make
this
more
efficient
like
like
I
said
so,
the
first
one
is
to
just
not
use
an
array
heap
and
use
like
a
proper
tree
and
on
each
enqueue
operation.
You
know
just
return
the
node
of
the
thing
that
you
happen
to
enqueue,
and
then
you
could
just
you
know,
use
that
when
you
update
the
priority,
but
that
means
more
allocations.
Obviously,
the
other
approach
is
to
just
include
a
hash
table
inside
your
priority.
A
Key
implementation
and
you'll
be
able
to
sort
of
quickly
work
out
the
index
of
the
the
element
you're
trying
to
update
relatively
quickly,
but
that
is
not
paid
for
play
because
then
for
every
enqueue
operation
for
every
operation
that
happens
in
the
heap,
you
would
need
to
also
update
the
hash
table,
and
that
comes
with
a
non-zero
cost.
B
A
I
feel
that
it
might,
you
know,
unblock
people
writing
algorithms
and
whiteboards
in
c
sharp
but
like
if,
for
you
know,
actual
applications,
it
might
bite
people,
I
would
say
we
should
probably
include
it,
but
our
documentation
should
make
it
adequately
clear
what
the
performance
cost
of
that
operation
is.
A
The
the
other
problem,
of
course,
is
that
if
you
have
duplicate
elements
like
if
you
have
so
so,
there
are
two
problems
with
this
method.
One
is
that
it
introduces
the
notion
of
equality
for
the
elements
themselves
rather
than
the
priorities.
A
B
You
would
then
want
to
presumably
take
a
comparer,
so
you
could
decide
how
you
wanted
to
deal
with
the
thing,
but
then,
if
it's
multiple
we
need
a
like,
is
it
there's
no
notion
of
first
really,
so
you
can't
tell
which
one
you
really
wanted
to
remove
so
yeah,
it's
an
easy
concept,
but
it's
a
hard
problem,
so
yeah
leaving
it
out,
seems
justified.
Then.
H
It's
also
kind
of
in
the
spirit
of
other
collections.
Right,
like
you,
could
make
the
exact
same
arguments
about
stack
right.
What,
if
I
messed
up
the
order-
and
I
want
to
swap
the
top
two
elements
or
something
right
like
it's,
the
assumption.
Is
you
get
your
priority
right
up
front
and
it's
immutable
right.
H
That's
basically
the
data
structure,
and
if
you
want
to
mess
with
that,
you
can,
but
then
you
have
to
dequeue
everything
up
until
that
element
and
requeue
everything
after
the
element
right
and
that's
the
same
that
stack
or
q
have
today
right.
So
I
I
think
that's
that's
a
fair
assumption
because,
again
like
if
we
add
methods
like
this,
I
really
hate
that
you
know
for
some
super
rare
event
later
on.
We
now
have
trouble
with
evolving
our
data
structure,
because
we,
you
know
supported
like
random
or
semi-random
access
somewhere
right,
yeah,
yeah.
B
A
B
Even
reference
equals
the
same
item
at
multiple
priorities
of
you
know,
which
one
is
it
going
to
find
and
remove
and
that
at
that
moment
the
problem
becomes
complicated
and
it
it's
not
the
real
pay
for
play
that
I
felt
that
it
was
for
letting
somebody
do
an
update.
It's
it's
a
completely
different
and
complicated
scenario,
and
and
it's
a
simple
sounding
question,
with
a
hard
answer
so.
A
Yeah,
like
all
the
applications
I've
seen
that
require
some
form
of
priority
update
like
they.
They
kind
of
assume
that
you
know
if
the
element
you've
enqueued
and
you
want
to
decrease
its
priority-
is
42,
for
example
there.
It
is
generally
the
case
that
you
wouldn't
store
the
same
thing
twice
unless
there's
a
bug
in
your
code
right.
A
H
I
see
so
our
data
structure
is
that
the
algorithm
on
the
consumer
side
likely
now
is
in
trouble
because
they
can't
handle
that,
but,
like
all
the
other
structure
would
be
fine
if
in
queueing,
the
same
object
once
a
priority
two
months
for
priority
five.
That
might
just
mean
that
you
get
the
same
element
back
twice
right.
H
H
Yeah,
we,
I
think
we
were
at
nqdq
or
what
was
the
last
one.
We
looked
at
yeah.
A
And
qdq
yeah,
so
next
one
is
nq
range,
which
you
know
does
what
you
would
expect
it
just
you
know
enqueues
a
a
sequence
of
element
and
priority
pairs.
Then
you
have
you
know
the
clear
operation
which
does
what
you
would
expect
it.
You
know
it
empties.
The
contents
of
the
priority
queue.
B
Within
q
range,
do
you
think
it's
also
worth
having
an
overload?
That's
innumerable
of
t
element,
comma
static,
t
priority.
B
B
So
if
you
want
to
add
20
things
all
at
the
same
priority,
instead
of
needing.
D
B
A
Yeah,
I
I'm
not
too
sure,
because
it
feels
like
you
know
you
just
use
a
select
to
you
know,
make
it
work,
assuming
that
you
want
to
apply
the
same
priority
to
everything
I
don't
know.
Is
it
like
a
common
thing.
B
It
feels
like
you
know
the
if
you
get
a
bunch
of,
if
I'm
thinking
of
things
in
really
only
two
priority
queue
right
of
normal
and
high
and
that
you
could
get
a
bunch
of
normals
coming
in
and
you're,
like,
oh,
go,
add
a
bunch
of
normals
and
that
if
you
had
stuff
as
an
innumerable
of
things,
to
add
that
now
you
need
to
use,
you
need
to
write
an
iterator
method
or
use
the
numeral
that
repeat
within
enroll.zip
or
whatever,
to
make
it
fit
this.
B
H
A
Generally,
what
I've
seen
is
that
priorities
are
numeric
values
and
most
often
enums,
so
you
you
tend
to
have
like
you
know
five
or
six
bands.
I
guess
so
in
that
sense,
if
you
yeah,
it
might
actually
make
sense
because
you
might
want
to
incur
a
batch
of
you
know,
tasks
that
will
have
the
same
priorities.
So
I
don't
know.
D
D
H
H
A
Okay,
so
basically
my
thinking
about
this
is
that
we
should
either
use
a
tuple
or
we
should
use
a
key
value
pair
now.
A
The
suggestion,
so
the
suggestion
is
either
we
implement
the
priority
qrs
proposed
here
or,
alternatively,
if
we
would
have
the
priority
queue
to
implement.
I
read
only
collection
of
key
value
pair
priority,
comma
element.
A
H
So
I
would
agree
with
that,
but
I
think
these
are
kind
of
orthogonal
things.
I
think
you
could
go
ahead
and,
for
example,
say
this
guy
here
implements,
I
whatever
the
suggestion,
was
right
with
keys
and
values
and
then
just
basically
do
an
explicit
implementation.
So
you
don't
actually
expose
keys,
but
you
could
still
expose
priorities
right.
B
Well,
it's
if
you're
returning
a
innumerable
key
value
pair
then
element
is
either
key
or
value
and
priority
is
the
other
one
and
it's
if
the
api
is
always
calling
them
element
priority,
but
you
get
back
a
key
and
a
value
which
one
was
which
and
yeah
exactly
so
I'll
say.
I
hate
value
tuple
in
public
api
and
I
think
that
this
used
it
correctly
so.
G
B
Correctly,
it's
the
same
argument
to
zip.
It's
there's
never
going
to
be
a
place
that
you
would
put
a
it
sorry,
unless
we
decided
that
the
that
it
was
going
to
return
a
thing
that
later
might
support
a
notion
of
update,
which
would
be
the
only
time
it
would
gain
a
method.
The
only
thing
that
you're
doing
is
it's.
I
need
to
enumerate
things
and
I'm
giving
you
two
pieces
of
information.
All
you're
going
to
do
is
deconstruct
it
at
which
point
value.
Tuple
is
the
right
answer.
B
Ever
want
to
gain
helper
methods
or
so
yeah
any
kind
of
utility
method,
or
you
know,
calculation,
properties
or
anything
that
will
tie
it
back
into
this
data
structure.
Then
it
would
want
to
custom
type,
but
basically,
if
it's
key
value
pair
and
key
and
value,
don't
naturally
align
with
what
it's
doing
value
tuple's
better.
H
B
Now,
if
people
agree
with
me-
and
we
shouldn't
call
a
thing
that
can't
maintain
ordering
at
the
same
priority
q-
and
we
call
it
priority
bag
and
we
want
to
be
a
priority
bag
of
key
value
pair-
that's
totally
fine,
but
yeah.
I
think
that
creating
a
new
type
for
this
would
be
a
waste
and
in
its
current
nomenclature,
key
value
pair
is
wrong.
A
H
Right,
that's
yeah.
I
just
read
the
comment
and
I
was
thinking
I
mean
on
the
one
inside
it
makes
sense.
On
the
other
hand,
it's
probably
surprising
that
you
know
the
data
structure
only
has
effectively.
You
know
nq
and
dq
semantics,
and
I
think
it
would
be
surprising
to
people
that
the
order
is
not
the
same.
A
Yeah,
okay,
I
mean
if,
if
we
were
to
fix
this,
then
it
would
be
as
expensive
as
just
you
know,
sorting
the
priority
queue
yeah.
B
Maybe
maybe
the
data
structure
doesn't
inherently
support
it,
but
it
feels
like
you
could
do
a
print.
You
could
do
a
walk
without
mutating
it,
because
this
enumerator
presumably
throws
if
there's
a
concurrent
modification,
so
it
all
it
needs
is
to
know
you
know.
What's
the
last
thing
it
walked
and
then
do
the
pretend
it
promoted
a
node
which
is
just.
B
H
G
G
G
H
B
H
A
A
B
If
dq
was
a
one,
then
then
making
a
an
iterator
seems
easy,
but
if
it's
log
n,
then
that's
different.
H
D
H
F
B
You
see
in
your
code,
you
know
pq
dot,
all
items
unsorted,
which
returns
an
and
I
enumerable
of.
H
H
B
Enumerating
yeah,
I
agree
that
there
can
be
some
like
you
want
to.
You
want
to
save
the
state
of
the
current,
like
you
want
to
save
all
the
data,
that's
in
the
queue,
because
your
process
is
shutting
down
like
right.
But
what
is
there
really
a
scenario
for
passing
that
as
an
I
enumerable
and
if
you
do
have
to
pass
it
as
an
ionumerable?
Is
it
complicated
to
have
to
go
through
a
method
first,
and
I
don't
think
it's
too
complicated
and
does
allow
us
to
to
name
the
enumerable.
A
H
I
mean
I
mean
the
questions
are
consumer.
B
G
Is
implicit?
It
is
like
like
not
that
it's
a
great
paradigm
of
a
great
example
of
design,
but
blocking
collection
implements,
I
innumerable,
but
then
it
also
exposes
a
method
that
gives
you
back
and
I
innumerable
the
special
semantics.
B
Yeah
yeah:
well,
I
meant
the
channels
pipelines
channel
lines.
G
H
Like
I
think,
most
people
will
probably
be
happy
with
just
the
elements
property
because
they
probably
don't
care
about
the
priority,
and
I
think
it's
somewhat
easier
to
explain.
The
elements
themselves
are
not
ordered
because
that's
the
same
semantic
you
get
from,
let's
say
dictionary
right,
because.
A
B
I
don't
think
priorities
makes
any
sense,
but
elements
and
items
good
luck,
figuring
out
that
one
seems
reasonable.
H
Yeah,
I'm
not
suggesting
adding
priorities.
I
was
just
thinking
like
you,
have
two
properties,
elements
and
elements
of
priorities.
Oh
okay,
and
so
I
think
that's
what
I'm
saying.
I
think
it's
fair
to
say
when
you
access
these
two.
They
are
not
ordered
because
that's
kind
of
what
you
have
with
keys
and.
D
H
G
J
H
I
mean
that's
fair,
I
mean
like
to
to
to
jeremy's
point.
I
mean
I'm
fine,
first
of
all,
with
suffixing
it
with
unordered
or
something
right
or
unprioritized,
whatever
the
phrases
you
want
to
put
there,
but
I
also
think
yeah,
I
think
intellisense
might
help
you
when
you
actually
say
dot
right
and
then
you
actually
see
something
popping
up.
H
It's
a
bit
harder
to
do
with
interface
implementations,
because
now
you
have
to
read
the
remarks
section
on
the
entire
data
structure,
which
is
as
I'm
just
experiencing,
not
that
easy,
because
I
still
can't
figure
out
what
the
sort
of
dictionary
semantics
are
and
I'm
staring
at
this
for
five
minutes
now.
So
is
the
proposal.
G
B
G
H
B
B
Do
a
destructive
like
if
you're
doing,
load
save
you
could
do
destructive.
You
just
keep
calling
try
dq
to
get
the
elements
with
priorities
so
that
you
can
write
down
what
your
state
was
and
then
rehydrate
it
later,
but
enumerating
also
may
be
sensible
in
that
context.
B
Yeah,
so
I
think
that,
just
because,
from
a
documentation
perspective
of
if
it's
a
property,
then
you
can
document
the
property
with
saying
this
is
unordered,
but
if
it's,
but
I
innumerable
is
yeah
zemo
said
it's,
it's
a
remark
in
the
class
comment
and
I
think
it's
an
easy
source
of
confusion,
especially
because
with
small
examples,
it's
probably
really
easy
to
accidentally
get
the
order
right.
B
It's
the
same
thing
with
people
that
dictionary
behaves
like
a
list
until
it
doesn't,
but
if
they
test
it
with
like
four
things,
it's
a
list
and
then
they
get
confused.
B
Then
you
could
then
cue
range
source
q,
dot
elements
with
priority.
Yeah
we're
not
saying
don't
have
the
data
we're
just
saying:
don't
have
the
type
itself
be
enumerable.
G
G
A
So
I
think
that
in
certain
cases
you
do
not
care
about
the
priority
at
all,
so
you
just
want
to
get
the
elements
in
the
queue.
H
H
C
So
I
mean
the
one
one
possibility:
is
you
have
two
priority
queues
and
you
want
to
check
for
equality
and
the
way
you
do
that
is
going
through
each
element
in
priority
and
checking
that
it
exists
in
the
other
one
and
then
vice
versa.
B
B
Which
would
mean
we
that's,
I
think,
steve's
question
of.
Why
do
we
want
elements,
as
distinct
from
elements
with
priorities?
Just
only
give
the
one,
and
if
you
have
a
scenario
where
you
didn't
care
about
the
priority
and
you
didn't
care
about
the
order
that
they
came
out
then
just
write
the
select
statement.
H
Yeah,
I
think
you
have
a
good
point
like
because
in
my
case,
when
you
look
at
dictionaries,
there
is
no
order
right
there
very
well.
You
saw
the
dictionary
and
like,
in
that
case
it
makes
sense,
because
you
just
treat
them
as
sets
right.
Your
order
doesn't
matter
but
yeah.
I
think
in
this
case,
given
that
you
use
priority
queue,
it
is
hard
to
think
of
cases
where
you
really
don't
care
about
the
order.
B
H
B
The
suffix,
I
think,
would
make
sense
if
we
had
items
which
was
sorted
and
really
expensive
and
we
were
coming
back
and
adding
items
unordered,
for
this
is
the
the
faster
one
if
you're
willing
to
deal
with
that,
but
otherwise
I
don't
think
that
we
would
add
this
the
ordered
one.
B
And
I
something
of
that,
whether
it's
the
custom
collection
just
so
it
can
be.
I
read
only
collection
and
eye
collection
or
it's.
I
enumerable.
H
B
All
right,
so
I
think
now
we're
too
clear.
B
D
B
B
Yeah
is
the
behavior
like
like
with
list
or
is.
B
D
B
H
H
Yeah,
which
I
think
is
I
think
in
short
capacity,
was
a
private
helper,
but
I'm
pretty
sure
we
exposed
it
somewhere
because
it
does
sound
very
familiar.
H
Yeah
dictionary
has
ensured
capacity,
that's
where
yeah
yeah,
I
think
it
makes
sense.
I
mean
I
think,
there's
nothing
wrong
with
ensure
capacity
and
dictionary
also
doesn't
expose
capacity
either
not
even
necessary.
Only
so
you
can't
even
ask
it.
F
B
I
mean
it's
it.
I
think
it's
one
of
those
that
well
list
returns
it.
I
don't
think
most
people
really
care
like.
Maybe
they
do
if
they're,
using
it
in
a
more
complicated
data
structure,
but
that
yeah,
basically
it's
hey,
I'm
about
to
add
100
things
and
I'm
not
going
through
yeah,
I'm
about
to
add
100
things
so
ensure
capacity,
count
plus
100
of
do
your
resizing
now
and
get
it
out
of
my
way,
especially
don't
grow
twice.
H
B
H
B
H
H
Seems
fine,
okay,
so
since
you're
in
the
bike
shooting
mode
I
have
so
where
does
this
king
ship,
presumably
where
the
rest
of
the
collections
are
going
or
are
we
shipping
this
as
a
standalone
thing.
G
H
B
So
since
that
doesn't
seem
to
have
a
easy
forthcoming
answer,
is
there
anything
under
here
in
open
questions?
We
haven't
already
talked
about.
A
I
think
I
think
we've
actually
covered
everything,
so
we
we,
we
we've
settled
for
using
a
value
tuple
for
the
enumerate,
enumerators
and
the
constructor.
I
guess
I
I
don't
think
do
we
have
a
sort
of
definitive
decision
on
whether
we
should
add
a
remove
method.
B
B
When
you
convinced
me
it
was
the
opposite
of
useful,
so
yeah.
B
H
If
you
have
a
specialized
data
structure
that
has
kind
of
concrete
semantics
now
you
get
data
in
and
out.
The
whole
point
of
infrastructure
is
to
optimize
for
those
cases
and
as
soon
as
you
throw
in
something
in
the
middle,
where
you
just
bypass
the
entire,
you
know
guaranteed
order
of
operations.
Then
you
make
your
implementation
more
complicated
and
also
borders.
The
only
thing
like.
B
Yeah
the
the
work
around
for
that,
and
I
mean
I
haven't
written
texture's
algorithm,
but
if
you've
looked
at
the
things
that
are
doing
it-
and
this
sounds
like
it
would
solve,
it
is
yeah.
You
make
a
wrapper
type
that
you
can
mark
as
this
is
a
dead
element
and
then
you
just
add
a
new
wrapper
type
with
the
new
priority.
So
you
don't
need
to
remove
anything.
You
just
need
to
yourself
have
already
been
able
to
find
a
reference
to
it
and
mark
it
as
dead.
B
H
B
H
B
Yeah,
so
I
think,
with
contain,
if
we
added
contains,
we
would
have
the
you
should
it
should
optionally.
Take
the
I
equality
comparer,
but
I
think
until
we
have
a
solid
scenario
for
why
someone
would
want
it,
and
it's
just
a
linear
scan
that
going
through
the
unordered
elements.
Property
seems
like
it,
you
can
solve
your
scenario
and
it's
with
essentially
the
same
perf.
D
A
A
For
remove
like
the
the
operation
to
the
there's,
there's
no
issue
with
the
with
removing
an
arbitrary
element
from
the
heap
like
you,
you
follow
the
standard
heap
modification
operations
that
take
long
time.
The
only
problem
is
actually
finding
that
element.
If
that's
sort
of
the
thing
that
takes
the
linear
scan.
H
H
D
H
A
A
Adding
a
remove
method
doesn't
negatively
impair
like
the
performance
of
people
that
use
the
regular
methods.
B
I
guess
contains
feels
weird
to
have
without
remove
and
we
can
and
you
can
solve
it
via
another
method.
Sorry
another
means
and
if
people
say
hey,
here's
the
reason
that
I
need
to
check
contains
and
needing
to
write
this
long
expression,
which
is
really
just
contains.
So
I've
made
an
extension
method.
Why
don't
you
add
it
to
on
the
type
then?
Now
we
understand
the
scenario
and
we
can
promote
it,
but
I
don't
think
there's
a
scenario
for
it.
J
D
B
Thing
do
you
actually
contains
this
because
yeah
the
interactive
debugger
doesn't
always
like
pandas.
B
H
B
J
So
it
seems
like
they're
kind
of
two
types
of
priority
queues.
Perhaps
there's
one
where
you've
got
a
very
small
handful
of
priorities
right
and
you're.
It's
mostly
a
queue
with
a
couple
priorities,
and
then
there's
one
where
it's
mostly
about
priorities.
Everything
has
its
own
priority
and
having
the
same
priority
is
actually
fairly
unusual,
and
so
you
don't
really
care
how
that
works,
and
it
seems
like
this
is
more.
The
latter,
which
is
fine.
We
just
should
set
expectations
properly.
B
J
Yeah,
I
that
said,
I
do
wonder
if
you're
not
better
off
just
having
five
cubes.
In
that
case,
you
know
what
I
mean
indeed,
but
by
the
way
I
agree,
but
that's
probably
a
much
more
common
user
scenario
like
I've
got
high
priority
work
and
I've
got
low
priority
work
and-
and
I
want
them
to
be-
I
want
to
have
a
few
semantics
for
both
of
those,
but
I
also
want
the
high
priority
work
to
take
precedence
over
the
low
priority
work.
I
don't
think
this
is
the
data
structure
for
them,
though,.
B
Yeah,
and
so
that's
where
it's
the
do,
we
you
know
agree
that
this
is
a
reasonable
data
structure
that
has
the
semantics,
but
that
it
should
use
a
word
other
than
q
priority
bag
was
the
thing
that
got
suggested
in
the
issue
after
I
brought
up
that.
I
don't
like
that.
It's
a
cube
that
doesn't
isn't
the
queue.
J
B
Yeah-
and
you
know
to
rehash
things
that
I
wrote
on
the
issue
wikipedia
for
q
is,
like
is
a
fifo
and
if
you
look
at
fifo,
it's
like
this
is
called
a
q
and
then,
if
you
look
at
priority
queue,
it's
like
some
implementations
are
a
q
and
some
are
not.
G
Yeah,
but
I
mean
when
q
is
used
with
other
stuff,
it
doesn't
maintain
that
meaning
like
work.
Stealing
q
is
explicitly
not
fibo
right
priority
queue.
It
varies,
so
I
think
if
q
alone,
maybe
but
q
in
other
contexts,
kind
of
have
to
give
up
on
that.
I
similarly
in
college,
my
first
professor
in
computer
science
drilled
into
me
that
the
word
recurse
meant
to
swear
again
and
their
proper
words
recur.
I've
had
to
give
up
on
that
in
real
code
bases
as
well.
G
B
J
B
Yeah,
if
I'm
the
odder,
I
just.
I
really
really
really
hope
that
I
never
call
anyone
that
uses
this
for
their
phone
customer
service
phone
ordering.
A
Repeating
something
that
has
already
been
stated
in
the
comments,
it
is
relatively
straightforward
for
users
to
obtain
the
stability
invariant,
and
that
is
typically
done
by
making
the
priority
a
more
complex
type.
For
example,
making
it
a
tuple
where
sort
of
the
first
element
is
the
actual
priority,
and
the
second
element
is
a
number
like
the
sort
of
the
order
of
something
being
enqueued
or
its
timestamp.
Or
what
have.
E
B
H
B
So
the
your
first
bullet
adding
queue
range.
I
enumerable
t
element
values
needs
a
comma
t
priority
priority.
B
B
D
G
H
D
G
H
G
B
B
H
H
G
With
not
implementing
interface
has
nothing
to
do
with
the
name
space.
I
just
think
it's
strange
to
non-bluetooth
interface.
It's
a
collection
all
of
our
collections,
all
of
our
meaningful
collections
implement
I
enumerable,
but
I've
said
my
piece.
J
Yeah
I
mean
why
do
you
use
an
innumerable
on
a
dictionary
probably
for
stuff,
like
dumping
it
out
or
saving
it
to
persisting
it
somewhere?
I
think
the
exact
arguments
that
apply
to
dictionary
apply
here
too.
Don't.
B
But
I
think
that
we
all
we
often
see
complaints
from
users
that,
if
they
add
four
items
to
a
dictionary
and
they
for
each
it
it's
in
the
order
that
they
added
them
and
when
they
add
400
items
it's
not
and
they're
like
this
is
weird
and
inconsistent.
You
should
fix
it
and
by
fix
it,
they
don't
mean
make
it
always
be
random,
they
mean
they
could
always
be
determined
or
make
it
always
be
the
thing
they
want
it
to
be.
I'm.
G
B
I
think
it's
if
you
have
like
a
dictionary
of
int,
where
the
hash
codes
are
predictable,
as
in
it's
itself,.
B
Then
the
first
couple
of
then
the
buckets
end
up
being
ordered
and
it
walks
the
buckets
in
the
bucket
order
and
and
your
items
are
all
understandable,
because
your
capacity
was
big
enough
that
you
don't
have
bucket
sharing.
E
A
I
think
I
think
the
main
problem
here
stems
from
the
fact
that
you
know
enumerating
a
regular
queue
guarantees
ordering,
so
I
think
people
might
just
you
know,
copy
and
paste
some
code
that
consumes
a
queue
and
accept
expect
that
you
know
the
same
thing
will
happen
with
priority
queue.
I
think
that's
the
biggest
risk
yep,
so
I
I
would
certainly
think
that
we
should
use
the
property
instead.
H
H
I
mean
that's
the
my
quote,
for
was
it
like
the
chernobyl
series
right,
not
great,
not
terrible,
right
like
it's,
it
seems
like
for
correct
code.
Maybe
that's
not
too
terrible
right.
G
H
Yeah
I
mean
it
seems
to
me
like
if
we
were
to
do
this,
I
mean
we
can't.
I
mean
it's
early
for
six
right.
So,
like
I
mean
I'm
okay
with
experimenting
right,
I
mean
okay,
we're
saying:
let's
revisit
this
and
see
what
happens,
the
only
problem
is
if
we
just
wait
for
signal
and
the
signal
doesn't
come,
that
doesn't
mean
that
people
are
not
surprised.
It
might
just
mean
that
people
are
not
actually
using
the
collection,
but
I
I'd
be
shocked.
If
people
will
not
stumble
over
this
as
a
behavior.
B
I
mean
I,
I
think,
that
we
have
in
versions
of
net
core
that
tell
us
that
we
don't
that
we
get
much
better
feedback.
Three
days
after
we
ship
than
we
do
for
the
entire
preview
period.
B
H
J
H
That
seems
the
most
or
the
least
riskiest
and
the
the
most
easiest
to
drive
from
a
data
perspective.
A
A
Roll
back
sorry,
would
we
would
we
then
delete
the
property
as
well,
or
is
that
not
an
option.
H
Well,
it
kind
of
depends
on
what
we
do
right.
So
if
we,
if
we
go
with
what
I
said,
it
would
still
add
value.
If
you
go
with
what
stephen
said,
then
you
have
two
ways
of
doing
the
same
thing,
which
is
not
entirely
horrible
right,
because
you
could
still
argue
the
person
who
does
it.
They
can
just
say.
Well,
it's
clearer
if
I
add
the
dot
unordered
items
in
the
middle
right,
it
would
be
a
bit
unfortunate,
but
it
was
it
wouldn't
be
terrible
but
yeah,
depending
on
when
we
find
out
right.
H
H
B
B
I
guess
you
could
you
keep
calling
try
dq
and
you
drain
everything
out
of
it,
but
it
you're
making
it
hard
to
to
do
process
save
and
load.
B
B
B
And
it'll
it'll
be
net
six's
version
of
we
changed
what
double
dot
two
string
does.
A
By
the
way,
I
have
the
impression,
though,
that
the
order
that
is
currently
being
returned
isn't
entirely
garbage,
because
I
believe
it's
the
optimal
sequence
when
you
perform
a
hebify
operation.
So
I
believe
that,
if
you
were
to,
for
example,
serialize
priority
queue.
If
you
were
to
reconstruct
the
priority
queue
on
this
realization,
then
it
would
be.
A
H
B
Fair
enough
I
mean,
I
think,
we're
but
making
it
be.
I
innumerable
then
has
the
does
it
guarantee
dq
order,
which
I
think
steve
will
have
strong
opinions
about,
and
I
might
even
agree
with
them
wow.
I
picked
a
perf
over
usability
in
the
yeah.
So
if
it's
not
sorted,
it'll
confuse
people
and
if
it's
sorted
it's
expensive.
A
H
H
Yeah
no
deal
breaker
weird
right,
I
mean
it
is
a
very
specialized
connection.
Right
I
mean
if
we
plot
all
the
people
in
the
world
that
use
it.
We
are
probably
talking
about
like
yeah.
What
is
it
less
than
five
percent?
Probably
right,
so
I'm
okay
with
saying
yeah,
it's
a
specialized
type
and
it
comes
with
specialized
semantics.
G
Eric,
I
assume
the
elements
property
returns
is
lazily
initialized
and
returns
the
same.
A
Not
in
my
prototype
but
yeah
that
should
be.
That
should
be
the
case
in.
A
A
H
A
H
Yeah,
it's
the
little
kid
gif
right,
yay,
all
right.
H
Then
I
think
we
can
look
at
other
things
in
the
backlog.
Does
anybody
have
a
particular
item
they
want
to
look
at?
B
One
question
as
we're:
shutting
that
down
with
the
so
the
unordered
items
we
had
a
property,
so
presumably
that
means
it's
giving
back
the
same
object
the
same
allocated
thing
on
every
call.
So
does
that
mean
that
it's
that
it,
I
guess
it's
get?
Enumerator
is
snapshots
of
what
the
collection
looks
like
at
the
time.
So
you
can
grab
the
collection,
add
to
the
priority
queue
and
iterate
again,
add
to
the
priority
queue
and
iterate
again
and
that
doesn't
throw.
But
if
you're
in
the
for
each,
when
you
add,
then
that
throws.
H
G
B
B
G
G
So
because
we're
exposing
a
struct
enumerator,
most
likely
as
we
would
and
assuming
we
want
it
nested
under
element
collection,
most
likely
it
would
just
have
internals
access
to
or
private.
You
know
it's
a
nested
type.
It
has
private's
access
to
everything
in
the
priority
queue,
so
it
has
a
reference.
The
priority
queue
and
just
accesses
it.
B
H
It
was
just
me
but
like
after
two
levels
of
nesting,
I
kind
of
give
up
all
right.
So
50
minutes
left.
K
I've
got
some,
probably
small,
numerix
ones,
sure
go
for
it,
which
one
four
three
one:
six
nine
and
four
three
seven,
three
three.
H
H
K
Okay,
yeah,
so
sign
codes
is
an
api
that
native
compilers
either
provide
directly
or
they
implement
as
an
optimization
where,
if
they
detect
sign
and
codes
called
near
each
other,
it
will
just
compute
both
at
once.
It's
an
optimization
useful
for
a
lot
of
various
apis
that
end
up
requiring
one
or
both
methods,
because
when
you
compute
one,
you
generally
need
the
other
and
computing
both
simultaneously
is
considerably
cheaper
than
computing
them
independently.
K
The
first
one
is
we
just
repo
return,
both
as
outputs
the
second
one
is
we
return
one
value
and
we
out
the
other
and
you'd
have
to
recognize
it
by
name
this
kind
of
matches.
How
div
rem
works
today
and
the
third
is
we
return
both
as
a
value
tuple,
which
is
the
actual
one.
I
think
we
should
do
as
that's
the
one
that
legit
will
optimize
with
the
recent
changes
that
have
gone
in.
B
H
K
D
H
B
In
color
code
it
shouldn't
be
but
yeah
if,
if
the
register
allocator
plays
nicely
with
the
value
tuple
return,
especially
if
it
plays
nice
early
with
the
value
to
put
return,
then
I'll
reluctantly
agree
that
that's
a
good
use
of
value.
H
K
Probably
have
to
talk
to
carol
to
determine
how
she
implemented.
K
F
I'll
ask
the
the
same
question
I
always
do,
which
is:
does
it
have
well-defined
behavior
when
it
sees
not
a
number
infinity
blah
blah?
Yes,.
K
B
And
I
guess
more
importantly,
in
those
boundary
cases
they
will
behave
the
same
as
the
sine
and
cosine
methods.
K
Yes
and
the
tests
that
we
end
up
adding
will
validate
that
as
well.
D
K
Was
that
that
one
is
there
too,
but
I
was
four
three
seven
three
three
might
be
a
better
one
to
look
at
first
they're
they're
semi-related
are
these
the
ininda
and
you
and
ones
yeah.
K
These
are
basically
both
just
proposals
to
expose
missing
apis,
but
the
the
innant
ones
have
actually
been
requested
for
real
scenarios,
whereas
the
unsigned
ones
they've
had
fewer
requests
from
the
community
overall.
K
So
so,
four,
four
three
seven
three
three:
it's
basically
we
exposed
several
math
apis
that
work
with
all
of
the
existing
integral
types
by
s.
Byte
short,
you
short
int
you
in
long
you
long
now
that
we
actually
have
native
integer
as
well
as
a
new,
primitive
type.
We
should
expose
these
abs,
absolute
value,
clamp,
div,
rem,
max
min
and
sine
for
these,
as
well
with
sine
and
absolute
value
in
div
rim,
being
only
for
the
cyan
types
to
match
how
how
it
is
for
int
versus
long.
K
Yeah,
so
big
mold
doesn't
make
sense,
because
big
mole
is
taking
a
an
input
of
one
precision
and
returning
an
output,
that's
twice
the
precision,
so
32
bits
and
returning
64
or
64
bits
and
returning
128.
K
I
think
you'd
have
to
like
return,
half
the
result
and
then
out
the
other
half
both
as
the
input
type
like
we're
doing
with
long
today.
K
Right
with
divrem,
it
might
be
nice
if
we
changed
it
to
remainder
as
the
result,
instead
of
result
and
left
and
right
for
instead
of
a
and
b
just
because
it
always
comes
out
that
that's
confusing.
K
The
other
thing
with
avram
is
that
it's
matching
the
existing
signature
for
consistency,
but
returning
a
value
tuple
would
be
clearer
and
produce
better
code
gen
moving
forward.
So
that's
a
decision
of
should
we
be
consistent
with
the
existing
integral
overloads,
or
should
we
just
go
ahead
and
make
that
break,
which
is
what
the
next,
which
is
what
the
42156
was
going
over.
H
B
K
Yeah,
the
the
four
two
one
five
six
is
covering:
we
don't
expose
div
rem
for
any
of
the
unsigned
types
and
it
covers
the
the
value.
Tuple
pattern
is
the
thing
that's
better
for
code
gen,
and
maybe
we
should
just
expose
all
of
them
like
that.
Moving
forward.
H
K
So
so
the
proposal
covers
two
parts:
one
is
the
we're
missing
these
overloads
right,
especially
for
the
unsigned
types
and
then
at
the
bottom.
I
called
I
called
out
that
the
value
tuple
pattern
is
is
the
pattern
that
has
been
optimized
with
the
register
allocator.
So
it's
likely
the
pattern.
We
should
move
use
moving
forward.
So
it's
a
question
of.
Do
we
want
to
be
consistent?
H
So
I
think
we
should
probably
I
mean
if
we
think
I
mean
feasibility
wise.
I
agree
with
jeremy,
it
seems
better
to
just
have
the
the
you
know
named
basically
name
tuple
elements
would
indicate
which
one
is
which,
but
which
is
probably
more
helpful,
and
it's
more
consistent.
I
mean
if,
if
that's
what
we
want
to
do,
then
I
would,
I
would
not
add
new
overloads
under
the
old
pattern.
I
would
just
say:
yeah.
H
We
only
exposed
the
new
one
and
you
know
we
can
do
it
for
the
existing
ones
anyway,
because
we
can
overload
based,
on
the
you
know,
absence
of
an
odd
parameter,
and
that
seems
fine.
H
H
Yeah,
adding
the
new
ones
and
simultaneously
also.
H
Not
good
so
it
would
be,
and
we
probably
should
do
it
for
math.
I
guess
math
f
doesn't
make
sense,
because
there's
no
floating
point
here.
H
H
Good
all
right,
then
this
is
it
for
today.
Then
I
see
you
guys
next
week
again.