►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
C
Hello,
everyone
today
we
are
doing
this
mythical
thing
called
reviewing.
The
backlog
in
api
review
so
should
be
interesting.
We
haven't
really
done
this
in
a
while.
So
I
guess
we
did
it
yesterday.
C
All
right
so,
first
up
because
it's
the
only
actionable
thing
with
the
blocking
tag.
37485
allow
x,
509
chain
callers
to
prevent
retrieval
of
missing
certificates.
C
So
there
are
a
couple
scenarios
where
people
don't
want
the
automatic
download
for
finding
missing
certificates
in
a
certificate
chain
and
windows.
Has
this
as
a
boolean
option,
I
mean
technically
they
have
it
as
a
flag
mac.
Has
it
as
a
boolean
option
and
we
manage
our
destiny
on
linux,
so
we
can
expose
it
as
a
boolean
to
do
less
work.
B
I
mean
there's
not
much
to
discuss
for
a
boolean
property,
but
the
other
thing
that
we
typically
discuss
is
the
polarity
is:
what
made
you
choose
disable
instead
of
you
know,
enable
and
have
it
be
true.
C
Largely
I
went
with
the
because
it's
new
using
the
the
the
falsiness
of
set
this
if
you
want
to
disable
it
so
I
chose
the
polarity
of
if
you
are
looking
at
this
line
of
code,
you're,
probably
changing
it.
So.
C
C
Yeah,
instead
of
fetch,
the
other
one
I
considered
was
retrieval,
but
then
retrieval
felt
a
little
ambiguous
of
its
retrieving
things
out
of
the
store,
so
I
went
with
so
fetch
or
downloading,
or
I
mean
it
doesn't
really
matter.
They're
only
going
to
be
like
six
colors
of
this
in
the
world,
so
but
one
of
them
possibly
castral.
C
C
Yep,
like
you
know,
I
can
I'm
fine
with
being
enable
I'm
the
the
first
one
I
had
was
the
candidate
name
when
prototyping
was
disable
network
retrieval,
but
that's
obviously
overreaching
because
it
doesn't
turn
off
krill
and
ocsp.
So
having
the
word
certificate
in
there
felt
important
and
then
yeah.
As
I
said
for
polarity,
I
chose
disable
as
the
name
to
indicate
that
this,
if
you're,
looking
to
turn
it
off
that
you
have
to
set
this,
it's
it
is
on
by
default
and
then
fetch
or
retrieve
or
download
or
whatever.
C
C
C
B
C
So
the
the
ocsp
and
certificate
revocation
list
are
both
covered
by
revocation
mode.
It
can
be
that's
the
on
or
off
offline,
which
is
local
cache
only
and
online,
which
is
it's
allowed
to
do
network
retrieval
so
that
one
already
had
a
has
a
setting.
It's
only
the
the
chain
walking
that.
C
C
There
are
definitely
scenarios
where
you
would
want
them.
I
guess
they're
not
definitely,
scenarios
where
you
want
them
independently,
but
I
can
imagine
scenarios
where
you're
trying
to
validate
that.
You
already
have
enough
state
for
setting
up
your
ssl
stream
context
and
but
that
you
do
want
the
revocation
to
be
processed,
so
they
they
are
they're
independent
vectors
on
mac.
I
yeah
on
mac
in
like
core
200.
They
were
tied
together
and
but
that
caused
some
problems
where
people
wanted
revocation
to
be
offline,
but
they
were
expecting
the
certificate
retrieval
to
still
work.
C
C
C
D
C
Yeah,
so
I
said
right
before
you
joined
my
original
candidate
had
been
retrieval,
but
since
they
will
still
be
retrieved
from
the
system
stores,
I
thought
that
that
was
an
overreaching
word
I
see
so
download
is,
is
very
specific
and
apt.
E
B
F
F
B
Yeah,
I
think
we
decided
to
punt
on
this
until
we
until
we
actually,
we
you
know,
get
the
data
team
in
here
then.
C
Just
have
to
set
it
up,
it's
ready
for
dedicated
review.
Okay,
yep,
this
one's,
not
ready.
Is
it
tanner,
yeah.
A
Yeah,
basically,
okay,
so
the
proposal
is
to
add
a
new
constant
representing
two
times:
pi,
it's
a
commonly
needed
mathematical
value.
The
original
requester
has
asked
for
the
name
to
be
tau,
which
is
the
at
least
one
of
the
formal
names
that
is
used
for
the
value.
A
I
think
I
think
it's
worth
having
a
constant
for
this,
and
potentially
even
some
of
the
other
constants
that
I
listed
at
the
bottom
of
the
page,
but
or
namely,
because
with
floating
point,
it's
very
easy
to
get
a
to
to
to
perform.
Something
like
you
might
think
that
two
times
pi
represents
exactly
this
value,
but
for
certain
precisions
it
may
not
so
providing
these
well-defined
constants
for
use
is.
D
A
A
It
I'm
I'm
just
trying
to
clarify
that
it.
It
should
either
be
tau
or
two
pi.
The
original
requester
suggested
tau
and
I'm
trying
to
explain
the
difference
between
them.
I
am
personally
fine
with
tau,
but
it
may
not
be
immediately
recognizable
to
everyone.
A
B
Yeah
so
corey,
if
you
take
a
look
in
the
teams
chat,
I
pasted
what
the
what
the
c
header
file
defines
it's
a
lot
of
stuff,
but
not
two
pi.
B
B
A
B
But
I'm
trying
to
understand
that.
So
are
you
saying
that
we
would
define
this
as
a
const
right.
B
But
what
is
so
you're
saying
we
would
in
our
source
code
we
wouldn't
have
const
const
double
tau
equals
two
times
pi.
We
would
have
const
double
tau
equals
six
point,
blah
blah
blah
blah
blah.
C
Because
I
don't
like,
since
you
know,
the
term
was
only
apparently
introduced
in
2001
according
to
wikipedia
I've,
never
heard
it,
but
I'm
old.
So
maybe
young
whippersnappers
in
math
classes
learn
how
now.
A
G
Yeah
my
care
level
is
close
to
0.
I
guess
I
mean
if,
if
tau
is
the
is
the
actual
mathematical
concept
for
that
now,
even
though
it's
recent
I'm
fine
with
that,
I
mean
2.
Pi
is
kind
of
weird
as
in
because
you
really
want
to
write
it
with
the
letter
two,
but
you
can't
because
the
identifiers
can
start
with
two.
You
can't
make
it
a
suffix,
because
then
it
looks
like
it's
a
different
version
of
of
pi.
So
it's
just
unfortunate
in
the
editorial.
G
B
A
Yes,
I
believe
so
some
of
them
need
to
have
more
thought
on
the
names
because,
for
example,
there's
one
for
pi,
divided
by
two
and
also
two
divided
by
pi,
c,
n
c,
plus
plus
just
calls
it
two
underscore
pi,
for
example,
which
would
conflict
here
and
also
isn't
clear
that
it's
two
divided
by
pi.
So
just
some
more
thought
needs
to
be
put
into
it
before
the
proposal
goes
up.
C
A
Right,
the
proposal
here
is
just
we
add,
pow
equivalence
for
integer
overloads,
there's
the
only
other
type
we
actually
support,
integral
pow
on
is
big
integer
right
now
and
for
many
inputs
this
will
actually
end
up
overflowing,
and
so
the
decision
on
whether
to
overflow
or
not,
would
need
to
be
decided.
A
A
A
Double
introduce
so
double
precision
floating
point
for
long
inputs
will
lose
precision
on
values
that
are
greater
than
2
to
the
power
of
54.
53..
Sorry,.
B
A
A
A
It
would
overflow
if
it
went
over
2
to
the
power
of
63
or
2
to
the
power
of
64.,
and
yes
levi,
you
made
a
good
point.
This
would
be
a
breaking
change
for
the
same
reason
that
adding
float
would
have
been
breaking.
C
A
C
B
A
B
B
A
Float
has
to
do
a
lot
of
extra
consideration
because
it
has
to
worry
about
fractional
inputs.
A
Right,
but
not
so
expensive
as
compared
to
the
number
of
floating
point
how's
one
of
the
slowest
math
operations
sure.
A
If
you're
trying
to
do
it
with
float,
if
you're
trying
to
do
it
as
float
within
in
inputs,
then
yes.
B
Right,
no,
I
was
just
I
was
just
purely
about
the
math.how
double
over
and
I'm
trying
to
understand
like
from
a
value
perspective
like
what
this
brings
to
the
table.
It's
bringing
to
the
table
potential
performance
on
some
inputs
and
avoiding
a
cast
on
the
result.
C
Well,
but
I
think
that
inst.max
value
to
inch.max
value
after
being
converted
to
double
produces
positive
infinity
from
pow,
but
that's
it.
But
that's
the
case
where
it's
overflowing.
It's.
B
C
Overflow,
the
results
that
it
is
right
there
is
there's
possibly
a
loss,
no
because
it's
53
bits
of
state,
so
yeah
so
int
going
to
long
could
have
some
loss
of
precision
after
53
bits,
but
the
there's
our
int
going
along
could
be
more
accurate
than
than
going
the
double
route
to
long.
C
If
the
whatever
the
word
for
the,
how
high
the
highest
bid
is,
exceeds
53
bits
right
but
as
written
the
proposal
was
returning
right
right,
which
means
it
definitely
cuts
off
very,
very
early.
G
B
All
right,
so
this
one
there
was
a
bunch
of
stuff
discussed,
but
if
you
scroll
down
jeremy,
there's
a
little
edit
for
me
at
the
bottom
of
the
summary
yeah.
So
basically
the
proposal
ends
up
being.
B
The
task
class
has
from
result
from
cancelled
from
exception
methods
and
also
a
completed
task
property,
and
the
request
is
to
add
those
to
value
tasks
as
well,
they're,
all
one-liners,
and
so
basically
the
value
here
is
for
most
of
these.
It's
just
saving
someone
from
having
to
type
out
sort
of
the
longer
expression
figured
out
and
for
the
completed
task
property.
It's
knowing
that
default
of
value
task
is
an
already
completed
value
task.
A
B
Yeah,
we
basically
use
one
l
for
everything,
except
for
cancellation,
where
we
use
two
that
holds
pretty
much
everything:
we've
added
since
dot
net
framework
2.0.
Before
that
there
was
a
consistency.
C
F
D
D
B
Yeah
right,
I
was
just
showing
kind
of
the
equivalent
semantics,
but
the
the
from
result
is
just
going
to
be
a
new
value
task
value
right.
Okay,
just.
B
The
other
ones,
the
from
from
exception
and
from
those
both
go
through
task,
because
value
task
is
only
able
to
represent
a
value
or
a
task
or
a
value
or
an
object
of
some
kind,
and
so
it
can't
store
an
exception
or
cancellation
information.
B
No,
we
can,
we
can
do
it
on
both
unix
and
windows.
The
this
one,
the
the
primary
benefit
here
is
wait.
What
is
this?
What
is
the
proposal?
Get
it
yeah.
B
This
is
an
atom
atomically,
effectively
getting
both
the
left
and
the
top.
At
the
same
time,
right
now
we
have
cursor
dot
or
console.cursorleft
and
console.cursortop,
or
something
like
that
and
in
the
extreme
case
each
of
those
is
extremely
expensive
and
in
fact,
prior
to
net
core
30
or
31.
I
forget
3o.
I
think
they
were
both
very
expensive,
because
in
order
to
get
that
on
unix,
we
basically
have
to
both
read
and
write
from
standard
and
standard
out.
B
We
basically
send
a
particular
ansi
escape
sequence
to
the
terminal
asking
for
the
position
and
then
the
terminal
sends
us
back
via
standard
out
the
position,
and
so
every
time
we
asked
every
time
you
called
console.cursorleft.
We
would
do
that
protocol
and
every
time
you
called
console.cursor
top.
We
do
the
protocol,
but
that
protocol
gives
you
back
both.
B
So
you
know
we
basically
were
throwing
away
information
and
duplicating
the
work
in
dot
net
core
30
time
to
zane
added
some
caching
here
such
that
we
basically
try
and
remember
and
kind
of
update
the
position
whenever
we
can
such
that
we
don't
have
to
go
back
to
the
terminal
as
frequently
so.
The
benefit
of
this
there's
still
benefit,
but
the
benefit
was
significantly
reduced
as
of.net
core
30.
C
But
most
of
our
we
have
locking
inside
console
right.
Yes,
so
technically,
there's
a
I
mean
if
you're
about
to
do
anything
with
the
data,
you
got
there's
a
race
condition
anyway,
but
there
is
a
race
condition
where
you
could
read
left.
Somebody
else
can
now
have
done
a
right
line.
Then
you
read
top
and
now
your
left
and
your
top
are
are
torn
sure.
That's
the
case
on
windows
as
well
yeah.
So
if
we
already
have
the
data
and
it
already
works,
then
adding
atomic
seems
good
to
me.
B
Anyone
else
that
this
seems
to
find
the
only
the
only
sorry.
The
only
thing
I
can
think
of
is
like
are:
are
we
still
adding
apis
that
out
multiple
parameters
at
once,
or
are
we
preferably
using
the
the
deconstruction
syntax
that
c
sharp
has
going
forward?
Like
I
don't
know
what
the
what
our
recommendation
is
going
forward.
You
mean
returning
a
tuple
yeah,
basically.
A
So
carol
is,
I
is
working
on
some
various
changes
in
legit
to
support
multi-reg
multi-register
returns
at
the
in
both
code,
gen
and
hardware
level
for
instructions
that
do
that
and,
as
far
as
I
know,
that's
going
to
not
work
well
without,
and
it
will
only
work
well
with
strucks
and
tuples.
B
C
It's
a
good
point
right,
I
mean
our
our
guidance
on
tuples
is
essentially
try
anything
else
first
and
then,
if
you
use
them,
you
need
to
be
absolutely
sure
that
your
api
will
never
evolve.
I
think
that
that
could
hold
for
this
case.
B
B
B
This
isn't
a
perf
thing,
it's
just
like
are
we
we?
We
have
all
of
these
new
language
features
that
are
supposed
to
make
the
code
look
better
supposed
to
be
more
modern,
are
with
api
designs
like
this.
Are
we
kind
of
holding
things
back
that
that's?
It's
such
a
minor
concern,
but
it's
something
that's
been
nagging
at
me
for
a
while
yeah
to.
B
C
And
this
strikes
me
as
a
very
similar
case.
We
also
did
it
for
range.getoffset
and
length
because,
with
a
name
like
get
offset
and
length,
it
literally
could
never
return
anything
other
than
an
offset
in
the
length
right
yeah.
I
don't
imagine
we're
going.
A
Well,
and
for
the
hardware
intrinsics,
those
are
likely
going
to
be
proposed
using
tuples
as
well.
C
Right
but
the
the
hardware
instruction
could
literally
not
change
right,
so
it's
it's
going
to
be
a
it
would
hit
the
case
of.
I
don't
need
to
do
this.
The
part
of
the
reason
we
have
the
prefer
having
a
named
type
to
it
is
so
that
you
can
add
methods
and
and
such
in
the
future,
but
in
the
intrinsics.
It's
you
put
this
data
in
and
this
data
comes
out
and
that
that
is
what
it
is.
The
processor
determined
it
so.
G
Yeah,
I
also
feel
like
it
doesn't
have
to
be
perfect,
but
it
just
has
to
be
fairly
unlikely
right.
I
mean
if,
if
we
ever
have
a
3d
position,
we
can
just
introduce
a
new
method.
Name
like
it's
not
a
big
deal.
It
would
not
be
great
if
it's
a
very
likely
change,
but
like
it's.
It's
not
like
the
world
is
falling
down
when
you
have
to
support
three
output,
values
of
the
sun.
F
C
G
D
It
doesn't
take
a
tuple
because.
C
G
C
A
G
Yeah,
I
think
what
levi
just
pasted
in
chat,
I
think,
is
the
important
thing,
because,
as
soon
as
you
return,
tuples
c
sharp,
really
upsells
you
on
decomposition
immediately
into
local
variables,
so
you
really
don't
hold
on
to
those
tuples
in
many
cases.
So
I
would
say
that
to
me
it's
fine
to
say,
get
crosstalk
position
returns
the
tuple
and,
while
said
question
position
does
not
accept
one.
I
think
that's
still
fine.
C
A
Another
argument
for
using
a
tuple-
I
know
steven
said
this
is
never
going
to
be
performance,
but
if
you
guys
pay
attention
to
twitter
at
all,
there's
people
tweeting
about
ascii,
renderers
and
stuff
3d
ascii
renderers
that
they
do
in
the
console
and
that's
a
performance,
oriented
scenario
where
a
tuple
would
be
beneficial.
G
G
B
A
G
E
G
Yeah,
like
I,
don't
know
exactly
what
they
do,
but
I
mean
like
if
you
look
at
you
know:
n
cursors,
for
example,
you
can
write
much
faster
screen
updates
than
you
can
with
the
normal
console
apis
directly,
and
it
usually
has
to
do
with
they.
Don't
they
they
buffer
more
stuff,
they
selectively
update
parts
of
the
screen.
They
don't
update.
All
of
it
right,
like
that's.
G
C
So
since
someone
asked
what
guidance
we
decided
on
and
wrote
down,
it's
do
prefer
descriptive
types
over
tuples
do
prefer
name
tuples
over
unnamed
tuples
do
name
using
pascal
case.
Do
not
use
tuples
with
more
than
three
fields.
Do
not
use
tuples
as
method
parameters
and
do
not
define
extension
methods
over
tuples.
C
We
could-
and
it's
really
that
would
really
be
if
we
thought
that
we,
if
there's
ever
a
reason
to
to
pass
this,
as
you
know,
an
atomic
property
anywhere
that
or
that
you
would
want
this
as
a
as
the
tuple
being
passed
in
somewhere,
because
having
the
named,
I
want
a
console.
Cursor
position
is
better
than
I
want
a
tuple
of
intent.
C
D
C
C
We
we
did
it
with
zip,
because
it
it
made
very
strong
sense
for
what
it
had
for
zip
of
you
give
it
two
things,
and
it
returns
a
two
tuple
and
or
an
enumerable
of
two
tuples,
and
we
did
it
for
get
offset
in
length
which
returns
the
named
tuple
offset
comma
length.
D
C
Yeah,
as
a
very
wise
annotator
said,
it
makes
a
lot
more
sense
in
internal
code
than
it
does
in
public
code
for
sure.
G
C
Yep,
theoretically,
it's
books
in
warehouse
on
the
23rd
o'reilly
has
a
preview
copy
of
it
as
ebook
already.
G
D
C
D
C
B
C
A
The
the
original
proposal
is
arguing
that
we
hide
these
not
remove
them,
hide
them
because
all
of
them
forward
to
volatile
methods
and
the
methods
on
thread
do
not
expose
all
equivalents
that
are
on
volatile,
so
it's
basically
an
incomplete
subset
and
any
new
methods
we'd
be
adding
to
volatile,
not
thread
anyways.
So
we
should
point
people
towards
using
the
new
methods,
I'm
not
sure
whether
or
not
that's
good
or
not.
I'm
just
explaining
the
original
proposal.
C
G
G
But
you
only,
but
I
think
the
issue
there
is
like
it
depends
on
how
we
want
to
do
this
right
if
we
actually
want
to
tell
people
like
use
the
other
apis,
we
have
a
code
fixer
for
that.
I
think
editor.
Browseable
is
probably
the
right
thing
if
we
don't
do
it
in
generator.
So
if
we
don't
do
a
fixer
for
that,
then
I
think
it's
more
of
a
problem.
G
A
C
The
api
cat
says
we
added
it
in
four
five
yeah.
That
makes
sense
that.
C
C
I
think
that
it
would
be
weird,
especially
for
multi-targeting,
because
if
you're
net
standard
2o
and
net
5,
then
you're
gonna
get
the
weird
state
that
I
think
emo's
still
arguing
with
visual
studio
about
of
intellisense
gives
you
a
squiggle
that
says
you're
calling
a
method
that
doesn't
always
exist,
even
though
it
does
always
exist.
It's
just
editor
browsable,
never.
G
Let
me
check
this
because
I
don't
think
we
ever
check,
but
that
gives
us
squiggle.
I
think
that
was
this,
so
it
basically
gives
you
an
icon,
and
then
you
have
the
member
list
open,
but
I'm
not
sure
it
actually
gives
you
this
critical.
If
it
gives
you
a
squiggle,
then
I
think
that's
a
big
problem.
If
it
doesn't
give
you
a
squiggle,
then
it's
still
a
problem,
but
I
think
much
less.
C
B
Yeah,
that's
my
understanding
as
well,
but
for
if,
if
we
wanted
to
cover
this
in
the
obsolescence
plan,
like
generally,
we
don't
eb,
never
obsolete
apis
unless
there's
a
really
good
reason
to
so,
I
mean
possible
counter
argument,
but
whatever
yeah,
but
in
this
case.
C
G
Well,
the
argument
for
the
obsoletion
is
basically
what
tanner
said
right
like
we
will
only
have
like.
We
only
exposed
a
subset
of
these,
it's
not
just
they
moved.
You
have
an
incomplete
set,
so
you
will
probably
draw
wrong
conclusions.
If
you
just
look
at
the
threading
apis,
you
probably
won't
look
at
volatile
right,
so
you
want
to
point
people
towards
the
volatile
api
for
that
and
that's
kind
of
margarine
for
hiding
it,
because
it
just
reduces
concept
count
in
thread,
which
already
has
too
many
things.
C
Okay,
if
you
think
that
you
know
as
as
the
pm,
if
you
think
that
that's
worth
the
user
frustration
of
getting
an
obsolete,
especially
if
we've
written
the
fixer
and
because
it's
you'll
never
get
the
fix
wrong
like
this
is
a
perfect
fixer.
I
guess
sorry,
it
will
fail
in
reflection.
G
G
B
Yeah
I
mean,
if
there's
a
I
just
want
to
make
sure
we're
consistent,
because
we
in
general,
like
our
stance
on
editor
browser,
will
never
has
been
one
of
at
a
very
long
arm's
length,
and
then
this
one
came
along
we're,
like
oh
sure,
so
I
just
want
to
make
sure
that
we
are
consistent
in
what
we're
doing
and
if
we
have
a
policy
of
yeah,
we'll
add
it.
B
If
it's
something
else,
we'll
add
it,
we
won't
obsolete,
it
we'll
add
a
fixer
and
like
that's
the
checklist,
then
fine,
but
we
should
know
what
that
checklist
is
and
apply.
It
consistently.
C
Okay,
because
if
we
yeah
so
you
know
just
thinking
through
the
implementation
of
of
a
fixer,
if
we
mark
it
obsolete
and
we
give
it
a
custom
diagnostic,
then
it
can.
Then
the
fixer
can
latch
on
to
that
and
know
what
to
do
without
needing
an
independent
analyzer,
but
that'll
only
work
if
they're,
targeting
that
five.
If
we
write
the
because
that's
the
only
place
it
would
be
obsolete,
if
we
write
it
as
just
a
general
analyzer,
then
it
could
be
opted
in
earlier.
So.
C
You
are
currently
half
the
half
the
faces
stream,
so.
G
Isn't
that
nice?
So
everybody
can
see
my
confused
face,
probably
so
that
I
think
the
I
think
the
right
approach
here
is,
if
I
so
I
wouldn't
obsolete
the
apis
unless
we
have
a
fixer,
because
it's
there's
really
nothing
wrong
with
the
apis.
It's
just
that.
G
It's
not
great
to
have
these
apis
floating
around
because
you
made
because
it's
an
incomplete
subset
right.
So
if
you
have
a
fixer,
I
think
obsoleting
is
fine
because
immediately
control
dot
it
and
just
replace
all,
and
then
you
call
it
a
day
and
then
once
that's
done,
that's
great,
but
then
you
start
just
following
that
in
intellisense
we
promote
these
apis
and
they're,
unfortunately,
not
just
clean
overloads.
They
have
all
different
names,
so
there
are
at
least
four
or
five
different
names.
G
So
that's
why
I
think
hiding
it
makes
sense.
But
again
I
wouldn't
hide
it
without
the
other
work
items
either.
So
I
will
probably
do
all
three.
G
B
This
came
up
the
other
day
too,
when
we
talked
about
obsoleting
the
some
of
the
cast
stuff,
one
one
of
the
pieces
of
feedback
we
got,
there
was
make
sure
the
fixture's
in
at
the
same
time,.
D
B
Consistent
yeah,
as
long
as
everyone's
yeah.
B
B
Yeah
because
he
and
we
do
need
to
have
a
longer
conversation
on
obsolescence
in
general,
but
kind
of
the
way
that
I
see
it
is
like
apis
no
longer
exist
as
first
class
participants
within
the
ecosystem
and
code
that
needs
to
be
able
to
adapt
and
grow
should
move
off
of
them.
That's
kind
of
how
I
see
obsolescence
as
a
concept.
G
G
C
G
C
C
C
Right
so
the
the
one
thing
that
we
think
that
we
know
for
guidance
for
dimms
is
to
never
do
this,
never
ever
provide
a
default
method
or
implementation
of
a
base,
interface.
Member,
because
that's
when
the
diamonds
start
appearing,
if
you
only
provide
default
implementations
for
your
own
members,
then
then
you're
in
a
sane
state.
C
Until
we
find
all
the
ways
that
that
breaks
too,
so
why
does
it
break
for
defining
it
for
the
base,
in
this
case
it
shouldn't,
because
very
few
people
would
ever
have
another
interface
that
said
that
they
needed
I
enumerable,
but
it's
once
if
I
enumerable
of
t
extends
I
enumerable
and
eye
potato
extends
I
enumerable
and
they
both
define
the
dim.
Then,
when
you
get
to
a
thing
that
is
innumerable
of
tea
and
diet
potato,
it
says,
there's
two
two
methods:
you
need
to
pick
one.
B
So
the
the
general
idea
behind
this
is,
if
I'm
just
writing
a
one-off
ienumerable,
I
need
to
implement
five
or
six
or
seven
different
members,
but
the
majority
of
them
are
literally
boilerplate
and
with
this
proposal
I
only
implement
the
two
methods
that
actually
matter
to
my
implementation.
B
If
we
were
using
base
classes
like
we
could
literally
have
an
enumerate,
an
innumerable
of
t
base
class
that
just
has
all
of
that
boilerplate
there.
But
the
problem
with
that
is,
I
can't
have
a
struct
innumerable
anymore
and
subclass
that
base
class.
C
If
we
were,
if,
if
we're
going
to
try
introdu
introducing
dems
anywhere,
I
would
think
that
five
would
be
better
than
six,
assuming
that
we're
sticking
with
even
numbers
or
lts
and
odd
numbers
or
not,
because
it
gives
more
people
a
chance
to
yell
and
scream
and
have
us
rip
it
back
out
before
sex.
So
people
who
only
do
lts
to
lts
hops,
never
get
broken.
C
Like
if
we
want
to
say
that
these
are
special
and
that
really
no
one
cares
about
the
non-generic
ionumerable
anymore
and
that
it's
just
kind
of
dead
weight
and
probably
there's
never
going
to
be
another
thing
that
does
this
because
everybody's
ignorable
of
t
then
or
is
directly
implementing
I
enumerable
for
legacy
reasons.
Then
maybe
this
is
an
okay
place
to
start,
but
this
does
mean
that
the
I
mean
that
is
only
available
if
you're
on
five.
C
So
if
you're
multi-targeting,
you
don't
get
this
and
we
can't
send
it
backwards
because
framework
doesn't
support
temps.
C
A
C
C
This
is
you
know,
with
resharper
or
code
snippets
or
anything,
it's
the
you.
You
start
the
oh,
I'm
I
innumerable
and
it's
like.
Okay,
I
wrote
the
three
forwards
for
you.
What
else
right
so
that
you
you're
still,
essentially
only
I
guess.
If
you're
I
enumerable,
let's,
I
wrote
the
one
forward
for
you.
A
C
It
is,
but
I
think
that
that
when
we
were
first
talking
about
dems
a
couple
years
ago,
this
is
that
emo
had
a
place
where
this
was
likely
to
show
up
with
a
diamond.
I
feel
that
it
was
exactly
I
enumerable
of
tea
and
some
other
type.
That
was
I
enumerable
and
maybe
the
answer
is
we
say
that
we're
only
ever
going
to
allow
it
on
the
generic
variant
of
the
original
interface
and
that
we'll
never
ever
use
dims
anywhere
else
or
definitely
we'll
never
use
it
for
providing
a
default
for
innumerable.numerator.
G
F
G
G
These
ones
here
are
somewhat
so.
I
think
the
reason
why
I
think
this
is
safe
here
for
enumerable
to
enumerable
of
tea
is
because
you're
not
very
likely
to
have
a
shared
diamond,
because,
basically,
whoever,
like
it's
very
unlikely
to
have
an
interface
that
derives
some
interface
that
only
extends
iron
new
mobile
and
then
depending
on
some
other
interface.
That
only
derives
from
my
animal
of
t.
G
C
G
No,
I
think
what
then
I
said:
that's
actually
the
real
reason
why
this
is
safe
is
because
this
doesn't
add
any
new
methods.
This
is
why
this
works.
The
problem
of
the
read-only
interfaces
is
that
we
add
a
net
new
method
that
nobody
implements
and
we
introduced
the
dim
at
a
derived
state
in
the
hierarchy
and
that's
not
what
happens
here
like
everybody
as
senators
that
everybody
who
implements
influences
today
already
had
to
provide
implementation
for
all
of
them,
and
that's
why
these
dims
never
get
triggered
right.
C
C
Runtime
breaking
changes.
Yes,
what
would
that
change
be
so
based
on
queryable
having
been
stated
as
something
that
is
explicitly
extending?
I
enumerable
if,
if
iqueryable
also
provided
a
default
for
git
enumerator
and
it
did
in
the
next
release,
then
anything
that
was
I
queryable
and
I
enumerable
of
t
would
end
up
with
now
have
two
different
implementations:
they're
identical
implementations,
but
the
runtime
isn't
looking
at
what
the
method
body
is.
C
It
just
looks
at
the
fact
that
two
things
are
occupying
the
same
slot,
and
so
then
it
would
say-
or
anybody
who
had
that
at
five
would
be
working
fine
and
then,
if
we
added
the
iqueryable
in
six,
then
you
would
explode
at
runtime
with.
There
are
too
many
implementations
for
this
interface
member.
B
C
C
Any
other
interface
that
extends
I
enumerable,
providing
a
default
implementation
for
innumerable.getnumerator.
B
Sure
so
I
I
can't
imagine
we
would
ever
change
iqueryable,
but
maybe
things
like
I
list
eye
collection
and
so
on
would
be
interesting.
C
Well
but
they're,
just
I
guess.
Yes,
it's
so
the
base
I
list,
so
the
non-generic
eye
list
would
be
enumerable
and
but
we
would
have
no
implementation
that
we
could
give
on
that
one.
But
it's
I
list
of,
and
then
I
list
of
t
would
pull
it
from
my
innumerable.
But
I
think
it'll
also
pull
it
from
my
list
and
I
don't
know
if
it
unifies
in
that
aspect.
A
Maybe
we
could
say
this
is
a
tentative
yes,
based
on
based
on
an
initial
investigation
on
how
it
impacts
the
libraries
and
runtime
itself
once
done
and
feedback
given
to
us
based
on
customers
in
the
next
preview,
and
we
make
sure
to
explicitly
call
out.
We've
made
this
change
in
the
blog
post.
C
D
B
C
C
D
B
We
should
test
it
to
me.
This
is
like
we
it's
one
of
those
cases
where
we'd
like
to
do
it,
but
it's
potentially
hugely
breaking,
even
though
we
can't
prove
that
to
ourselves
and
undoing
it
we
know
would
be
hugely
breaking
and
the
benefit
is
saving
someone
who
implements
this
type
from
writing.
Three
one-liners.
B
It's
nice.
I
just
don't
know
that
it's
worth
it
so
does,
is
the
implication
there
that
we
would
never
do
dims
ever
on
any
interface
in
the
runtime
or
the
libraries.
No,
but
this
is,
if
you
had
to
pick
if
someone
said
what
is
the
most
popular
interface
in
olive.net,
this
would
be
the
one
you'd
pick
right
and
that's
that's
why?
Because
it's
the
most
popular
that's
why
there
is
an
argument
to
be
made
about
like?
Can
we
make
it
easier
to
consume.
C
It's
it's
the
riskiest
place
to
to
start
playing
with
the
concept
like
if
there
was
another
place
that
was
a
good
candidate
for
dems,
that's
sort
of
off
in
the
weeds,
that's
a
a
better
place
to
get
feedback
of
hey!
We
dims
existed.
We
put
some
dims
in
the
framework,
hey
you,
you
may
have
defined
dims
in
your
own
project.
You
may
have
already
reached
several
levels
up
and
implemented
this
and
now
you've,
given
yourself
in
your
own
library
as
a
diamond
and
then
people
complain
and
we
go
wow
yep.
A
C
B
I
think
this
one
also
this
one
also
highlights
some
there's
gray
areas
like
I
agree
with
corey.
I
don't
think
dispose
should
be,
have
a
default
implementation
right.
Obviously
levi
does-
or
he
wouldn't
have
put
it
here,
but
you
know
they.
We
need
to
be
very
careful
with
what
we
choose
to
provide
in
default.
Implementations
for
yeah.
B
I
get
it
like
current,
like
that's
a
no-brainer
in
terms
of
what
you
would
want
reset
is
mostly
a
no-brainer,
but
you
know.
Maybe
someone
would
want
to
try
that
behavior
for
it,
even
though
we
don't
recommend
it
but
dispose
like.
C
C
The
enumerators
implement
like
if
the
enumerator
is
implemented
as
a
private
type,
where
it's
either
de
facto
or
implicitly,
sealed
then
sure.
But
if
it's
a
public
eye
disposable,
it
should
be
using
the
disposed
pattern
and.
B
E
B
Yeah
yeah
yeah.
I
because
that
implementation
is
given
by
the
compiler.
I
don't
think
this
would
affect
it,
but
it's
something
we
would
need
to.
No,
I'm
just
pointing
out
that
a
large
number
of
custom
of
innumerable
implementations
have
disposed
logic.
B
Oh
yeah,
yeah,
yeah
yeah,
I
didn't
I
didn't
mean
to
imply
that
they
don't
it's
just
when
I
investigated
how
we
used
it
within
the
run
time
like
when,
when
I
actually
say
like
public
struck,
my
struct
colon,
I
enumerable
of
t
or
I
numerator,
of
t
like
most
of
the
disposed
methods,
either
no
op
or
wrap
methods
which
know
up
sure.
Most
of
those.
B
Yeah
of
which
makes
sense,
given
that
it's
an
enumerator
right,
okay,
so
what
we
can
do,
then,
is
if,
if
we're
not
feeling
good
about
this,
let's
just
table
this,
then
because
it
sounds,
it
sounds
like
we
also
didn't
say.
No,
we
just
said
we
need
more
information,
and
maybe
in
some
in
the
future
we
can
identify
an
interface
which
it
would
make
sense
to
run
that
experiment
on.
C
C
B
B
G
So
let
me
let
me
phrase
it
slightly
differently.
So
to
me,
my
problem
is
that
I
enumerable
is
not
the
kind
of
type
that
many
people
implement
manually
right
so,
like
the
the
value
of
these
dims
seems
somewhat
lowish,
because
it's
not
going
to
be
used
by
a
lot
of
people
and
to
me
that
means
like
we
have
to
be
very
sure
that
the
dims
will
work
right.
So
it's
basically
somewhat
at
this
point
a
high-risk
feature
for
what
seems
to
be
very
low
gain.
G
A
A
G
G
So
that
one
I
would
agree
with,
but
to
me
that's
more
like
how
do
we
get
more
confidence
with
dims,
which
I
think
is
a
work
item
we
need
to
work
on,
but
I
think,
if
you
would
ask
me,
is
this
a
feature
that
I
would
push
for?
I
would
say:
no,
if
the
feature
is
super
safe
and
we
have
spare
cycles
sure
I
wouldn't
be
opposed
to
that,
but
like
right
now
it
seems
to
trade
off
this
weird,
like
high
risk,
low
gain
kind
of
thing.
G
G
E
B
C
But
all
it's
saving
on
those
types
is
one
one
liner
on
the
enumerable,
which
returns
the
struct
based
iterator
and
two
no
in
one
one
liner
on
the
enumerator,
because
current
and
yes,
it's
disposed.
A
C
D
For
my
education,
real
quick
like
if
I
had
a
framework
like
say,
I
was
a
company
who
made
this
framework
and
I'm
like.
I
want
to
jump
on
the
the
dim
train,
and
so
I
implemented
these
dimms
myself.
Like
I
made
like
say,
my
framework
was
called
eric's
framework,
so
it's
like
I
eric
I
innumerable
and
I
eric
innumerable
of
t
and
then
I
went
and
put
the
dims
in
there
and
then
implemented
a
bunch
of
types
that
that
used
my
interfaces
that
implements
the
dimms.
D
C
B
C
D
C
Right
it's
when
we
make
if
we
for
some
reason,
didn't
do
it
on
ionumerable,
but
we
did
it
on
I
list
and-
and
you
had
done,
I
eric's
innumerable
and
I
list
of
t
and
then
now
you
would
get
it
from
eric's.
Innumerable
and
list
of
t.
C
D
C
B
Yeah,
but
I
I
think
none
of
this,
though,
changes
the
fact
that
I
think
emo,
you
had
said
that
this
is
a
fairly
low
reward.
Api
change,
even
if,
even
if
the
risk
is
unknown,
correct.
G
It
I
mean,
like
that's
my
impression
I
mean
you
can
correct
me
but,
like
my
impression,
is
in
all
the
places
where
you
would
use
this
manually,
there's
so
much
other
work.
You
have
to
do
that.
This
doesn't
really
make
your
job
much
easier
and
the
cases
where
you
don't
have
to
do
the
other
stuff.
You
would
not
implement
interfaces
right.
So
that
seems
why
I
don't
think
it
will
make
that
scenario
substantially
easier.
Even
the
180
places
you
mentioned.
B
G
B
C
If
we
fail
during
that,
then
we
know
it's
too
scary
and
we
should
never
talk
about
it
again.
Failing
means
something
succeeding,
doesn't
necessarily
right,
because
I
I
do
think
that
that
we
have
room
for
new
interfaces
that
we're
adding
in
the
future.
C
C
The
the
one
thing,
because,
while
doing
the
book
you
know
we
had
talked
about
dimms,
and
so
I
have
in
there
an
annotation
that
the
only
thing
that
we
think
we've
learned
is
do
not
use
dimms
to
provide
an
implementation
for
a
base
member,
because
that
brings
the
diamond
problem
it
lets
it
exist.
C
It
doesn't
force
it
onto
somebody,
but
it
if
you
never
do
a
base
implementation,
then
you
never
can
create
a
diamond
if
you're
only
doing
local,
I'm
for
I'm
sending
method,
sending
members
sideways
or
I'm
simplifying
a
base.
Member
call
at
this
point,
because
I
have
enough
context
of
oh
I'll-
read
this
additional
property
and
pass
that
as
the
as
the
member
is
the
parameter.
C
B
Sure
so
so,
jeremy,
something
near
and
dear
to
your
heart,
like
I
crypto,
transform,
for
instance
it
it's
an
interface
and
it
has
two
apis
right,
two
methods
on
it
on
the
interface
that
take
byte
arrays.
Would
it
make
sense
to
if
we
ever
wanted
to
have
a
span
overload
on
those
add
those
to
the
method
or
to
the
interface
as
a
default
interface
method
that
really
just
turns
around
and
forwards
to
the
byte
or
rate
consuming
methods.
C
I
mean
that
would
be
very
like
it
would.
It
would
solve
the
problem,
but
in
that
case
it's
the
same
problem
we
had
with
span
in
general
of
we
introduced
something
more
simple
or
with
something
more
base
than
array,
and
so
you
now
call
what
looks
like
it's
the
better
variant
and,
it's
actually
worse
sure.
C
Okay,
someone
could
specialize
the
interface
and
override
that
and
get
a
better
behavior,
but
if
we
wanted
to
do
it
for
for
something
like
span,
I
think
we
would
go
back
to
all
the
places
we've
added
new,
virtuals
and
we'd
say
this
interface
provides
you
a
default
member,
but
good
god.
You
need
to
implement
it
because
we
have
a
very
bad
base
implementation.
C
A
C
C
B
G
G
D
B
Internally,
I
just
need
more
feedback
on
the
proposal
that
I
sent
around
before
we
can
bring
it
to
this
discussion.
G
B
B
C
The
the
problem
is,
I
I
feel
that
the
code
that
I
always
want
to
write
is
you
know,
I'm
looking
for
an
I
enumerable
just
because
that's
the
most
recent
thing
we've
talked
about,
I'm
looking
for
an
ion
numerable
and
I'm
walking
a
bunch
of
candidate
types
is
thing
that
I
care
about
strongly
test
thing
that
I'm
looking
at
in
a
for
loop
and
and
it's
like
false
and
then
you're
like.
Why
didn't
it
find
anything
and
you're
like
gah
cause?
I
need
to
flip
those
parameters
around
so
I
mean
yeah.
C
D
C
Yeah
so
yeah,
given
that
he
used
this,
I
I
think
that
the
static
was
the
mistake
that
he
just
copied
or
bad
copy
pasta
from
type
extensions.
C
D
C
C
So
I
mean
I
definitely
agree
that
what
we
have
is
assignable
from
is
is
wrong.
I
don't
know,
if
is,
if
type
is
one
of
the
types
that
john
cares
about
not
having
members
on,
but
I
think
he
doesn't
actually
care
as
long
as
it's
not
virtual
yeah.
That.
B
C
Impression
as
well,
and
so
if
we're
just
adding
an
instance,
is
assignable
to
that
inverts,
the
relationship
and
calls
is
assignable
from
then
he'll,
probably
be
okay
with
that.
D
C
Of
t
yeah
list
of
t
that's
because
instance,
methods
on
generic
types,
get
copied
to
new
method
bodies.
A
C
C
B
E
C
Yeah,
it's
for,
if
you're
writing
any
sort
of
custom,
plug-in
loader
and
you're
looking
for
have.
I
found
the
right
candidate
type
and
yes,
it's
you
write
it.
You
get
it
wrong.
You
go
back.
You
scratch
your
head.
You
figure
out
that
you
need
to
flop
the
parameter
order
around,
and
so
it's
not
a
hugely
mysterious
problem.
It's
just
frustrating!
C
B
Sorry,
I
was
muted,
no,
that's.
Basically
it.
D
C
A
You're
going
to
go
have
to
go
back
to
dot
net
1.1,
to
figure
this
out,
yeah,
okay,.
G
C
These
things
were
not
in
the
in
the
chat,
there's
actually
a
very
good
point,
which
is
part
of
the
reason
that
no
one
can
think
about
what
it
means
is
because
the
relationship
we're
asking
is
inherits
and
the
relationship
that
the
word
uses
is
assignable
and
and
if
it
just
said
type
dot
inherits
from
then,
because
I
think
that's
the
I
think
that's
the
problem
is
assignable
from
and
inherits
from,
are
opposite
relationships.
B
Takes
into
account
hierarchy
interfaces-
and
you
are
obviously
assignable
to
yourself
right-
is
subclass
of-
is
only
typed
hierarchy
and
nothing
else
right,
but
I
mean
the
like.
C
B
B
It
doesn't
take
into
account
explicit
or
implicit
caste
operators,
and
it
does
not
take
into
account
I
dynamic,
castable
or
whatever.
That
interface
is.
C
It
does
is
assignable
from
use
custom
conversion
operators.
I
don't.
C
B
C
Effectively,
so
I
definitely
agree
that
we
have
room
for
improvement
yeah.
I
I
don't
know
if
just
adding
is
assignable
two
gets
it
right,
I'll
I'll
single
out
kevin
for
having
a
a
very
good
comment
in
the
chat
of
great
now
he
can
just
get
it
wrong
with
two
methods
instead
of
one
so
yeah.
C
Right,
well,
I
mean,
even
if
you
don't
do
the
named
parameters,
if,
if
when
you're
calling
it
and
intellisense
tells
you,
the
signature
is
base
comma
derived,
then
you're
like
oh,
I
put
the
base
one
here
and
the
derived
one
here
yeah,
but
is
assignable
to
or
sorry
is
assignable
from,
I
think,
is
just
called
type,
and
so
you
have
instance
is
assignable
from
some
other
type
and
it
doesn't.
It
doesn't
help.
You
know
which
one
is
the
base
and
which
one
is
the
derived.
I
mean
what
the
candidate
check
is.
C
C
C
Editor
browse
will
never
from
there
we
go.
I
think,
that's
where
emo
started.
G
G
G
Right,
well,
it's
not
bad,
it's
just
similar
to
the
other
one
like
we
should
not
have.
We
should
not
equally
promote
two
ways
of
doing
the
same
thing.
We
should
make
up
our
mind
which,
which
we
promote
and
then
not
promote
the
other
one
right
and
in
that
sense,
obsoleting
is
actively
demoting.
The
other
one
right.
I.
D
Mean
this
is
intellicode
right
because,
like
if
you
intellicode
starts
like
hey,
everybody
in
the
world's
using
is
assignable
from
so
that's
what
they
build
in
their
model,
and
so
then
that's
what
they
suggest.
You
use
right
and
then,
as
soon
as
you
do
it.
It's
like
here
comes
the
code
fixer
to
tell
you
not
to
do
that
and
then
eventually
the
model
relearns
right
but
yeah.
The.
D
A
Even
better
would
be
if
we
could
teach
the
model
to
to
replace
usages
of
the
previous
with
the
with
the
better
api
for
cases
where
it's
a
trivial
conversion,
yeah.
E
C
C
I
I
agree
of
the
like
kevin's
point
is
very
succinct
of
like
now.
You
have
two
things
that
you
can't
reason
about.
I
think
I
think
one
of
the
biggest
problems
is
the
fact
that
the
parameter
name
doesn't
help.
You
know
which
one's
supposed
to
be
the
parameter
and
which
one's
supposed
to
be
the
instance.
F
C
C
I
yeah,
you
were
just
saying,
left
constant
versus
right,
constant,
but
this
is
in
an
assignment
statement.
The
base
type
has
to
be
on
the
left
and
the
right,
the
more
rich
type
has
to
be
on
the
right,
and
but
the
relationship
we
have
on
type
is
the
opposite
of
that.
C
G
C
Always
thought
of
it
wrong
and
then,
when
I
was
saying
why
it
was
wrong,
I
then
talked
myself
backwards,
because
I've
learned
this
is,
I
learned
the
worst
thing
possible,
which
is
it's
the
opposite
thing
that
I
think
it
is
so
I
remember
that
and
then
I
know
what
it
means
and
then
I
remember
no,
it's
the
opposite
of
what
I
think
it
is
and
then
I'm
in
a
in
an
infinite
loop.
Never
remember
it's
the
opposite
of
what
I
think
it
is
just
trying
to
remember
the
right
answer.
G
G
G
C
A
C
A
C
G
Yeah,
it's
just
that.
I
think
we
want
to
promote
one
of
them,
because
the
thing
is
it's
not
just
for
the
person
who
wrote
the
code
right
over
the
person
who
reads
the
code
later
and
if
you,
if
we
believe
that
it's
better
to
have
them
in
one
order,
we
should
just
push
for
that
one
order
and
tell
people
to
change
their
code
like
I
wouldn't
make
it
a
warning
like.
C
B
A
Well,
I
mean
it's
trivial
enough
to
do.
Is
null
question
value
whatever.
G
D
F
G
C
Yeah
well,
so
I
think
that
means
for
every
person.
You
have
one
model
and
you
always
want
one
of
them,
and
this
is
going
to
be
very
much
to
you
know
pop
an
analogy
of
left,
const
versus
right.
Const
of
you
can
over
time
you
can
tell
who
wrote
the
code.
G
Yeah,
I
guess
I
mean
who
could
be
a
form
of
confirmation,
bias
right.
It's
like
it's.
Just
all
the
people
ever
talked
about
this
said
like
yeah.
I
always
get
this
right,
so
I
always
get
this
wrong
like
it's.
Maybe
the
ones
who
get
it
right
or
they
just
don't
know
this
right.
D
G
I
mean
the
fact
that
it's
a
virtual
method
makes
it,
unfortunately,
so
that
we
can
never
remove
it
right.
We
always
have
the
both
the
old
and
the
new.
The
only
the
best
we
can
do
is
we
can
say
the
old
one
is
only
for
extenders
and
the
new
one
is
only
for
people
using
it,
but
that
might
is
the
water
somewhat
right.
So
maybe
you
just
accept
it
as
not
worth
it.
A
Yeah,
I
think
it's
not
worth
trying
to
promote
one
versus
the
other,
because
it
really
depends
on
do
you
prefer
equals
cast
y
or
do
you
prefer
prefer
x's
t
y.
A
G
G
G
G
Not
that
strong,
like
if
everybody
else
in
the
meeting,
thinks
it's
a
good
idea,
I
would
be
like
okay,
I
mean
I
originally
said
it's
a
good
idea
right.
The
only
reason
why
I'm
not
backpedaling
is
that
I
am
I'm
not
sure
I
suffer
confirmation
bias
and
I'm
also
not
sure
that
the
additional
complexity
of
presenting
people
with
both
choices
is
actually
resulting
in
fewer
mistakes
or
more
mistakes,
and
it
seems
that's
what
would
happen.
G
G
C
Right
so
I
think
we're
either
saying
yes
to
this
modulo,
any
other
name
that
somebody
wants
to
substitute
for.
Oh,
I
guess
type
gets
a
question
mark
here.
C
Yeah,
because
I
think
what
I
really
want,
like
my
conflicted,
yes
is,
I
would
rather,
we
didn't
add
this
and
renamed
the
parameter
and
is
assignable
from
and
probably
no
one's
calling
that
one
with
named
parameter
syntax,
but
it
would
still
take
a
while
before
everybody
gets
on
targeting
packs
that
always
help
them
out.
C
C
G
Yeah,
I
would
say,
generally,
we
don't
change,
parameter
names
for
aesthetics,
but
if
there's
a
strong
reason,
because
people
people
get
it
wrong
because
the
things
are
named
incorrectly,
I
think
we
should
feel
like
we
are
able
to
fix
that
because
it's
only
a
source
breaking
change.
Realistically,
yes,
there
could
be
a
runtime
breaking
change
if
somebody
does
reflection
or
something,
but
that
seems
far-fetched.
So
I'm
I'm
inclined
to
say
it's
fine.
G
G
Well,
so,
okay,
let
me
let
me
let
me
try
to
open
the
picture
so
for
net
all
up.
We
said
we
will
make
breaking
chains
between
releases
right.
So
it's
not
that
we
don't
do
breaking
changes
period.
We
don't
do
breaking
changes
in
the
bcl,
usually
and
the
reason
we
don't
do
them
there
is
because
of
a
library
ecosystem,
which
is
largely
defined
as
binary
compatibility
right.
So
I'm
generally
fine
with
saying
if
you
retarget,
you
have
to
change
some
things
in
your
code
right.
We
just
have
to
pick
our
battles.
G
We
should
not
do
this.
Oh
my
god.
We
just
make
aesthetic
fixes
left
and
right
and
now,
every
time
we
upgrade
you
introduce
20
or
30
source
breaking
changes
every
release
right.
But
if
we
have
an
api
that
people
use
fairly
frequently
or
frequently
enough
and
people
get
it
wrong,
half
the
time
because
the
parameter
name
is
named
incorrectly,
I
feel
like
that's
something
where
we
could
say:
yep,
it's
a
source,
breaking
change
and
it's
fine,
because
the
value
is
high
enough.
G
A
C
Mean,
like
you
know,
if
we
wanted
to
talk
about
math,
div
rim,
I
every
time
I
use
it.
I
have
to
go
look
at
the
implementation
to
find
out.
Is
it
outing
the
division
or
the
remainder,
and
because
I
think
it's
just
called
out
value
and.
A
C
But
so
yeah,
if,
if
we're
willing
to
take
the
minor
risk
of
source,
breaking
change
here,
but
think
that
the
better
answer
is
to
rename
the
parameter.
Admittedly,
it's
a
parameter
name
on
a
virtual,
which
means
maybe
we'll
we'd
feel
slightly
worse
about
it,
because
the
overrides
are
going
to
restore
the
name,
not
that
anybody
ever
talks
about,
like
all
of
the
in
the
case
of
type,
all
of
the
types
that
extend
type
are
non-public.
C
Right
so
I'm
just
like.
I
think
that
the
better
fix
is
to
go
back
in
time
and
rename
the
parameter
to
is
assignable
from,
given
that
I
don't
have
a
time
machine
today,
which
means
I'll
never
have
one
damn.
It
is
that
that
renaming
the
parameter,
I
think,
is
my
preferred
fix
to
is
assignable
to,
but
if
we
don't
want
to
rename
the
parameter,
then
is
assignable
to
at
least
help
someone
by
identifying
which
one
it
wants,
and
now
you
can
from
that
knowledge
theoretically
use
both
of
them
correctly.
G
B
B
B
The
the
theory
is
that
you
need
a
destination
already
set
and
the
time
machine
itself
is
the
destination.
G
I
think
primer
is
the
only
timetable
movie
that
I
genuinely
had
to
stop
and
draw
a
diagram
a
few
times
before.
I
could
make
sense
of
what's
going
on
which
one's
primer
there's
two
guys
in
the
garage
that
build
a
time
machine
effectively
where
you
sit
in
the
time
machine
and
then
the
time
that
passes
is
the
one
that
you
use
to
travel
back
and
then
they
recurse
and
then
it
gets
very
quickly
complicated
and
they
meet
themselves
and
when
they
meet
themselves-
and
it's
not
it's
not
very
straightforward-
I
mean
you
can
google
it.
G
I
think
xkcd
has
a
comic
where
he
shows
diagrams
for
different
back.
C
To
the
future
has
its
three
timelines:
yeah
primer
is
just
like.
Take
a
pencil
and
squiggle.
G
The
technical
term
for
this
is
brain.
I
think
that's
how
that's
it's
it's
very
interesting,
though
I
I
really
like
the
movie
it's
worth
watching.
C
I
believe
so
because
that
that
one
member,
somehow
we
we
just
spent
you
know
40
minutes
on.
C
In
the
chat
people
are
talking
about
the
underscore
type
interface,
and
so
levi,
just
added
is
assignable
to
on
that
interface,
with
a
dim.
So.
G
G
Anyway,
I'm
I'm
not
convinced
a
language
that
has
made
breaking
changes.
Every
language
release
is
eligible
for
giving
us
feedback
for
works.