►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
Hello
friends
and
actually
minimize
my
audio
panel
now
alrighty,
so
I
think
the
visualization
one
just
popped
in
because
I
don't
think
that
was
on
the
radar
before.
B
Yeah,
that's
mine
yeah,
so
this
is
a
pretty
straightforward
request.
It's
basically
exposing
a
compare
property
in
concurrent
dictionary,
in
line
with
the
other
hash
table,
implementations
that
we
have
in
collections,
that's
it
more
or
less.
It
would
be
a
non-nullable
property
also.
So
if,
in
line
again
with
dictionary,
it
would
return
a
quality
compare.default
if
none
was
specified
by
the
user.
C
Do
any
other
concurrent
things
take
a
compare?
That's
a
good
question.
A
A
C
A
Indeed,
let
me
check
the
other
ones
I
feel
like
now.
It
is
one
more
for
eric
a
line,
api
surfaces.
That
would
be
this
one
here.
B
B
There
goes
the
meeting,
so
this
basically
follows
a
series
of
other
api
proposals
that
basically
introduce
parity
between
the
immutable
builder
types
and
the
actual
immutable
types.
We
generally
we
in
prince
in
principle.
We
do
ensure
that
there
is
parity,
so
this
is
basically
just
adding
everything
that
is
missing
in
this
case,
so
the
the
this
was
compiled
by
the
user.
B
I've
also
kind
of
decided
that
removing
certain
methods
that
didn't
make
any
sense
in
the
in
in
the
context
of
a
mutable
builder
type,
but
this
would
more
or
less
make
sure
that
there
is
a
one-to-one
parity
between
the
mutable
collections
and
their
corresponding
builder.
B
D
Do
we
know
if
there's
going
to
be
any
concerns
from
them
from
extending
this
to
include
these
new
types.
B
That
I
do
not
know
personally
what
types
of
issues
are
you
referring
to.
D
Vs
depends
on
a
particular
version
of
system
collections.
Immutable
roslyn
depends
on
one
and
they
need
to
stay
in
sync.
B
D
D
It
might
just
be
worth
a
small
sync
up
with
jared
to
find
out
who's
responsible
for
that,
since
it's
not
andy
anymore
and
make
sure
that
they're
not
going
to
be
broken
at
all
by
or
at
least
that
they're
aware
that
there's
going
to
be
changes
here.
D
Every
time
we've
wrapped
system
collections
immutable
in
the
past.
It's
caused
pain
points
for
roslyn
because
of
having
to
coordinate
between
what
they're,
using
in
one
of
their
targets
versus
what
exists
in
vs.
D
That's
somewhat
automatic
when
they
go
in
start
multi-targeting.
The
latest.net.
D
C
A
Yeah,
I
think
in
general
I
mean
like
they
are
on
the
distribution
list
of
the
of
the
designs
right,
so
they
will
get
an
email
like
everybody
else
that
we
add
these
apis.
A
But
it
seems
to
me
the
general
justice.
You
know:
don't
update
the
vs
copy,
don't
update
the
thing
that
they
depend
on
so
seems
reasonable
in
general,
but
yeah.
I
don't
think
it's
acceptable
for
us
to
not
add
apis,
because
of
that,
so
I
mean
they
boiled
down
to
them,
giving
us
giving
them
a
heads
up
and
saying
this
is
coming.
B
B
A
A
A
A
A
A
A
B
Odd
yeah,
I
I
guess
the
up.
The
spirit
of
the
proposal
is
to
just
I,
I
guess,
inc
incorporate
what
exists
in
the
other
type
without
innovating
in
that
space,
because
there
were
other
opportunities
as
well
in
other
methods,
and
we
kind
of
decided
that
that
would.
A
A
Well,
interesting,
okay,
so
it
literally
is
just
what's
on
the
builder
today
which
yeah
okay,
so
that's
not
great,
then
yeah
I
mean
I
buy
that
like
if
it's
literally
just
doing
that,
then
I
think
it's
also
easier
to
review.
A
B
I
I
mean,
for
example,
there
were
certain
methods
where
you
know
with
the
offsets.
Like
you
mentioned,
where
you
know
you
could
consider
you
know
taking
a
span
argument,
but
you
know
in
that
case
you
know,
why
not
add
it
to
the
original
method
as
well,
and
you
know,
lo
and
behold,
it
becomes
a
completely
orthogonal
concern.
A
Do
we
generally
have
like
unit
tests
for
stuff,
like
that,
where
we
say
you
know,
we
say
you
know,
keep
service
area
a
consistent
service
area
b.
This
is
usually
a
thing.
We
do
sorry.
Could
you
repeat
that?
Do
we
sometimes
have
unit
tests
that
basically
validate
that
surface
area
a
is
replicated
in
type
b.
D
Would
it
be
worthwhile
just
having
a
internal
interface
like
we've
got
ispan
formattable,
which
is
internal
and
we've
got
that
on
various
types?
We
could
theoretically
have
an
internal
immutable
array
methods.
D
That
both
builder
and
the
and
the
non-builder
type
implement,
and
then
that
would
ensure
that
they
stay
in
sync.
And
since
it's
internal,
we
don't
have
to
worry
about
versioning,
really,
particularly.
A
Never
actually
used
yeah.
I
think
the
reason
I'm
bringing
this
up
is
because
we
recently
discussed
before
exten,
enumerable
and
exteriorable
right.
So
it
seems
like
that
will
be
all
scenario
where
we
want
to
make
sure
that
as
we're
adding
ua
no
items,
we
do
it
consistently.
D
C
B
B
D
The
the
author
of
the
proposals
on
youtube-
and
they
mentioned
that
it
looks
like
immutable
array
builder-
has
a
reverse
method-
that's
not
being
proposed,
as
mirrored
on
immutable
array
here,
because
it
would
hide
the
link
method
and
therefore
it
would
potentially
be
a
source
breaking
change
for
some
users.
D
Would
that
actually
be
a
source
breaking
change
since
immutable
array
implements,
I
innumerable
and
therefore
it
does,
and
so
therefore
it
would
still
implicitly
convert
it
would
just
end
up
doing
so
by
boxing,
which
it
would
already.
B
B
A
D
A
I
mean
you
can
totally
construct
cases
where
you
do
right,
where
let's
say
you
pass
a
tool,
a
method
that
is
overloaded
between
a
new
mobile
and
immutable
array.
You
know
you're
calling
the
other
one
right.
I
mean
I
I
agree
with
you
that
it's
probably
not
a
biggie
and
honestly
like
force
breaking
changes
like
this
seems
like
something
I
would
be
willing
to
do,
but
it's
probably
also
fair
to
say
that
it's
not
a
you
know,
drop-in
replacement,
that
just
every
code
will
always
compile.
A
C
I
don't
and
really
see
where
the
source
break
would
come
on
this
one,
because
I
think
the
only
concrete
type
we
bring
back
from
reverse.
Is
I
enumerable.
So
that's
the
only
thing
you
could.
So
that's
the
static
type
declared
as
the
return,
and
I
don't
think
the
type
it
returns
is
even
public.
So
the
only
thing
that
you
could
be
doing
from
the
current
call
was
putting
it
in
an
innumerable
instance.
C
The
type
we
would
return
implements.
I
enumerable
it
would
be
assignable.
You
would
then
get
the
problem
that
if
you
started
depending
on
the
new
method
and
then
like
cross
compiled
you'd
get
a.
I
can't
convert
this
error,
which
would
confuse
you,
but
it
wouldn't
be
breaking
for
anyone
going
forward.
C
A
B
For
what
it's
worth,
I
checked
the
link,
reverse
implementation,
and
it's
also
just
copying
the
source
into
a
buffer
which
surprises
me
so
fun.
Fundamentally,
you
wouldn't
see
a
big
difference
in
what
actually
happens.
B
That
was
the
only
one
that
was
removed
out
of
concerns,
for
you
know,
just
you
know,
link
I
I
guess
using
that
method
shadowing
the
link
equivalent,
the
other
ones
were
removed,
primarily
for
reasons
that
they
just
weren't
a
good
fit
for
a
mutable
type.
So
if
you
scroll
up,
there
is
an
enumeration
of
those
in
the
conversation.
A
I
mean
honestly,
like
I
am
okay
with
leaving
it
as
is,
and
just
approving
this
as
this
and
then
basically
saying
whoever
does
the
work.
The
first
thing
you
should
do
is,
you
know,
do
the
whatever
we
do
either
the
interface
or
the
testing
and
then
just
see
what
actually
is
complained
about
and
then
have
a
conversation
on
those
things
and
then
just
decide
whether
we
either
convince
ourselves
the
breaking
change.
B
Now
the
methods
that
I
recommended
removing
you
could
actually
achieve
the
exact
same
result
with
immutable
builder.
So
if
you
scroll
down
a
bit,
there's
an
a
method
in
immutable,
sorted
dictionary
called
set
items
where
you
basically
set
a
sequence
of
key
value
pairs.
Now
that
would
be
a
very
unusual
method
to
expose
an
immutable
dictionary,
because
you
would
just
use
a
for
each
with
an
indexer
right.
So
so
my
my
argument
is
that
you
know
we
could
say
that
hey.
B
We
just
need
to
have
100
parity
between
the
two
types
or
we
can
say
that
you
know
because
they're
fundamentally
different,
you
can
essentially
achieve
the
exact
same
goal
with
the
standard
access
patterns
of
you
know,
mutable
dictionaries.
A
You
basically
lower
the
bar
for
people
to
go
from
the
build
like
to
the
builder.
I
think
I
could
probably
live
with
the
reverse,
meaning
I
think
it's
okay
to
say
when
you
go
from
a
builder
to
immutable,
you
lose
some
expressiveness.
So
in
that
sense
I
think
the
builder
should
probably
be
super
set.
If
anything
because
like
we
don't
want
to
have
people
like
to
necessarily
say.
Oh,
I
go
away
from
the
builder
because
that's
that's
that's
easier
because
then
you
just
you,
have
less
efficient
code
right.
B
Sure
I
I
guess
if
we
were
to
stretch
that
logic
to
its,
you
know
to
its
logical
conclusion.
You
know
I
could
additionally
argue
that
you
know
the
api
signatures
should
match
as
well.
So,
for
example,
you
know
if
we're
looking
at
that
specific
set
items
method
in
the
immutable
version
it
actually
returns.
B
A
B
This
is
the
way,
then,
let's
do
it
that
way,
so
that
you
can
just
copy
and
paste,
and
you
know,
change
the
type
and
it
still
compiles
right.
A
Well,
the
problem
of
doing
that
is
that
that's
just
an
api
breaking
change
right.
We
can't
change
return
types
for
existing
methods,
so
anything
that
returns
void
today
will
have
to
return
void
in
the
future
yeah.
But
yeah
I
mean
that's
a
good
point
like
if
we
I
mean
on
the
immutable
type,
you
always
have
to
use
the
return
type.
Otherwise
you
just
didn't
do
anything.
A
So
that
means
every
time
you
go
from
an
immutable
one
to
a
mutable
one,
like
you
know,
the
code
will
probably
not
compound,
no
matter
what,
in
which
case,
you
know,
if
you're
back
to
picking
and
choosing
anyway.
So
then
maybe
just
leave
it
as
will
be
what
we
have
today
and
then
it
also
seems
at
that
point.
The
whatever
unit
test
we
have
would
be
more
complicated
because
we
couldn't
do
it
with
an
interface,
because
the
ticking
shifts
would
differ
right.
A
B
A
A
A
It
is
easier
than
I
expected
it
to
be,
and
I
think
all
the
other
ones
are
now
analyzers.
I
believe
yes,
so
so
I
think
we
start
with
this
guy
here
right
and
then
the
rest
is
just
depending
on
how
far
we
get
all
right.
Carl.
E
E
If
it's
not,
if
they
are
not
byte
type
by
the
right
type,
then
we
cannot
use
the
length
property
for
the
count
argument
because
it
wouldn't
be
invite.
So
it
might
be
easier
to
understand
if
you
scroll
down
to
the
example.
C
But
because
buffer
block
copy
is
so
it's
the
thing
it
wants
to
copy
is
the
number
of
bytes
right
yeah.
So
if
you
have
a
thing,
that's
more
than
one
byte
you're
just
going
to
fail,
because
it's
not
big
enough
right.
So
this
is
really
like.
I
mean
we
can
do
the
analyzer,
but
really
everyone
should
just
figure
this
out
immediately
when
you
hit
the
line
of
code.
C
Unless
we're
saying
that
we
want
the
suggested
you
wrote
the
line
of
code
and
we
squiggle
it,
and
we
say
you
probably
mean
divided
by
size
of
thingy,
but
you
probably
can't
use
sizeof
because
you're,
probably
not
in
unsafe
code
right
and.
C
E
E
We
decided
that
maybe
a
fixture
wouldn't
be
appropriate.
Only
the
analyzer
and
let
the
user
choose.
A
E
D
E
If
we
just
byte
or
s
byte,
then
using
lens
is
okay.
E
C
C
A
That's
a
strong
statement
I
mean
I
don't
know
like
in
general.
I
prefer
like
design
time
error
of
the
design
time
rather
than
having
to
run
my
tests
for
that.
But
I
mean
I
hear
what
you're
saying
like
it
would
never
work
or,
like
you
know
any
example
that
would
work
would
be
fairly
contrived.
So
but
it's
possible
that
you're
looking
at
the
result
and
you
will
be
very
confused-
why
it
doesn't
work
right
versus
if
you.
C
Actually
get
it
quickly
yeah,
I
suppose
I
guess
my
question
is:
what's
the
value
that
the
analyzer
is
adding
if
it's
that
we're
adding
a
very
helpful
hey,
this
works
in
the
number
of
bytes
and
you're
passing
an
array.link.
This
probably
isn't
what
you
want,
as
opposed
to
the
exception
message,
which
is
length
too
large
and
you're.
Like
I
passed
link
it
can't
be
too
large,
then
I
guess
that
would
be
where
the
value
comes
in.
But
if
it's
just
hey
this
isn't
going
to
work,
it
turns
out.
The
runtime
will
tell
you
that
too.
A
A
A
Elements
I
mean
that's
a
fair
question,
I
mean
the
answer
is
usually
you
know.
However,
people
found
this
line
of
code
right,
they
stumbled
over
the
type
or
they
copied
it
from
somebody
else,
or
they
heard
somebody
else
saying.
Block
copy
is
more
efficient
than
a
radar
copy,
or
something
like
that
right.
D
Because
it
seems
like
block
copy
like,
for
all
intents
and
purposes,
this
is
an
unsafe
api
because
it
deals
not
with
the
type
of
the
array
but
with
bytes.
Instead,
it's
going
to
it's
not
constrained
to
a
t
x,
but
it's
going
to
throw
if
the
type
is
not
a
primitive
type,
at
least
looking
at
the
implementation
here.
D
D
A
D
D
A
D
E
A
E
We
could
suggest
both
things
detect
that
the
argument
has
to
count
is
probably
not
the
correct
one
and
say
make
sure
to
the
number
of
bytes
or
use
these
other
alternatives.
We
could
have
that
message
include
both
suggested.
A
D
A
Doing
so,
probably
you
want
to
use
a
radar
copy
instead
right,
which
is
probably
more
helpful
than
flagging
code.
That
actually
does
work,
because
you
voted
five
years
ago
and
tested
it,
and
so
that
seems
a
bit
more
scoped
in
nature
than
effectively
obsoleting
block
copy
right,
because
I
mean,
even
if
you
don't
use
obsolete,
even
if
you
make
it
in
you
know,
opt-in,
analyzer
or
something,
for
example.
People
won't
do
it
right.
A
They
will
not
opt
into
this,
so
you
will
very
get
very
few
usage
of
that
and,
honestly,
if
we
just
add
a
warning
that
is
scoped
enough,
that
we
believe
we
can
have
it
on
by
default.
Poly
would
prefer
that,
because
that
you
basically
avoid
the
bleeding
here,
as
in
you,
avoid
more
people
taking
dependency
on
an
api
that
is
hard
to.
A
A
A
Like
I
said
like
to
me
the
so,
what
is
effectively
suggesting
is
basically,
if
you
flag
the
api,
either
by
making
an
obsolete
or
having
an
analyzer
that
has
opt-in
that
says,
don't
use
buffer
to
block
copy
use.
Something
else
right,
and
I
actually
like
the
suggestions
from
carlos
to
say
we
don't
do
that.
Instead,
we
just
basically
flagging
code.
That
we
know
is
wrong,
meaning
you
know
what
the
analyzer
is
proposally
doing
here
and
then
just
change
the
message
to
say
by
the
way
you
probably
want
to
use
a
radar
copy,
anyways.
C
C
The
analyzer
has
no
value
but
yeah.
I
I
think
that
that
I
don't
think
that
there's
a
problem
with
people
who
call
buffer.blockcopy,
because
it's
in
my
fingers,
when
I
need
to
copy
one
byte
array
into
another,
because
it
was
fastern.net
too
framework.
C
You
know
I'm
old,
the
so
as
long
as
you're
using
it
with
bytes,
it's
fine
and
what
it
was
designed
for,
and
it
used
to
be
the
case
that
array.copy
doing
its
type
switches
would
call
buffer.blockcopy
if
you
were
doing
bytes
so
suggesting
that
someone
change
it
on
depending
on
what
frameworks
they
all
care
about
with
their
code
sample.
That
would
be
a
worse
answer,
but
saying
hey
you're.
This
isn't
bytes.
C
You
probably
meant
array.copy
totally
seems
like
a
fine
suggestion
from
a
fixer
or
multiplying
by
the
runtime
version
of
get
the
value
size
doesn't
like
it
can
propose.
C
Yeah
the
given
that
it's
you
get
less
data
than
you
probably
meant,
as
opposed
to
an
exception.
I
do.
I
now
agree
that
it
makes
sense
to
we
see
that
you
did
from
source
0,
comma
stuff
source.length.
I
don't
think
it
matters
that
it
was
going
to
death
zero
and
that
hey.
This
probably
is
not
what
you
wanted.
A
I
mean
the
only
cases
where
I
can
think
of
this
being
the
case
would
be,
you
know,
a
magic
header
or
something,
but
in
this
case
you
would
have
a
literal
right.
You
would
now
I
wanna
exactly
16
bytes
or
something
I
I
like.
It
seems
weird
to
me
to
use
the
railing
to
make
the
determination
that
you
want
that
particular
subset
of
the.
A
B
E
Also
consider
expanding
the
documentation
for
this
api
in
case
we
are
not
mentioning
a
potential
problem.
E
E
E
So,
depending
on
the
number
of
arguments,
the
stop
string
is
the
overload
of
ask
and
that
we
would
substitute
and
I'm
also
making
sure
to
consider
the
cases
where
the
arguments
are
passed
named,
because
we
need
to
make
sure
the
name
of
the
argument
to
the
correct
one,
because
the
names
could
be
different.
E
A
A
C
At
the
same
time,
and
in
the
event
that
there's
a
triple
overload
group
of
string,
read-only
span
and
read-only
memory,
I
think
it
should
go
to
spam.
Probably
yeah
I
mean
we,
I
I
don't
think,
there's
a
problem
with
being
complete.
At
the
same
time,
I
would
be
surprised
if
the
memory
support
added
a
huge
amount
of
if
it
detected
a
bunch
of
additional
cases.
C
The
vast
majority
of
apis
that
we've
exposed
at
least
are
string
span
rather
than
string
and
memory
or
string
and
span
of
memory
yeah.
The
only
time
that
I
can
really
think
of
when
it
would
pop
up
from
memory
is
if,
if
it
was
a
t
and
it
it
picked
t
being
char,
because
I
agree
that
I
can't
think
of
places
where
we
would
take
a
read-only
memory
of
char
and
expect
that
it's
a
string
except
for
the
like
trim
apis.
C
And
I
feel
like
those
were
instant
extension
methods
over
read
only
span
or
read-only
memory
of
charge.
So
I
don't
think
that
anyone
like
they'd
have
to
call
it
statically
and
then
pass
in
a
substring
for
it
to
apply.
C
C
E
Maybe
we
can
just
take
the
conservative
path
of
just
doing
it
for
fun
right
now
and
if
someone
suggests
or
request
adding
the
memory
once
we
could
expand
this
and
analyze
our
own
picture,
we
can
just
keep
the
note
that
this
could
be.
I
can
collect
cycle
for
the.
D
D
C
Well,
I
mean
it
could
already
be
being
passed
as
s
dot
substring
to
a
method
that
takes
a
read-only
span
of
char
and
has
no
string
overload
and
if
we're
not
already
finding
that
we
should
right.
I
think
there
was
a
separate
issue
from
that.
Wasn't
there
maybe
I'm
wrong.
Maybe
not
I
don't
remember.
If
that's
the
one
I
did
or
not,.
C
C
C
Sounds
like,
or
it
seems,
fine
to
me,
given
my
understanding
of
what
it's
doing.
I
if
we
feel
like
doing
read-only
memory
great
and
if
we
don't
that's
fine.
C
I
agree,
I
can't
think
of
a
place
where
it
would
come
up
unless
it's
in
a
generic
method,
where
char
ends
up
being
the
resolved
type
to
make
it
compile.
C
A
E
Equals
so
the
idea
of
these
analyzers
to
find
places
where
we
are
iterating
through
them
array
and
comparing
elements
in
the
array
and
instead
suggest
using
frequency.
C
E
C
Okay,
I
kind
of
wonder
I
can't
remember
if
I
proposed
this
or,
if
levi
suppose
this
or
someone
else
proposed
this,
but
I'm
not
sure
it's
really
worth
it.
It's
going
to
be
a
pretty
complex
which
should
read
as
expensive
rule.
I
think,
because
the
you
know
for
loops
show
up
everywhere:
we'd
have
to
analyze
at
least
look
at
every
single
one.
C
Some
of
them
from
a
performance
perspective
are
probably
actually
losses,
since
there
is
some
fixed
startup
overhead
to
sequence
equals
in
fact,
I
think
in
our
own
code
there
are
some
places
where
we
explicitly
don't
do
sequence
equals,
because
we
expect
them
to
be
two
or
three
elements
or
something,
and
it
saves
you
at
best.
C
D
Arbitrary
types
and
special
cases
like
float,
half
double
some
of
the
vector
types
etcetera.
It
becomes.
A
potential
change
in
behavior,
which
may
be
undesirable,
might.
C
D
C
E
We
are
iterating
through
the
whole
data,
not
just
a
few
of
them,
so
that
would
be
one
of
the
triggers
for
the
analyzer
to
show
up
the
other.
One
is
what
was
mentioned
in
the
last
comment.
In
the
thread.
E
So
whether
we
do
that
comparison
before
or
not
would
also
be
a
an
another
condition
to
propose
using
sequence,
equal
because
sequence,
sequence
does
the
same
comparison
right
and
now.
E
Is
what
panner
mentioned
that
their
own
some
data
types
could
not
trigger
this.
D
I
think
it'd
be
fine
as
like
a
low
priority,
one
that
can
help
flag
perform
potential
performance
optimizations,
but
as
with
many
performance
optimizations,
I
think
users
need
some
additional
annotations
on
keep
in
mind
that
this
may
break
for
these
types
of
scenarios
and
it
may
regress
performance
for
small
arrays
or
other
things.
I.
C
Mean
to
that
point,
if
we
were
to
do
it,
I
think
it
wouldn't
even
be
info.
It
would
be
like
you
know
this
helpful
thing
you
could
turn
on.
While
you
were
doing
your
development
to
see,
if
there's
anything
interesting
and
then
you
turn
it
back
off
yeah,
because
I
think
that
the
the
the
performance
hit
of
running
this,
which
is
going
to
be
a
very
complex
state
builder,
the
performance
set
of
running
this
is
going
to
be
worse
than
like
it.
C
Like
it'll,
either
not
catch
a
bunch
of
things
and
we're
going
to
keep
special
casing
like
oh
there's,
this
other
kind
of
pattern.
That
kind
of
looks
like
the
thing
that
we
kind
of
wanted
it
to
find,
and
then,
oh
now,
let's
go
exclude
anything
that
has
a
an
equal,
equal
and
oh
exclude
anything.
That's
a
generic
method
because
we
don't
know
if
it's
an
equal
equal
or
if
it's
going
to
end
up
having
equal
equal
match.
C
I
don't
actually
remember
how
equal
equal
works
with
generics,
but
like
I
think
that
we're
going
to
end
up
just
special
casing
it
back
and
forth,
and
we're
going
to
want
it
off
by
default,
and
I
think
we
just
shouldn't
even
do
it.
C
A
C
A
C
C
C
C
C
Any
call
to
enumerable.sequence
equal
where
the
two
arguments
are
both
arrays,
I
see
and
that
it
would
be
hey
if
you
take
the
left
argument
and
do
dot
as
span
first,
then
now
you
get
span
sequence
equal,
which
is
better.
A
C
Or
we
add
a
special
code
path
to
normal
secret
sql
that
just
you
know,
does
a
type
check.
Well
I
mean
we
can
do
the
type
check,
but
then
you're
behind
the
type
check
it.
This
would
be
the.
If
you
did
the
as
spam,
then
you
get
to
even
bypass
that
amount
of
runtime
reflection.
C
As
for
adding
a
member
on
sd
array,
like
you
said
that-
and
I
felt
like
john
kotus
would
murder
me,
but
if
I'm
wrong
then
I'm
sure
we
could
add
it,
and
I
mean.
C
But
I
mean
yeah
if
we
can
add
a
target
number
there
that
does
better
binding,
then
sure
otherwise,
an
analyzer
of
if
you
added
dot
as
span
to
your
to
the
quote,
unquote
instance
being
passed
or
that's
the
target
of
this
method.
Then
hey
look
now
you're
hitting
span
sequence
equals
instead
of
enumerable
sequence,
equals
and
that's.
C
C
Alternatively,
actually,
I
think
we
could
probably
add
a
numerable
dot
sequence
equals
of
t
with
arrays.
And
so
then,
if
you
hit
t
array
comma
t
array,
we
could
forward
that
one
directly
to
span
sequence
equal.
So
that's
a
a
compile
time
decision
and
not
a
runtime
decision.
C
It
opens
up
a
whole
lot
of
floodgates,
so
we've
tried
pretty
hard
to
keep
the
public
apis
for
innumerable
to
be
enumerable,
I
enumerable
and
now,
if
we
start
adding
overloads
that
take
arrays,
we
ordered
overloads
that
take
lists.
We
had
overload.
Let's
take
collections,
we
had,
and
you
know
we
increased
the
surface
area
from
200
overloads
to
something
much
much
more
than
that.
D
It
might
be
better
if,
like
one
of
the
biggest
problems
with
link
today,
is
that
we
do
have
few
overloads,
but
we
also
end
up
with
overhead
from
checks,
because
the
jit
doesn't
specialize
reference
types
and
maybe
that's
something
that
we
could
talk
with
the
jet
team
about
and
investigate
to
see.
If
there's
something
we
could
do
to
improve
that
handling,
so
that
for
maybe
in
an
opt-in
pattern,
you
could
specialize
for
specific
types
where
we
know
that
it's
performance.
A
Okay,
so
I
have
some
notes
here.
I
guess
at
this
point:
should
we
just
mark
it
as
needs
more
work,
because
we
talked
about
a
bunch
of
stuff
that
we
could
be
doing
in
this
in
this
case,
and
if
I
just
mark
it
close,
then
I
think
all
of
this
stuff
will
disappear
from
our
radar.
So.
C
A
C
C
Because
I
think
that
you
know
tanner
with
some
the
thinking
about
the
general
improvements
of
maybe
changing
something
about
how
the
jet
does
generic
methods
with
reference
types
really
is
a
very
different
and
big
concept.
C
My
feeling
is,
no,
I
think
the
consensus
feeling
was
no,
but
adding
an
analyzer
that
suggested
writing
as
span
seems
workable
and
then
steve
seems
to
be
against
adding
specialized
entry
points
on
enumerable,
because
it's
in
the
words
of
yes,
minister,
the
thin
end
of
the
witch.
D
A
Array
is
meant
to
be
very
low
level.
You
know
core
type
so
that
one
wouldn't
be
bad,
but
I
think
everything
this
is
more
high
level,
like
all
the
interfaces
or
collection
types.
I
think
at
that
point
it
would
be
hard
to
argue
that
the
type
check
is
expensive
stuff
right,
but
for
a
race
I
could
see
a
world
where,
like
the
array
is
relatively
small,
so
the
type
check
it's
just
making
it
more
expensive
or
whatever.