►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
B
C
B
B
The
this
is
functionally
similar.
It
just
deals
with
the
unsigned
type
rather
than
the
sign
type
most
of
our
own
internal
usages
are
actually
calling
single
to
in
32
bits
today
and
casting
to
you
it
because,
when
you're
doing
bit
manipulation
on
the
underlying
value,
particularly
because
extracting
the
exponent
or
other
parts
of
the
of
the
floating
point
format,
you
don't
want
to
preserve
the
sign
bit
when
doing
the
shift,
operations
or
other
or
or
other
arithmetic
related
things.
And
so
you
actually
want
it
to
be
unsigned.
C
D
B
Right
and
it's
potentially
a
correctness
concern
for
other
users,
so
I
think
it's
it's
trivial
to
expose
the
helper
method
that
just
returns
you
in
and
takes
you
in.
It
increases
the
surface
area
minimally,
while
making
it
simpler
and
easier
to
maintain
the
code
in
question
that
that
you
are
writing.
E
G
E
B
B
B
So
it's
effectively
a
trivial
helper
method,
oriented
around
the
more
correct
usage
of
this
type,
and
if
we
were
doing
this
today,
I'd
probably
recommend
we
do
all
of
them
as
unsigned,
but
I'm
guessing
it
wasn't
done
that
way
in
v1,
because
unsigned
types
are
not
cls
compliant.
B
What
about
double
yeah?
It
should
also
be
there
for
double
and
half.
I
think
this
was
opened
before
we
had
discussed
those.
C
C
H
A
B
If
you
go
to
the
the
last
post
in
the
issue,
I
linked
to
the
places
we're
doing
it
in
source.net.
B
Right,
the
the
majority
case
is,
we
end
up
casting
to
unsigned
whenever
we
are
doing
bit
shift
operations.
If
we're
comparing
against
a
constant
value,
we
typically
keep
it
as
signed,
except
for
when
we
have
to
compare
against
a
negative
hexadecimal
representation,
in
which
case
we
either
have
cast
to
unsigned
or
on
the
constant
value
we
have
unchecked
cast
int
0x8
rest
of
value.
B
B
B
A
A
B
B
So
this
is
another
one
of
a
fairly
common
bit
hack
that
you
would
commonly
end
up
trying
to
implement
yourself
via
the,
for
example,
stanford
website
that
lists
common
bit
hacks.
It's
just
rounding
an
integral
value
up
to
the
nearest
power
of
two.
If
it's
already
a
power
of
two,
it
doesn't
change.
B
This
is
frequently
used
for
memory
when
dealing
with
memory.
For
example,
when
you
want
to
ensure
that
you're
going
up
to
an
x
power
of
two
or
that,
for
example,
an
alignment
should
be
power,
a
power
of
two.
B
So
here
is,
for
example,
linkedin
chat,
the
the
one
example
of
the
recommended
optimization
and
a
discussion
on
how
many
code
instructions
it
compiles
down
to
and
potential
other
optimizations
if
you
have,
for
example,
an
optimized
log
of
two
implementation.
B
So
so
the
naive
approach
is
just
a
series
of
shifts,
but
the
optimized
approach
is
effectively
a
leading,
a
leading,
zero
count,
a
subtraction
and
then
a
left.
B
B
E
B
So
we
we've
been
putting
the
the
math
seems
to
be
relegated
mostly
to
common
math
operations
and
floating
point,
whereas
bit
operations
has
been
centering
itself
around
specifically
integral
values
where
you
have
bitwise
bitwise
optimizations,
to
make
them
extremely
fast
or
often
even
one
instruction.
C
A
B
I'm
not
convinced
that
there
would
be
in
particular,
is
power
of
two
is
a
common
operation.
We
use
it
in
the
bcl
ourselves
and
it's
also
used
by
basically
every
memory
allocator
in
existence,
whereas,
if
you're
looking
for
other
powers,
those
generally
don't
have
a
quick
and
short
instruction
sequence.
You
can
execute
to
determine,
and
I
don't
know
how
frequently
they
would
be
used.
B
I
think
that's
a
different
api
and
I
think
we
would
be
in
I.
I
think
it
would
be
interesting
to
find
out
what
the
use
case
would
be
for
that
and
how
frequently
it
might
be
used.
I
know,
for
example,
one
operation
that
is
fairly
frequent
in
the
similar
vein
is
divide,
but
rounding
up
rather
than
down,
because
the
the
typical
pattern
for
division
is
to
round
down
with
integrals,
but
you
frequently
want
to
round
up
instead.
A
So
the
the
reason
I
asked
the
reason
go
ahead.
The
reason
I
bring
it
up
is
is
the
use
case
you
illustrated
for
this.
One
is
like
when
you
want
to
have
alignment
in
memory
and
that's
actually
one
of
the
use
we
use
it
in
in
apache
arrow.
We,
we
use
a
similar
operation
here
in
apache
arrow
to
try
to
get
things.
A
yeah,
but
it's
like
two
lines
of
code
right.
It's
kind
of
like
use
the
use
the
bit
hack
in
the
code
side.
It's
probably
just
yeah
extra.
B
What
the
use
case
would
be
and
whether
or
not
there's
a
general
algorithm
we
could
expose
here
for
for
round
up
to
the
nearest
multiple
of
an
arbitrary
value.
E
B
B
B
B
B
I
think
it's
special
for
two
and
ten
in
particular,
because
that's
what
the
c
runtime
has
that's
what
the
c
runtime
did
and
therefore
that's
what
we
did
in
math
and
therefore
that's
what
I
prefer:
what
I've
proposed
for
all
future
math
and
numerix
related
editions:
okay,
okay,
because
that's
also
typically,
what
you
see
when
you're
doing
when
you're
writing
mathematical
expressions,
you
you'd
have
log
sub
expression:
2,
not
log
sub
expression,.
B
B
Yeah,
if
we
we
could
do
signed
as
well
but
signed,
would
for
all
negative
values,
they'd
become
one
which
seems
like
it's
undesirable.
In
most
cases,.
A
B
A
C
I
C
See
it's
one
of
those
examples
where
no
matter
what
I
do,
I
I
don't
do
the
right
thing.
Like
last
time
I
attacked
10
people
and
then
we
got
to
two
issues
and
then
I
felt
bad
for
everybody
I
attacked
now
I
only
attacked
a
few
people
and
you
may
know
me:
we
may
need
more
people,
so
you
never
know
all
right.
So
I
guess
this
is
also
10.
Alright,.
B
Yep,
so
this
is
just
saying
when
we,
when
we
went
and
approved
the
api
editions
to
int,
pointer
and
uint
pointer
for
the
init
and
inuint
primitives,
it
looks
like
there's
some
parse
and
tri-format
overloads,
specifically
dealing
with
spans
that
we
did
not
expose
so
it's
proposing
that
we
expose
them
so
that
way.
Users
dealing
with
native
integers
can
also
parse
and
format
values
in
an
allocation-free
way.
A
B
I
think
I
think
the
pattern,
so
how
far
has
been
when
it's
an
api
that's
been
around
since,
like
dot
net,
1,
0
or
2
0,
we
don't
use
default
values
and
new
overloads,
don't
use
it
as
well.
But
when
it
came
to
introducing
the
read-only
span
overloads
because
they
were
new
overloads,
we
were
able
to
use
defaultable
values
instead
of
defining
four
variants.
B
I
don't
think
we
have
the
same
overloads
for
tripars
on
on
in
32,
for
example.
Today,.
B
Do
we
then
yeah?
We
should
have
them
here
as
well.
No,
we
just
have
the
two
that
are
proposed
here.
It
looks
like
the
one
that
takes
all
four
and
the
one
that
takes
two.
A
A
B
D
B
We
we
made
when
back
before
5.0
shipped,
we
reviewed
a
bunch
of
api
editions
to
these
types
and
for
whatever
reason
I
forgot,
the
read
only
span
overloads.
B
It's
worth
calling
out
someone
on
youtube
asked
if
they
should
return
in
an
inuit
instead,
and
I
responded
that
there's
an
identity
conversion
between
init
and
pointer
and
so
taking
a
returning,
uint
pointer
and
in
pointer
rather
than
the
primitive
keyword
just
matches.
What
we've
done
for
all
the
other
exposed
apis
and
there'll
be
no
usability
issue
here.
K
B
Right
so
so
you
can
do
a
addition
operations
if
it's
in
it
and
other
operations
that
that
were
available
in
il
but
not
exposed
on
the
on
the
type
so
operators,
basically,
but
unless
you're
doing
bar
x,
equals
and
pointer.parse,
then
it
won't
be
an
issue.
B
C
B
Back
into
ptr,
but
I'd
have
to
check
look.
K
Yeah,
but
if
you
statically
type
it
instead
of
using
var,
which
is
I'm
aware,
it's
static,
but
it's
let's
call
it
dynamically
statically
typed.
If
you
write
the
word
in
it,
then
everything
works
fine.
And
so,
if
you
call
tripartist
and
say,
outvar
results,
it's
interpreter
and
if
you
say
out
in
an
out
init
result,
then
you
have
a
number.
C
C
C
C
All
right
so
then
another
one
from
center.
That's
the
one
we
just
reviewed
okay,
then
I
didn't
close
it.
I
guess,
or
I've
approved
some
of
the
api.
Oh
no,
I
just
opened
it
twice.
Okay,
this
is
miriam,
I
believe,
is
miriam
on
the
call.
D
D
Good
hi
for
this
one,
it's
just
basically
two
extensions
methods
on
options
builder,
and
the
idea
is
that
today,
when
we
have
the
capability
we
already
have
today,
is
that
when
we
start
an
application,
we
don't
we
can.
We
are.
We
can
do
validation
on
options,
but
it
doesn't
happen
at
application
startup,
and
in
order
to
allow
that
to
happen,
we
would
need.
We
would
need
these
two
apis
basically
validate
eagerly
and
validate
annotation
and
girly.
D
The
kind
of
I
tried
to
summarize
everything
I
had
like
a
comment
wise
and
like
conversation,
was
anything
that
happened
throughout
the
issue
in
the
description.
So,
if
you
have
any
questions.
D
I
believe
what
happens
is
you
would
use
vanilla
iota
to
validate
annotations
to
build
the
data
annotations
today,
but
you'd
have
to
wait
until
request
using
that
gets
triggered.
So
then
it
will
lazily
validate.
So
you
wouldn't
get
validation
errors
until
you
make
a
request
that
involves
that
option.
Basically,.
D
So,
for
example,
if
I
have
a
connection
string
somewhere
coming
up
through
some
options,
if
I
don't
exercise
a
request
that
happens
to
use
that
connection
string,
not
until
that
time
we
will
not
get
any
validation
adders,
but
this
will
make
sure
that
that
when
you
do
the
startup
you
do
you
get
that
you
get
few
fail.
If
you
have
validation
issues
with
your
options,.
C
C
Yeah,
so
I
guess
what
I'm
trying
to
figure
out
is
like
what
is
the
difference
between
eagerly
and
non-eagerly,
like
because
I
mean
it
because
it's
clearly
you're
invoking
code
at
the
point
you
call
the
method
so
clearly
by
the
data.
Annotations
non-eagerly
doesn't
do
something
that
eagerly
does,
and
I
still
don't
understand.
C
D
Basically,
the
idea
is
that,
as
as
steve
mentioned,
the
way
current
validations
data,
annotation
validation
of
options
happen
today,
is
that
you
will
not
get
your
options
validated
until
they
are
requested
to
be
resolved.
I
believe,
through
the
eye,
and
once
they
get
resolved,
that's
when
they
are
kind
of
getting
a
validation
code
also
gets
run
on
them
and
rather
than
doing
that
later
after
the
application
started.
J
D
D
Yeah,
so
it's
like,
like
in
a
little
bit
of
implementation
detail,
would
be
that
there
would
be
a
hosted
service
that
would
get
added
and
as
part
of
the
startup,
it
will
run
and
validate
all
of
the
options
and
then
kind
of
give
an
aggregate
exception
out.
With
all
of
the
failures.
D
Like
throughout
the
conversations
like
in
the
comment
section
earlier,
one
recommendation
was
to
use
a
I
startup
filter,
which
is
kind
of
like.
I
think,
if
I
believe
it's
like
a
it
adds
a
pipeline
while
you're
doing
startup
in
order
to
do
the
validation,
but
then
the
the
feedback,
for
that
was
that
we
don't
want
it
to
be
host
specific
and
we-
and
I
believe
that
they
said
they
wanted
to
be.
D
They
wanted
to
actually
be
working
for
generic
hosts
as
well
and
like
a
more
generic
option,
was
to
use
hostessers.
But
that's
implementation
detail
for
either
approach.
We
can
still
use
these
two
new
apis.
D
C
D
A
D
How
do
I
say
I
also
didn't
find
any
anywhere
else
that
they're,
like
there's
a
pattern
of
name
like
eagerly,
but
so,
but.
C
H
I
guess
like
one
of
my
concerns
comes
to
like
implementation
like
as
far
as
I
understand
and
not
like
an
expert
on
I
validate
options,
I'm
like
bruising
through
the
code
right
now,
but
it
seems
like
I
validate
options-
is
an
interface
that
services
implement.
So
what
about
those
so
like
until
you've
built
the
service
provider?
H
Is
it
too
early
to
run
those,
but
it
could
just
be
my
lack
of
understanding
there.
I
also
see
that
there's
a
to
do
about
named
option
support
yeah.
D
I
think,
like
the
prototype,
that's
still
already
there,
it
doesn't
support
named
options,
but
I
don't
think
the
api
would
need
to
change
for
it
to
kind
of
support
so
like
the
to
do.
I
have
is
kind
of
like
maybe
in
a
separate
later
iteration,
to
figure
out
how
to
support
that,
and
the
limitation
that
I
put
over
there
is
that
we
have
three
different
types
of
options:
eye
options
which
is,
as
I
put
down
there
and
a
summary.
D
C
D
I
don't
think
it's
a.
Let
me
check
again.
A
C
D
H
So
to
be
yeah
to
make
sure
I'm
understanding
what's
going
on
with
this
change
so
with
validate
eagerly,
it
doesn't
throw
in
line
right
like
it
would
still
wait
until
like
the
service
provider
was
built.
So
is
this
idea
more
like
the
ice
startup
filter,
where
basically,
once
you're
in
configure
that's
when
you
validate
like
after
the
service
provider,
is
built,
or
is
it
like
supposed
to
throw
out
a
validate
eagerly.
D
H
D
A
H
H
A
K
D
The
way
I
propose
api
edition
is
on
another
helper
class.
That
is
that.
Are
you
asking
a
piece
of
the
name
options
builder
then,
at
data
annotation,
extensions.
A
A
D
D
C
C
D
Sorry,
just
checking
right
now.
D
I
don't
know
I'll
get
back
to
you
on
this
one.
C
So
I
think
we
said
we
would
prefer
on
startup
over
eagerly.
What
is
it
fear.
D
D
I
think
I
think
I
could
be
wrong,
but
it
is
possible
to
just
use
validate
eagerly
without
using
validate
data
annotations
api.
If
we
do
when
we're
like
using
other
api,
such
as,
let's
say
I'm
just
looking
at
a
sample
given
services
services,
we
add
the
option,
we
configure
it
and
then
we
validate
it
specifically
for
something
and
then
call
validate
eagerly.
D
A
C
D
Sure
sure,
though,
just
from
just
to
give
something
from
like
from
what
I
just
looked
really
quick
is
the
the
reason
there's
both
of
them
here.
Both
apis
is
that,
as
you
see
in
the
usage,
if
I
do
add
options,
and
I
call
validate
and
annotations
and
validate
eagerly,
I
believe,
validate
annotations
would
check
the
class
that
options
class
and
do
all
of
the
validations
based
on
some
attributes
that
are
on
it.
D
D
If
someone
wanted
to
do
both
of
them
at
the
same
time,
the
validate
annotation
really
is
for
that,
specifically,
so
that
they,
if
they
don't,
have
custom
validation
to
kind
of
write
down
inline
by
just
relying
on
the
annotation
of
the
annotated,
like
required
attributes
on
the
class,
they
can
just
use
the
combined
over
the
combined
api.
C
A
C
D
The
way
it's
renamed
now,
but
if
there
are
more
restrictions
for
validation
that
I
want
to
provide
for
some
of
its
properties,
then
I
would
be
rather
than
in
the
usage
you
see
in
the
screen,
rather
than
those
three
lines
instead
of
saying
so,
I
would
still
write
down
the
first
line,
services.add
options,
my
options,
then
I
would
do
configure
to
say:
let's
say
if
it
has
a
boolean,
it
has
to
be
false
and
then
another
one
to
say
dot
validate.
D
I
want
the
boolean
to
always
be
true,
so
this
one
that
says
validates-
and
I
want
billion
to
always
be
true-
would
replace
the
second
line
in
the
usage
and
then
I
would
call
validated,
but.
C
D
D
Yes,
they
have
validate
data
annotations,
yes,
and
these
two
would
be
extra.
A
C
D
Some
reason,
I
think,
I
think
it's
sufficient
to
add
just
one
api
and
that's
the
second
one,
the
one
that
says
validate
eagerly
which
we
renamed
to
validate
on
startup
and
the
other
one
was
just
a
convenience.
J
D
It
won't
block
anyone's
if
it's
not
there.
So
to
start,
we
could
just
have
the
one
that
you
have
named
as
validate.
Was
it
on
startup
rather
than
validate
eagerly
about
validate
secretly,
because
okay,
that's
sufficient.
C
C
Oh,
thank
you
all
right.
So
then,
where
is
my
brother
right
now?
Here
we
go
all
right,
so
we
just
did
that
and
I
think
this
is.
We
are
jeff
mark
this.
I
think
ready
for
review.
F
F
F
All
those
platform
attributes
and
some
of
the
operating
system
platform
check
methods
accept
the
string
argument
which
expressing
the
platform
and
of
optional
version
part.
So
this
is
proposing
this
analysis
analyzer
for
checking
the.
If
that
string
argument
is
correct,
if
the
platform
name
is
known
platform
name
and
if
the
version
is
parsable.
F
Well,
this
this
exact
example
is
showing
the
checking
for
the
platform.
Name
is
known,
so
we're
planning
to
collect
platform
names
from
operating
system
platform,
check
methods
we
added
in
fiverr
and
also
from
the
image,
build
item
group
supported
platforms
list
and
then
we'll
check
the
platforms
against
that
and
plus
to
this.
I
think
we
also
need
to
check
that
if
the
version
part
is
possible
if
it's
provided-
and
there
is
some
example-
if
you
scroll
down
more
and.
F
So
the
first
example
there
is
window
is
not
invalid
platform
and
we
will
plug
that,
and
second
version
is
not
personable.
It
should
be
like
at
least
two
numbers
with
separate
by
dot
two
to
four
number
separate
by
dot.
F
C
Yeah,
so
that
makes
sense.
So
basically,
I
think
we
had
another
conversation.
We
talked
about
how
we,
how
we
know
which
platform
names
are
valid,
and
I
think
when
I
wrote
this
issue,
I
proposed
that
we
just
look
at
the
the
method
names
on
operating
system.
A
C
C
You
may
have
multiple
times
in
your
in
your
whole
thing,
so
it
seems
generally
speaking
more
worthwhile
to
validate
you
know
what
occurs
more
frequently
and
it
seems
also
worthwhile
to
support
what
merrick
wanted,
which
is
you
can
tell
the
system,
yeah
yeah,
there's
a
platform,
you
don't
know
about
it.
Yet
that's
fine!
C
I
still
want
to
be
able
to
put
them
on
attributes
and
don't
you
know
not
get
warnings,
so
we
should
probably
I
don't
know
whether
you
edit
this
as
a
comment
here,
but
I
think
we
should
probably
call
this
out
somewhere
in
here
that
it's
the
union
of
both.
I
C
C
C
F
Yeah,
it
is
also
kind
of
related,
so
we
can
add
multiple
platform,
attributes
and
also
platform
attributes
applied
to
the
top
level.
Member
will
apply
to
the
all
members
within
that
container.
So
we
need
to
have
some
rules
to
have
to
ovulate
those
nesting
and.
F
So
this
is
one
of
the
examples
for
the
thing
we
have
a.
We
have
a
rule
where
nested
apis
cannot
be
expanding.
The
parent
platform
support
in
this
case
like
if
this
type
sum
is
suppose
only
for
ios,
then
the
members
inside
it
cannot
support
anything
else,
and
we
want
to
flag
that
and
if
you
scroll
down,
there
is
more
example.
We
want
to
cover
with
this
analyzer
like
first
one
can
be
the
nesting
and
then
next
ones
we
want
to
flag
for
the
in
case.
F
C
So
the
first
example
makes
sense
to
me
because,
basically
you
you
have
two
minimum
bounds,
but
then
the
second
one
seems
reasonable.
No
because
basically
it
would
mean
the
platform
also
did
something
weird
but
like
that
doesn't
seem
illegal
right,
because
the
basically
it
says,
okay,
we
introduced
the
ap
on
ios
12.
Then
we
decided
to
remove
the
api
on
is
14
and
then
in
ios
15.
We
changed
our
mind
and
edit
the
api
again.
F
Well,
that
is
first
doesn't
for
me.
It
doesn't
really
make
sense
like
by
my
understanding
and
support
is
like
kind
of
the
api's
absolute
kind
of
remote
and
and
making
it
available
back
is,
of
course,
doesn't
make
much
sense,
and
second,
it's
just
making
more
complicated
logic
so
that
we
need
to
have
keep
track
of
many
range.
Certainly
so,
right
now,
like.
K
Though
no
it's
unheard
of,
I
know
it's
unheard
of
that
you
know
apple
or
us
would
listen
to
customer
feedback
about
having
deleted
things,
but
it
could
happen
that
something
got
removed
and
after
a
bunch
of
complaints,
it
comes
back.
C
C
I
mean
I
would
say
I
would
not
bet
my
life
on
it.
So
I
mean,
as
jeremy
said
I
mean.net.
We
have
done
exactly
that
thing.
Right.
Net
standards
started
with
removing
everything,
and
then
we
changed
our
mind
and
added
a
bunch
of
stuff
back
because
it
broke
too
many
things.
So,
but
I
mean
even
in
this
standard,
it's
kind
of
like
it's,
you
know
we
we
never
really
removed.
C
We
just
added
a
new
thing,
called
net
standard
with
fewer
apis,
and
that
thing
was
only
ever
growing
like
we
didn't
make
breaking
changes
between
versions
of
of
of
net
standard
right.
So
I
think
windows
did
the
same
thing
right
when
they
started
windows
8
they
effectively
didn't
add
all
the
win32
apis
and
then
over
time
they
added
more
and
more
of
these
apis
back
right,
but,
like
that's,
that
is
similar
to
what
net
standard
did
right.
So
I'm,
okay
with
it.
C
F
C
F
Yes,
if
there
is
like
there
is
no
support
in
between
that
choose
unsupported,
then
the
later
support
will
be
just
yeah
right
now,
it's
just
ignoring,
but
now
we
want
to
one
for
them
right.
C
Yeah
I
mean
the
second
case
is,
makes
perfect
sense
because
it's
duplicated
the
third
one.
Sorry,
the
first
one
is
similar
to
the
previous
one
like
in
principle
that
doesn't
seem
impossible
right
like
it
should
like
it's.
Logically,
it's
not
inconsistent
or
anything,
it
just
seems
unlikely.
So
I
think
same
thing.
It's
okay
to
say.
C
We
can't
express
that
today
because
of
the
way
our
analyzer
is
written,
but
if
we
ever
need
it,
we
would
have
to
edit
right,
but
that
seems
reasonable
anybody
any
concerns
of
this
or
it
seems
to
me
the
same
same
rule.
I
would
make
it
a
warning.
I
would
have
it
on
by
default,
because
we
want
people
who
annotate
apis
to
have
some
sanity
checking.
C
C
This
might
cause
some
thoughts
for
the
goods
based
on
how
we
emit
them
today,
but
I
think
we
need
to
handle
that
no
matter
what
so,
I
think
the
general
rule
to
say
you
can't
widen
support,
makes
sense
and
we
should
validate
that
and
then
we
should
just
deal
with
the
multi-targeting
issue
that
we
currently
have.
K
G
F
Whatever
for
this,
one
fixer
could
suggest
just
to
remove
the
inconsistent
attribute,
but
for
the
trailers
analyzer,
I
forgot
to
mention
that
it
doesn't
makes
looks
like
it
doesn't
make
sense
to
have
a
fixer
like
for
for
correctness
of
the
platform
name
or
versioning.
K
C
G
Yeah,
this
is
just
continuing
the
conversation
we
have
last
tuesday.
We
were
basically
short
of
approving
this
because
we
were.
G
Exposing
a
queryable
overload-
and
I
suppose
the
answer
is
like
we
really
should,
because
we
do
that
for
all
methods
that
expose
us
it's
returning
enumerable.
So
we
should
we
should
avoid.
We
should
avoid
having
eye
credibles
binding
to
the
mobile
overload,
so
yeah.
C
G
Yeah,
so
we
we
are
checking
for
parity
for
every
link
method,
with
a
few
exceptions,
and
the
exceptions
are
typically
methods
that
return
things
like
dictionaries
or
you
know,
types
that
don't
necessarily
do
not
do
not
have
any
correspondence
in
queryable
like
the
rule
is
if
something
returns
our
enumerable.
You
should
definitely
create
a
credible
overload.
G
G
I
G
C
G
Okay,
so
basically,
the
proposal,
as
the
title
suggests,
is
extending
the
existing
distinct
except
intercept,
intersect,
gillian
min
and
max
methods
with
by
counterparts
and,
basically,
what
that
means
is.
G
These
would
basically
complement
the
existing
overloads
of
distinct,
et
cetera,
et
cetera,
et
cetera,
but
currently
accept
higher
quality
compares,
and
these
would
actually
accept
key
selectors
instead,
obviously,
we're
also
exposing
other
loans
that
to
accept
higher
quality.
Compare
for
the
key,
because,
I
suppose,
there's
president
precedent
in
the
api
and
that's
more
or
less
the
gist
of
this.
So
you
know
distinct
by
just
simply
implements
distinct,
accepting
a
key
selector
instead
of
a
high
quality.
G
Compare
you
have
the
max,
buy
and
min
by
overloads
that
again
accept
a
key
selector
for
determining
for
determining
the
comparable,
the
the
ordinal
for
selecting
the
minimal
and
maximal
elements
in
the
collection
and
the
final
two
methods
are
really
just
additions
of
overlords
that
should
have
been
in
link
but
are
simply
missing.
So
I've
added
those
for
completeness.
G
C
G
Actually,
sorry
to
drop,
but
I
think
the
last
two
methods
are
a
typo.
They
should
not
be
accepting
a
funk
argument.
I
I
think
I
I
did
a
mistake
there
in
copying
and
pasting
that
the
last
method
should
really
take
an
annual
source.
I
know
the
customer,
I
compare
it
yeah
that
makes.
C
Sense
so
my
only
question
is
we
don't
make
any
guarantees
in
order
right?
So
if
you
say
just
think
by
it's
just
like
well,
you
get
whatever
thing
happens
to
be
first
for
our
purposes
here,
but
that
might
change
between
releases
right.
G
A
C
G
Get
my
assumption
is
that
whatever
semantics
we
have
for
the
existing
distinct,
etc
methods,
we
would
follow
the
exact
same
semantics
in
these
new
overlays,
fair.
C
G
Correct
you
could
technically
still
achieve
this
using
the
existing
distinct
method.
However,
you'd
have
to
implement
a
custom
high
quality.
Compare
that
projects
to
the
key
you're
interested
in
distincting
by
so
fair
enough.
G
And
I
I
think
I
have
a
question
for
everybody
here.
If
you
scroll
a
bit
to
the
right.
G
So
you
see
that,
like
we've
added
overloads
that
accept
a
custom,
high
quality
compare
or
I
compare
for
the
key
type.
My
gut
feeling
is
that
this
is
kind
of
overkill,
because,
typically,
when
you
project
to
a
key
that
key
is
typically
like
some
kind
of
ordinal.
That
already
has
like
well-defined
either
equality
or
comparison
semantics.
G
So
I'm
wondering
whether
we
really
need
those
that
being
said,
there
is
precedent.
We've
done
this
elsewhere,
but
I
want
to
get
like.
C
Use
the
compara
it's
because
of
string,
sensitive
case
sensitivity
and
in
almost
no
cases
do
I
care
about
the
casing,
like
like
very
very
recent
example.
Like
you
know,
the
api
review
backs.
The
themesof.net
website
basically
uses
issue.
Ids
is
the
key,
but
the
issue
id
itself
is
not
unique.
So
previously,
with
the
you
know,
dotnet
slash
repo
pound
whatever,
but
I
don't
trust
that
I
get
everybody
in
the
same.
You
know
casing,
so
I
I
would
probably
for
strings
almost
always
use
the
overloads.
To
take
the
compare
I
mean.
C
K
C
K
C
K
Matches
the
current
type
style
yeah,
it
makes
sense
for
for
strings.
If
yeah,
do
you
want
case
insensitive
or
do
you
want
to
pull
in
one
of
the
culture
comparers
that'll
treat?
What's
oh,
you
know
oe.
C
K
C
C
H
K
G
There
is
another
I
guess,
design
consideration
that
was
prompted
by
the
original
poster
that
I
would
like
to
bring
up.
If
you
scroll
a
bit
further
down,
email
you'll
see
that
there's
a
second
api
proposal
that
was
the
sort
of
original
api
proposal
right
that
one.
So
if
you
notice
here,
like
I
like
to
draw
your
attention
to
the
accept,
buy
and
intersect
by
overloads
and
you'll,
see
here,
actually
that
sort
of
the
the
second
and
third
overloads
in
the
proposal
actually
support
heterogeneous
animals.
G
So,
like
the
you
know
that
the
second
thing
that
you're
accepting
can
be
of
a
different
type,
and
the
idea
is
that
the
function
accepts
two
different
key
selectors,
one
for
the
first
sequence
and
another
for
the
second
sequence,
effectively
making
this
a
join-like
construct
right.
The
sorry.
G
Yeah
I
kind
of
pushed
back
on
that
design,
because
I
kind
of
feel
that
this
is
a
very
different
beast
compared
to
what
our
existing
exact
methods
and
intersect
methods
are
doing.
It's
not
like
you
know,
set
difference
or
intersection
in
you
know,
set
theoretic
terms.
It
is
something
very
similar,
but
also
very
different.
So
a
I'm
not
necessarily
convinced
that
this
is
useful
and
b.
If
we
do
decide
to
add
it,
it
should
probably
carry
a
different
name.
C
And
so
in
that
case
the
t
source
is
kind
of
a
red
herring
right
because
you're
just
saying
well
just
subtract
the
key.
So
I
can
see
this
being
useful
and
if
you
wanted,
I
don't
know
how
else
you
would
do
it
because
you
would
basically
have
to
normalize
the
stuff
first,
but
that
kind
of
defeats
the
point
for
calling
the
buy
methods
right.
K
Right
because
the
to
go
back
to
my
you
know,
log
message
thing,
because
I'm
not
capable
of
complex
thought.
If
you
had
a
filtered
list
of
you,
know
users
whose
messages
you
don't
want
to
see.
I
mean
yes,
you
could
do
your
messages
and
then
a
where
not.
But
if
you
had
an
innumerable
of
your
don't
show
me
these
users
list,
then
you
would
want
messages
except
by
list
of
user
ids.
To
ignore
source
goes
to
message.uid.
K
Like
that,
I
can
see
the
scenario.
I
don't
think
it
would
be
very
common
and
you
can
you
can
work
around
it
easily.
So
unless
there's
a
strong
need
for
it,
I
think
it's
fine
to
wait,
but
I
can
see
where
it
has
value.
C
Yeah
I
mean
equally,
though
I
understand
the
concern
because
I
mean
these
are
not
I
mean
I
mean
link
overloads,
usually
have
not
pretty
you
know,
completion
because
they
are
like
you
know.
Beefy
constructs
usually,
and
these
ones
certainly
don't
help
with
that.
But
I
don't
know
they
remind
me
a
lot
of
the
you
know
the
zip
apis
where
yeah
they
look
a
little
bit
awful,
but
then
they
do
exactly
what
you
want
and
if
they
don't
do
that,
it's
it's
they're,
pretty
not.
You
know
useful.
I
guess.
G
You
know
this
kind
of
generality,
with
the
accept
and
intersect
methods
right,
you
couldn't
do
it
with
union
and
you
couldn't
do
it
with
this
thing
because
like
well,
this
thing
is
a
completely
different
piece
right,
but
you
can't
do
it
with
union,
and
that
kind
of
this
seems
to
indicate
to
me
that
this
is
like
a
different
operation.
C
A
K
Yeah
I
mean
like,
I
think
that
they
would
make
sense
as
the
names
accept
and
intersect,
because
they're
both
one's
an
inclusive
filter
and
the
other
is
an
exclusive
filter
of
where
you
have
the
the
complex
world
where
you
have
t
source
to
like
needing
a
key
selector.
I
don't
know
that
I
like.
Maybe
it
would
be
intersect,
no
that
but
that's
the
first
one
intersect
by
the
the
first
thing
in
the
in
the
filter
of
keys
right,
because.
K
G
So
what
is
the
proposal?
So
we
to
the
original
api
proposal
we
have.
The
first
overload
that's
proposed,
where
the
second
innumerable
is
of
type
t
key.
So
supposing,
supposing
you
have
a
heterogeneous
collection,
you
can
just
do
a
select
within
the
argument.
Is
that
what
you
were
saying?
Jeremy.
K
Yeah
yeah,
so
you
have
you
know:
log
messages,
dot,
accept
ignore
ids,
comma
m,
to
m
dot
uid.
K
That
sounds
so
gross,
though
I'm
sorry
like
they
have
to
be
an
extra
select.
No,
that's
the
key
selector
yeah!
That's
the
thing
that
you
wanted
to
do
this.
For
yes,.
H
H
K
A
K
Or
only
show
me
messages
by
these
two
uids.
So
yes,
that's
technically
messages
where
the
uid
is
in
the
set,
but
that's
the
same
as
saying
messages:
dot,
intersect,
filtered
uids
and
then
now
you
need
a
key
selector,
so
you
can
match
them
of
that.
The
message
the
thing
I
want
you
to
filter
by
is
the
user
id.
C
Well,
it
depends
on
which
overlord
you're
talking
about
right.
I
mean
in
the
first
one
you
you
pass
in
the
thing
that
you
want
to
intersect
and
then
you
basically
say:
well,
you
give
me
the
keys
as
an
innumerable,
so
you
don't
need
a
key
selector
for
the
second
one,
and
then
you
only
give
a
key
selector
for
the
first
one
right
right.
C
C
K
Yeah,
I
don't
know
that
our
implementation
is
better
than
doing
basically
double
for
each,
but
assuming
it
is,
then,
if
you
write
it
as
the
as
the
select
you
force
the
double
for
each
which
time,
if
you
write
the
where
you've
forced
a
double
for.
G
Each
yeah
and
that
actually
works
also
for
cases
where
you
don't
need
to
do
a
select
in
the
first
place,
where
you
have
like
just
a
sequence
of
the
things
you
want
to
all
the
keys.
Basically
right,
I.
I
also
think
that,
like
you
know,
link
methods
that
take
too
many
lambdas
as
parameters.
For
me,
that's
no.
K
Yeah
yeah,
I
think
that
for
the
the
highlighted
one
or
partially
highlighted
one,
I
think
that
there's
value
in
that
the
next
two
can
be
written
in
terms
of
the
first
yeah.
C
G
Correct,
presumably
with
an
high
quality,
compare
overload.
K
The
no
the
one
where
they're
both
t
source
is
in
the
earlier
set.
We
already
talked
about.
H
G
C
Okay,
okay,
so
it's
only
about
when
the
when
they
types
mismatch.
Basically
right,
that's
the
way
to
think
about
it.
H
J
C
C
C
I
E
G
By
the
way,
unless
you've
already
done
it
just
a
reminder
that
there's
a
typo
in
the
last
max
and
man
overloads
yup.
C
G
One,
I
I
think,
if
you
scroll
down
to
the
iquerable
segment,
the
second
argument
should
be
annumables
rather
than
like
variables,.
K
F
K
C
All
right,
I
can
do
that
right,
incense,
so,
for
so
does
it
mean
for
a
new
move?
We
need
to
change
the
parameter
names
or
as
first
or
second,
the
right
one.
C
C
G
G
C
I
C
All
right
so
then,
I
think
we're
out
of
time
and
we
took
the
big
one
today.
So
pretty
good
yeah.