►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
All
right
friends,
we
are
live
for
the
last
apr
review
for
the
year.
Probably
let
me
open
up
the
thing
here
all
right,
so
I
don't
have
a
particular
order,
so
I
will
just
do
them
top
down
and
let's
see
how
far
we
can
get.
A
B
B
C
B
So
yeah
basically
proposal
is
to
introduce
multiplying
of
legs.
Well,
two:
okay,
second
version
that
just
returns
while
it
will
pull
off
two
hills:
lower
and
upper.
D
Is
this
something
we've
decided
the
jet
optimizer
shouldn't
do
isn't
worth
it.
B
C
B
C
E
We
approved
divrem
overloads
last
week
for
this
purpose.
I
don't
think
there's
actually
that
many
and
most
of
them
are
fairly
core
methods
like
in
math
or
intrinsics.
E
We
don't
have
a
lot
of
places
elsewhere
that
I
think
this
would
benefit
as
as
much
as
these
ones
do
where,
where
you're
talking
about
a
very
specific
performance,
oriented
api.
A
F
I
would
say
that
it
it's
it's
fundamentally,
something
where
you
actually
have
a
single
instruction
that
wants
to
return
values
in
multiple
registers
and
it's
very
difficult
for
the
regist
for
the
sorry
for
the
jit
to
effectively
utilize
that
without
something
like
this
and
without
some
significant
rework
kind
of
front
to
back
in
the
jet.
F
G
B
H
Feel
like
the
heuristic
would
be
if
it
returns
of
type
and
outs
the
same
type,
because
that's
at
least
true
for
div
rim.
In
this
one.
E
H
F
But
but
again,
sort
of
the
fundamental
issue
is
that
we
are
trying
to
represent
a
an
intrinsic.
I
mean
this
is
so
this
particular
scenario
is
fairly
specific
to
intrinsics.
It's
the
case
where
you
want
to
generate
a
single
instruction
that
will
produce
multiple
values
and
it
doesn't
inherently
depend
on
those
values
being
identical.
It's
just
unlikely.
F
I'm
not
aware
of
any
hardware
intrinsics
that
produce
two
registers
where
the
types
of
the
thing
in
the
different
registers
are
different,
I
mean
they
may
exist,
but
but
the
fact
that
they're,
the
same
type,
is
not
fundamental
to
the
problem.
F
I
actually
think
tanner
or
or
jager
could
probably
better
respond,
but
my
my
guess
would
it
be
that
it's
considerably
less
than
10.
E
Yeah,
I
would
say,
that's
accurate
in
fact,
outside
of
this
one
and
potentially
one
other
in
the
bmi
namespace.
I
don't
think
we
have
any
on
x86
and
we
already
had
retroactively
fixed
this
for
arm
before
we
shipped
on
net5.
E
C
I
F
So
I
will
confess
that
I
did
that
and
I
did
it
as
a
you
know.
That's
the
word,
an
experiment
to
see
if
I
could
get
what
I
expected
by
doing
this,
so
I
have
no
pretense
to
being
an
api
designer.
So
I
have
you
know,
nothing
is
invested
in
the
name
other
than
it's.
What
I
picked,
because
I
couldn't
overload
by
return
value.
B
C
E
C
E
Taken
already
yeah
someone
at
the
bottom
suggested
we
just
call
it
multiply
instead
of
multiply
no
flags
at
least
today
the
fact
that
it
doesn't
modify
the
flags
isn't
relevant
to
the
jit
and
it's
possible
it's
reasonable
to
say
that,
because
this
is
an
intrinsic
api
and
because
it's
so
special
case,
it's
okay,
just
to
call
it
multiply.
E
H
E
The
old
one,
the
I
believe,
we're
going
to
have
the
the
old
one
forward
to
the
new
one,
and
I
believe,
carol
has
indicated
on
various
pr's
that
the
code
gen
will
be
identical
at
that
point,.
E
Yes,
because
you
can
then
avoid
one
of
the
registers,
I
believe
in
this
particular
in
in
the
case
of
this
particular
api,
and
it's
frequently
the
case
that
you
only
want
the
upper
result
frequently
when
you're
doing
a
64
by
64
multiplication
to
produce
a
128
bit
result.
You
just
want
the
upper
bits.
E
E
F
Case
that's
been
checked,
I
mean
I,
I
don't
know
that
others
do
not
generate
the
same
code,
but
if
you
look
at
the
code
that
you
can
see
at
the
top
of
the
screen
now
it
produces
that
identical
code
for
both
the
out
version
and
the
value
tubal
version
and
and
the
reason
is
kind
of
due
to
the
magic
of
inlining
that
we
don't.
F
We
don't
record
the
fact
that
the
value
is
address
taken
until
we've
done
importing
and
inlining
is
done
as
part
of
the
importing.
So
by
the
time
we're
done.
Inlining
that
address
taken
thing
disappears
and
it's
you
know
you
just
have
a
a
call
to
the
value
tuple
version
so.
F
Correct
so
when
I,
when
I
first
did
this,
I
actually
made
it
private
the
the
the
version
with
a
two
suffix.
E
I
think
the
downside
is
it
in
it
forces
users
to
use
unsafe
code
and
code
that
they
otherwise
would
not
need
to
use
such
depending
on
the
scenario
that
that
could
have
various
implications.
E
G
E
G
Like
it
seems
like,
if
pointers
are
the
problem,
then
we
ought
to
be
taking
a
pass
and
saying:
how
can
we
get
rid
of
pointers
generally
and
as
opposed
to
dealing
with
it
in
this
one
particular
instance.
D
A
C
E
And
there's
also
reasons
to
have
pointer
overloads
as
well.
For
example,
you
can
then
have
the
guarantee
that
the
data
is
pinned
and
you
can
rely
on
the
alignment
so
that
you
can
use
certain
instructions
you
couldn't
otherwise
use
so
there's
cases
for
both
sides
of
the
coin
of
wanting
pointers,
and
not
it's
just
this
particular
case
where
the
underlying
instruction
doesn't
fundamentally
use
a
pointer
where
it's
causing
a
hindrance.
C
So
it
to
me
this
is:
there
are
two
separate
issues
here
that
are
rolled
into
one.
There
is
a
performance
issue
which
we
can
just
go
and
fix
with
zero
changes
to
the
public
service
area
right.
We
we
can
add
if
we
wanted.
We
want
to
add
this
as
a
private
thing,
we
can
do
that
and
no
one
is
the
wiser
your
code.
Gen
just
gets
better
separate
from
that.
C
There
is
a
concern
around
usability
and
whether
we
force
people
to
use
pointers,
and
so
all
the
stuff
around
you
know
the
assembly
code
generation
from
this
issue,
I
think,
is
sort
of
a
red
herring
right,
we're
just
talking
about
the
usability
and
whether
we
want
to
force
people
into
using
unsafe
code
to
call
this
api.
A
E
We
have
a
couple
others
on
the
base
class
that
we're
using
and
exposing
publicly
via
bit
operations.
Instead,
as
we
determined,
there
was
no
reason
to
expose
them
directly
as
intrinsics.
A
H
That
said,
in
such
a
strategy
where
you're
gonna
have
gaming
conflicts,
I
you
know
we
do
in
have
as
the
written
guidance
that
if
you
can't
come
up
with
a
better
name-
and
I
agree
that,
having
multiply
next
to
multiply
no
flag
suggests
they're
different
when
really
they're.
Just
they
had
a
naming
conflict
that
the
right
answers.
Stick
a
2
on
the
end
see
also
x,
509
certificate,
2.
C
H
Know
yeah,
so
that's
the
when
going
through.
If
we
find
a
similar
collision,
then
I
think
that
the
two
is
the
right
answer:
don't
try
and
be
clever
and
invent
new
names.
C
We
should
come
back
with
from
a
public
surface
area
perspective.
We
should
come
back
with
sort
of
the
complete
set
that
we
want
to
look
at
holistically
in
terms
of
what
problems
we're
trying
to
solve.
Now,
if
it
turns
out
the
complete
set,
is
this
and
one
other,
then
that's,
you
know
probably
a
pretty
quick
thing
to
do.
C
G
F
So
we,
I
think,
the
way
we
avoid
that
going
forward
is
that
we
have
perfect
ability
to
predict
the
future.
So
I
mean
it's
just.
This
is
the
nature
of
engineering.
So
I
actually
only
found
this
because
an
external
contributor
proposed
an
alternative
which
actually
was
very
scary.
The
way
it
was
depending
on
things
happening
a
certain
way
in
the
jet
and
at
the
time
I
happened
to
be
working
on
and
registering
more
structs
that
that
come
in
as
parameters-
and
I
realized
there
was
a
certain
commonality
here.
F
So
you
know
it
was
fortuitous
that
I
realized
okay,
this.
This
is
the
right
way
to
handle
this.
You
know
you
can't.
F
I
wish
I
had
thought
of
that.
At
the
time
we
were
discussing
these.
There
was
some
discussion
way
back
when
about
returning
value
tuples,
and
at
that
time
there
was
pushback
that
we
shouldn't
be
returning
value
tubals.
So
I
do
remember
that
was
the
case.
I
was
told
that
noah
were
really.
The
issue
is
that
you
shouldn't
have
valuetuber
parameters.
F
Nevertheless,
you
know
I
I
don't
think
you
can
say
well.
This
is
something
we
should
have
foreseen
because
you
just
can't
always
predict
what
engineering
conclusions
you're
going
to
come
to
in
future.
G
F
So
this
one,
you
know
all
of
these
were
implemented
in
the
jit
before
they
were
approved,
and
there
are
many
cases
where
the
jit
doesn't
generate
the
code
you'd
like
it
to
and
the
solution
to
that
is
not
always
obvious
right.
D
D
E
So
I
think
the
fundamental
problem
here
is
for
each
x86
and
arm.
We
added
roughly
you
know,
15
to
1500
to
2000
intrinsics.
We
were
doing
this
within
a
single
release
for
perf
reasons.
We
did
do
investigations
to
ensure
perf
was
correct,
but
there's
always
going
to
be
cases.
These
are
compilers
they're,
one
of
the
most
complex
things
that
we
can
build
as
software
engineers.
E
There
are
complex
cases
where
it
looks
great
in
the
simple
scenario
you
you
test,
it
runs
great
it
it
tests
great
and
then
there's
this
other
case
where,
when
you
combine
certain
il
patterns
together,
we
just
generate
bad
code
and
there's
cases.
B
G
H
A
I
mean
I
understand
the
desire
to
have
the
feature
work,
the
right
the
right
time,
the
first
time,
but
I
mean
honestly
considering
how
many
intrinsics,
basically
we
have
shipped-
I
mean
it's
true
for
almost
any
api
we
ship,
but
almost
any
api
we've
after
we
ship.
We
find
out
that
there's
some
use
case
where
the
proposed
apis
don't
work,
but
that
might
be
perfect
might
be
usability.
There's
various
areas
right
and
considering
how
many
intrinsics
we
have
added
and
considering,
like
the
amount
of
like
I
guess,
revisions
we
have
done
since
then.
A
I
think
that's
in
the
realm
of
what
you
can
expect
for
almost
any
api
service
being
added.
So
I
I
don't
think
it's
necessarily
useful
to
try
to
avoid
all
these
problems
moving
forward
because
it
no
means
you
know
if
china
brings
a
new
intrinsic
and
he
has
to
bring
the
assembly
code
for
five
different
cases
like.
I
don't
want
to
review
that
either.
A
Like
I
mean
like
considering
that
my
eyes
already
fall
out
of
my
head
for
half
of
these
like
now,
imagine
you
also
have
to
stare
at
assembly
code
for
half
of
them
like.
I
think
that
at
that
point
you
just
no
longer
do
this
work
right
and
I
feel,
like
that's,
that's
swinging
the
pendulum.
I
think
the
wrong
way.
I
think
that's
we
have
to
accept
some
amount
of
yeah.
We
can
predict
the
future
and
we
deal
with
that
once
we
see
those
things
right
and
that's.
G
A
G
G
It's
the
jit
can
optimize
this,
so
we're
going
to
expose
a
method
that
allows
the
jit
to
optimize
this,
because
it
can't
because
there's
no
other
good
way
to
get
the
same,
optimization
right,
and
so,
if
we're
doing
that,
we
ought
to
be
making
sure
that
we're
getting
the
optimization,
there's
absolutely
no
value
in
shipping
and
intrinsic
that
doesn't
give
you
the
optimization.
You
want.
F
That's
really
not
true,
I
mean
I
really
take
exception
to
that
there
are,
I
mean,
even
even
in
c
plus,
there
are
intrinsics
that
when
you
look
at
the
generated
code,
it
wasn't
able
to
put
everything
in
registers
like
you
expected,
and
I
mean
unless
you
use
the
ancient
sea,
you
know
register
stuff
and,
at
any
rate
point
being
that
it's.
F
F
I
mean
that
that's
that
maps
to
an
instruction-
and
in
fact
you
know
if
you
scroll
back
the
intrinsic,
actually
generates
the
molex.
The
problem
is
the
code
around
it
and
there's
plenty
of
issues
in
legit
having
nothing
to
do
with
intrinsics.
Where
it,
you
know
it.
There's
extra
loads
and
stores.
There's
extra
copies.
It's
you
know
the
jit
is
a
jit.
F
C
I
this
might
be
my
naive,
I'm
not
a
jet
dev
perspective,
but
it
seems,
like
you
know,
from
my
perspective,
I
think,
of
in
this.
In
this
light,
like
what
can
the
system
do
for
me
in
terms
of
coach,
and
it
seems
like
we
can?
Actually
we've
proven
that
we
can
actually
get
the
right
code
gen
for
the
current
api,
so
we
may
not
have
been
doing
the
absolute
best
thing
previously,
but
we've
been
able
to
fix
it
under
the
existing
signature.
C
It
so
happens
that
the
solution
to
that
wasn't
entirely
in
the
c
code
that
makes
up
the
jet.
It
also
includes
a
private
api
in
managed
space,
which
seems
totally
fine
to
me.
So
it
seems
like
we.
We
are.
We
found
a
problem
and
we
fixed
it
and
we
did
it
all
under
the
existing
surface
area
and
the
only
reason
we're
even
talking
about
new
service
area
now
is
a
completely
unrelated
reason
about.
How
could
we
we
want
to
enable
developers
to
consume
these
apis.
A
C
A
C
No,
we
we've
discovered
that
we
we
discovered
that
for
new
apis
like
we
can,
we
can
potentially
avoid
some
additional
internal
boilerplate.
We
have
to
do,
but
fundamentally
that's
a
usability
thing
right.
We
we
know
now
that
we
can
expose
it
either
way.
Should
we
choose
to
and
we
can
get
the
exact
same
code
in
sure.
H
But
I
think
that
we
should
table
this
discussion
and
try
and
get
through
some
api
reviews,
since
this
is
the
last
one
of
the
year.
A
Yeah,
unless
somebody
has
an
actionable
feedback
item
for
tanner
and
and
legit
team
in
general,
like
I
think,
they're
yeah,
like
it's
a,
I
think
it's
a
it's
a
larger
issue.
Otherwise,
all
right!
So
let
me
just
toggle
to
the
next
one.
That
would
be
three
three
seven,
eight
nine.
F
F
A
Okay,
so
then
the
next
one
is
three:
three,
seven,
eight
nine,
which
is
override
stream,
read
async,
right
async,
which
is
an
analyzer.
I
think
the
proposal.
D
J
So
this
analyzer,
what
it's
saying
is
that
when
you
are
creating
a
new
stream
class
that
are
a
class
derived
from
stream
and
you
override
begin
read
and
read,
you
should
get
a
suggestion
to
also
override
the
other
right
and
read
methods.
J
It's
clear
if
you
scroll
down
and
you
look
at
the
example.
So
as
soon
as
you
override
the
two
methods
begin
with
an
end,
read
and
begin
write
an
and
write.
You
should
be
suggested
to
override
read
aging
for
an
array,
write
async
for
an
array
and
then
read
async
for
a
memory
and
write
async
for
a
memory.
B
H
Basically,
it's
yeah
the
sounds
like
it's,
especially
for
the
asyncs.
It's
whatever
point,
you've
overridden
one.
It
will
suggest
you
override
the
things
from
the
successive
waves
of
how
we've
written
asynchronous
code
so
begin
goes
to
task,
and
then
task
with
the
byte
array
goes
to
the
task.
With
memory.
J
Right
and
something
I
would
like
emo
to
help
clarify
is:
do
we
want
all
of
these
apis
to
be
suggested
to
get
overloaded,
no
matter
which
ones
the
user
is
overriding
or
do
we
specifically
want
to
only
offer
the
suggestion
when
the
user
overwrites
begin
read
and
read,
begin
right
and
write?
A
I
think
I
got
what
you're
asking.
I
think
that
depends
on
the
implementation
right,
so
we
so
the
the
general
spirit
of
this
analyzer
was
to
say
you
want
to
avoid
cases
where
somebody
just
does.
You
know
what
they
think.
The
right
thing
they
derive
from
stream
stream
is
abstract,
so
they
get,
you
know,
forced
to
override
certain
methods
so
that
them,
the
compiler,
is
happy.
They
ship
it.
Now,
then
they
have
a
ginormous
perf
bug
yeah.
A
A
So
I
think,
like
there's
other
cases
like
that,
where,
if
you,
if
you
derive
from
an
object,
there's
probably
more
methods
you
should
override
in
order
to
get
better
perf
or
better
behavior
or
more
consistency,
whatever
the
argument
is
right,
and
so
that
might
apply
for
overloads
or
it
might
not
right.
I
don't
know
enough
about
stream
to
know
when
you
override
this
overload.
You
should
also
override
the
other
overload
like.
If
that's
the
case,
then
it
should
also
suggest
those
does
that
make
sense.
Yeah.
A
Yeah
I
mean
like
as
soon
as
you
want
to
do
that
I
think
my
initial
gut
feel
was
also.
Maybe
we
can
generalize
this
right
an
event.
Some
sort
of
custom
attribute
that
we
can
put
on
the
methods
we
like
either
the
ones
that
the
user
overrides
and
then
point
to
the
other
ones
or
the
other
way
around
right.
A
But
some
data
driven
way
where
we
can
say
put
a
custom
attribute
on
some
of
your
methods
and
then
the
analyzer
will
generally
handle
all
of
them
right,
but
it
might
be
that
it's,
it
needs
very
specific
knowledge
about
the
type
that
we
can't
easily
express
in
custom
attributes,
in
which
case
once
you
have
that.
Maybe
at
that
point
also
the
code
chain
is
reasonable
because
you
already
have
a
one-off
anyway
for
that
type.
So
you
know
what
to
do.
A
We
find
a
way
how
we
can
generalize
this
into
a
custom
attribute,
but
customer
debuts
are
public
api,
so
you
have
to
kind
of
get
them
right,
the
first
time,
and
so
in
order
to
do
that,
you
want
to
have
enough
cases
to
know.
Is
the
attribute
expressive
enough
like?
Can
you
actually
use
them
in?
You
know
enough
cases
to
make
the
complexity
worthwhile
right.
So
I'm
okay
with
saying:
let's
just
do
it
one
time
for
stream
and
then
see
how
well
that
work
the
whole
well
that
works
in
other
places.
I
J
Yeah,
that
was
my
question
too.
It's
not
entirely
clear
from
the
main
description.
Do
we
want
if
the
user
creates
a
class
that
inherits
from
stream?
Do
we
want
this
analyzer
to
automatically
show
all
the
to
automatically
suggest
adding
overload
override
sorry
for
those
six
methods,
or
do
we
want
them?
C
I
think
it's
going
to
be
the
reason
I'd
originally
suggested
this
just
for
read
and
write.
Async
is
because
we
can
trigger
off
of
the
fact
that
whether
there's
an
existing
override
of
the
existing
read
async-
that
takes
a
byte
array
and
there
is
sort
of
there-
is
value
and
also,
in
that
case,
overriding
the
memory
based
ones
that
return
value
tasks
instead
of
tasks
for
everything
else.
It's
not
always
clear.
I
mean
yeah
in
a
perfect
world.
C
You
could
say
you
should
override
everything,
but
let's
say
you
have
a
stream
that
is
only
is
read-only
or
a
stream.
That's
right
only
and
we
would
be
warning
people
to
override
all
of
the
right
methods
on
the
read-only
one
or
all
the
read
methods
on
the
right,
one
for
which
there's
really
no
benefit
to
them.
Doing
so
other
than
maybe
making
a
failure
case
fail
faster.
C
I
think
it'd
just
be
super,
noisy,
so
yeah.
I
I
my
goal
was
to
keep
it
pretty
scoped
to
the
the
single
case
that
we
know
there
is
benefit
in.
H
Yeah
looking
at
the
implementation
and
steve,
maybe
you
remember
different
than
how
I'm
reading
it.
It
looks
like
you
never
need
to
override
the
iasync
result,
one
because
it
just
calls
it
just
uses
the
boilerplate
to
give
an
eye
sync
result
from
a
task.
H
Therefore,
if
you
never
overrode
that
one
you're
fine,
but
if
you
did
override
that
one,
you
should
override
the
forward
ones
and
if
you
override
either
of
the
ones
that
return
a
task
like
you
should
do
both
from
bite
array
to
memory,
because
you
can
avoid
the
the
intermediate
like
the
pinning
of
the
memory
and
the
intermediate
buffer
and
the
and
the
copy
backwards.
So.
H
C
So
you
know:
stream
has
grown
up
over
two
decades,
with
additional
virtual
methods
being
added
that
have
to
then
delegate
to
the
existing
virtuals
and
that's
why
we're
we're
so
careful.
Now,
anytime,
we
we
get
an
issue
opened
or
proposal
to
add
new
virtuals
because
it
just
adds
to
this
delegation
chain
so
pretty
much
every
api
other
than
the
abstract
ones.
C
C
And
so
like
we're,
not
you
know
you
can
override
them
and
you'll
get
slightly
you'll
get
better
performance
if
someone
is
using
them,
but
it's
certainly
not.
I
wouldn't
add
an
analyzer
just
for
that
where
you
know
there
are
a
couple
other
ones
where,
depending
on
use
cases
like,
if,
if
someone
actually
is
using
stream.readbyte
or
stream.writebyte
it
does,
it
is
beneficial
if
you
can
override
them
and
provide
a
better
implementation.
C
It's
beneficial
to
do
so,
because
the
base
implementations
aren't
particularly
efficient.
They
allocate
an
array
and
call
the
you
know
the
read
thing
or
the
or
the
right
method,
but
they're
also
generally
not
used
on
hot
paths.
The
reason
this
focused
on
the
read
write
async
that
take
a
memory
is
because
those
are
now
becoming
the
apis
that
everyone
should
be
calling
everywhere.
C
In
fact,
we
have
an
analyzer
now
that
pushes
you
in
that
direction,
if
you're
using
the
read
async
right,
I
think
that
take
byte
arrays
carlos
as
analyzer,
tells
you
no
use
the
memory
ones
instead
and
we'll
happily
make
the
change
for
you,
and
so
we,
if,
if
you
don't
override
those,
you
will
not
be
getting
as
good
performance
as
if
you.
H
Did
yeah
and
then
I
think
we
probably
want
the
analyzer
to
ask
whose
version
of
the
other
things
it's
getting,
because
if
you
have
an
intermediate
type,
like
things
become
really
weird,
certainly
we
can
say
if
you've
overridden,
read
async,
that
takes
a
byte
array
and
your
read
async,
that
takes
a
memory,
comes
from
system,
io
stream.
You
should
overwrite
it,
but
if
there
was
a
class
in
the
middle,
you
may
just
be
adding
logging
and
there's
no
benefit.
H
So
you
would
do
it
as
base
class
immediate
base
class
and
not
where
did
the
virtual
implementation
come
from
right?
It's
fair.
C
C
And
if
you're
doing
my
initial,
my
initial
suggestion
was
even
simpler
than
that
it
was
purely
if
you
derive
from
stream
and
you
override,
read
async
that
takes
a
byte
array,
also
override,
read
async.
That
takes
a
memory
if
you
override
right
async.
That
takes
a
byte
array,
also
override
right.
I
think
that
takes
some
memory.
H
H
C
I
mean
we
can
I
I
I
don't
think
it's
wrong
to
do
so.
I
just
I'm
trying
to
be
cognizant
of
noise
versus
value.
H
A
C
Yeah,
if
your
base
class
is
stream
yep,
then
if
you
override,
read
async
that
takes
a
byte
array,
we
warn
you
and
you
don't
have
a
read,
async
override.
That
takes
a
memory.
We
warn
and
we
well,
I'm
not
sure
if
we
can
fix
it,
but
we
warn
or
we
info
or
whatever
the
right
term
is.
If
you
drive
from
stream
and
you
have
a
right,
async
override
that
takes
a
byte
array
and
you
don't
have
one
that
takes
read-only
memory.
C
We
you
know,
we
warn
if
you
derive
from
stream
and
you
have
a
oh,
this
one's
a
little
trickier,
because
you
have
to
have
a
reed
override
that
takes
a
bite
array.
Maybe
that's
why
I'm
hesitant
about
it,
but
because
we'll
be
warning
everyone.
C
J
C
Right,
including
in
those
cases
where
you're
you're
overriding
it
just
to
throw
not
supported
exception,.
H
A
C
C
The
same
category
as
the
rest
of
our
performance
rules,
which
I
believe
is
generally
on
by
default,
but
either
hidden
or
suggestion
as
the
level
or
hidden
or
info
whatever
the
right
terminology,
is
the
severity
yeah.
The
difference
between
those
is
one
of
them
shows
up
in
the
the
suggestions
thing
at
the
bottom
of
visual
studio,
whereas
hidden
only
shows
up.
If
you
like
client,
then
it
pops
up
the
little
icon.
I
So
I
have
a
silly
devil's
advocate
question,
so
let's
say
that
I
have
a
stream
derived
type.
I
I
implement
the
read
async
byte
array
method
and
then
this
analyzer
kicks
in
and
says.
Oh,
you
should
also
override,
read
async
of
memory
of
bite.
What
do
I
do
inside
of
that.
C
You
do
one
of
a
few
things
I
mean
the
naive
thing.
Is
you
just
delegate
to
the
the
byte
array
one,
but
that's
what
the
base
implementation
does.
Ideally,
you
invert
your
your
implementation.
You
move
the
implementation,
that's
in
the
byte
array,
one
to
be
in
the
memory
one
and
then
you
have
the
byte
one
called
the
memory.
One
yeah.
I
I
I
C
C
B
C
I
C
C
Yeah
or
you
you're
you're,
passing
it
along
to
some
wrapped
stream,
and
so
you
just
change
to
delegate
to
the
you
know
the
one
that
takes
you.
You
delete
the
offset
count
because
those
are
no
longer
necessary,
and
maybe
you
slice
or
something
like
that.
But
you
know
it's
it.
It's
also
not
something
we
can
generally
auto
fix,
and
so
that's
why
it's
not
a.
It
would
certainly
never
rise
to
the
level
of
a
warning.
I
No,
I
I
I
understand
it's
not
going
to
rise
to
a
warning.
I
just
I
what
I'm
afraid
of
is
that
we're
going
to
say
like?
Oh
you,
you
overwrote
this
one
thing
also
override
this
other
thing
and
by
the
way
here
are
five
new
concepts
you
have
to
be
aware
of
in
order
to
be
successful.
With
this.
H
I
C
I
Again,
the
thing
that
I'm
getting
out
is
if,
if
we
tell
people
like
okay
now
now
you
have
to
write
a
memory
based
api
if
you're
simply
delegating
to
another
stream
sure
forward
it
through
whatever,
if
you're
not
delegating
to
another
stream,
if
you're
actually
doing
something
yourself
now,
you
have
to
be
aware
of
things
like
pinning
things
like
memory,
marshall
things
like
all
these
all
these.
If.
C
I
C
I
With
the
what
we're
using
them
as
as
in
dot
net
extensively,
is
as
exchange
types,
we
don't
necessarily
expect
people
to
crack
them
open
and
look
at
them.
That's
something
that
always,
you
know,
gives
me
shivers.
Whenever
I
see
people
doing
that.
A
Right
because
most
of
the
time
I
mean,
even
if
you
don't
delegate
to
a
stream,
you
delegate
to
something
else,
that
is
a
data
sync
people
are
not
necessarily
writing
their
own
data
management
system
entirely
from
scratch
right.
So
most
people
are
probably
able
to
take
that
that
memory
and
put
it
to
some
other
thing
that
takes
a
memory
right.
I
C
H
C
C
H
C
I
mean
to
me
this
is
an
argument
against
the
rule.
This
is
going
back
to
my
comment.
This
is
an
argument,
a
question
about
what
the
default
severity
should
be.
I
think
it's
completely
reasonable
and
desirable
to
have
lots
of
things
that
you
can
turn
on,
that
tell
you
places
that
you
can
improve
your
code
in
one
way,
shape
or
form.
If
our
goal
is
to
just
not
have
it
be
in
people's
faces.
C
I
Yeah
and
as
as
I
think
you,
the
argument
that
you
had
made
earlier
is
most
people
are
probably
just
going
to
forward
it
anyway,
so
that
should
be
fine.
Okay,.
A
Think
for
the
I
think,
for
the
most
part,
though,
like
I
think
there
is
a
there's
a
difference
here
right.
So
we
are
not
flagging
people
to
code.
We
are
flagging
people's
derived
types
right
where
they
basically
say
already.
H
Non-Trivial
samples
in
the
documentation
for
this
particular
rule.
C
And
potentially
I
I
have,
I
honestly
have
no
problems
if
we
even
said
that
it
was
off
by
default
or
if
it
was
hidden
or
something
like
that.
But
what
I
care
about
is
that
we
can
say
turn
it
on
and
dotnet
runtime
or
we
can.
You
know,
work
with
stack
overflow
to
turn
it
on
in
their
code
or
we
can
turn
it
on
an
asp.net
or
wherever
and
flag
all
the
places
that
we
are
deficient
right.
H
And
that's
the
same
argument
that
I
have
for
the
the
synchronous
span
versions
is
having
the
rule
there,
so
you
can
say
dear
system,
tell
me
all
the
places
that
I'm
doing
a
double
copy,
because
I
have
to
rent
from
the
array
pool
call
the
other
overload
and
then
copy
it
back.
Tell
me
all
the
places
I
could
avoid
doing
that.
A
J
J
B
A
C
A
H
C
A
A
A
C
A
C
D
Yeah,
I
think
I
agree
with
steven
here
the
way
you
know
even
myself,
I've
used
analyzers,
often
to
just
control,
dot,
apply.
Assuming
that
it's
doing
the
correct
thing,
it's
possible,
a
user
might
see
the
warning
go
away
and
just
think
that
it
was
fixed.
A
Yeah,
I
think
that's
something
where
I
heavily
disagree,
and
I
mean
you
can
talk
to
the
resident
guys,
but
they
have
to
usability
studies
and
it
is
generally
not
considered
this
way
for
most
users,
most
users
see
fixers
as
a
way
to
go
from
a
to
b
and
most
refactorings
also
don't
result
in
100
equivalent
code
right.
They
are
almost
always
building
blocks
for
automating
keyboard
activity
so
that
people
don't
have
to
do
everything
by
hand.
That's
the
general
spirit
of
fixers.
A
C
C
A
Okay,
that's
something
I
forget
to
disagree.
I
don't,
I
don't
think
that's
useful
bar,
but
okay,
so
like
in
this
case.
I
think
it's
okay
to
say
we
can
say
override,
is
probably
good
enough
because
it
already
does
90
of
what
people
want
so
and
it's
less
expensive
than
us
writing
a
fixer.
So
that
to
me
is
a
useful
argument.
So
then
I
guess
we
don't
do
the
fixer.
Then.
A
All
right
so
then
one
down
so
then
yes,
the
next
one,
would
be
36194,
I
think,
leave.
I
thought
this
one.
I
I
did
yes
so
this
is.
This
is
basically
adding
overloads
to
or
not
overloads,
but
a
new
method
group
to
complement
activator.create
instance
right
now,
activator.createinstance
there
you
can
give
it
a
type
and
it
will
find
the
public
parameter
list
constructor
or
the
non-public
parameter
list
constructor,
and
it
will
create
an
instance
of
that
type
for
you
hooray
useful,
for
you
know
di
and
other
things
where
you
don't
necessarily
know
at
compile
time.
What
t
you
need
to
get
back?
I
The
problem
is
this
api,
is
you
know
a
little
slow,
especially
in
hot
pads
and
a
lot
of
frameworks,
especially
asp.net
and
di
systems
use
code
generation
in
order
to
emit
dynamic
methods
that
that
basically
just
wrap
a
call
to
new
concrete
type?
So
what
this
is
proposing
is
why
don't
we
just
offer
that
functionality
inbox,
so
the
proposed
api
method
group
at
the
top
is
create
factory
of
t
or
create
factory
of
type.
I
Sorry
there
there's
method
info.createdelegate!
That's
sorry
that
I
think
that's
give
me
just
a
second.
I'm
checking
something
real
fast,
oh
yeah,
so
there's
delegate
dot,
create,
delegate
and
method
info.createdelegate,
and
I
put
this
on
for
the
parameter-less
one.
I
put
it
on
activator
just
because
it
matches
the
existing
create
instance,
apis
that
are
already
on
activator
for
the
pyramidal
parameter,
full
one
which
I
haven't
talked
about.
Yet
it
would
go
on
constructor
info
rather
than
method
info
yeah
and.
H
I
Effect
equivalently,
yes,
the
there
would
be
some
small
implementation
differences.
For
instance.
We
would
try
to
do
as
many
checks
up
front
before
we
even
return
the
delegate
to
you,
so
exceptions
might
be
thrown
in
different
places,
but
the
exception
behavior
would
still
be
somewhat
same
sure.
H
I
Yeah,
it's
it's
a
more
optimal
lazy
of
the
other
guy
yeah
okay,
but
it's
using
tricks
that
we
can
only
do
within
the
runtime
that
other
externals,
including
regular
library
code,
can't
do
because
we
can
actually
like
reach
into
the
implementations
of
objects
and
the
memory
allocator
and
a
few
other
things.
H
I
Yeah,
that
and
and
in
fact
on
as
a
naive
implementation
for
mono,
we
would
probably
do
that
just
because
I
haven't
yet
plumbed
in
through
mono
the
work
to
make
this
optimal.
But
yes,
you're,
correct,
okay,.
I
C
Sorry
levi,
I
I
I
got
distracted
again.
You
probably
already
talked
about
this,
but
what
fundamentally
prevents
create
instance
of
t
that
returns
a
t
from
performing
as
well
as
create
factory
of
t
that
returns
a
func
of
t.
I
B
I
Create
factory
would
be
cached
per
t
and
then
create
instance
would
delegate
to
it.
I
The
problem
is,
there
is
still
a
a
bunch
of
like
static
indirection
there,
because
we
still
need
to
go
back
through
and
like
look
up
handles
from
types
and
all
that
fun
stuff,
and
it's
actually
faster,
if
you,
if
you
as
a
consumer,
just
have
your
own
cached
funk
rather
than
calling
create
instance
of
t
and
allowing
the
runtime
to
look
it
up
on
your
behalf,
because
you
already
have
the
direct
delegate
a
reference
to
that
delegate
in
your
own
code.
You
don't
have
to
look
it
up
anymore.
B
I
C
I
H
I
To
be
to
be
perfectly
honest,
we
can
probably
get
away
without
having
create
factory
of
t,
because
if
you
have
a
t
inside
your
own
code,
maybe
we
would
just
say
you
know
what
continue
to
call
new
t
and
assume
the
runtime
is
going
to
do
the
optimal
thing,
which
in
this
case,
would
be
calling
create.
Instance
of
t.
I
H
I
C
I
No,
I
see,
I
see
this
api
used
more
for
serializers
di
systems
and
other
things
that
are
trying
to
mimic
static
code
at
runtime.
C
So
the
the
difference
between
create
instance
and
create
factory
isn't
significant
enough
to
warrant
that
correct.
What
I'm
sorry
question
go
ahead.
I
M
Another
question:
does
this:
have
any
memory
savings
over
creating
your
own
dynamic
method.
I
Yes,
absolutely
there's,
because
this
does
not
spin
up
the
jet.
You
don't
have
to
allocate
new
executable
pages
like
it.
It
saves
quite
a
bit
of
time
and
overhead.
I
Versus
using
dynamic
method
to
do
il
emit
yourself,
oh
sure,
which
is
actually
what
this
is
trying
to
get
people
to
avoid,
because
if
you,
you
can
also
imagine
right
now
in
system
text,
json
say
that
you're
working
in
an
environment
where
a
jit's
not
feasible
we're
still
going
to
create
a
dynamic
method.
And
then
you
know
take
the
take
the
interpreter
cost
of
executing
that.
Well,
because
this
doesn't
spin
up
the
jit
at
all.
There's
no
interpreter
cost.
H
And
this
is
just
a
perf
savings
of
you've
already
validated
that
the
type
was
eligible
for
parameter-less
construction
right
like
you're.
Basically,
it's
the
it's
equivalent
to
again
empty
params.
That
goes
to
new
t,
but
the
because
create
instance
has
to
go,
find
a
constructor
and
then
bind
to
it
and
all
that
you're
you're
saving
the
cache
value.
I
Yeah,
if
you,
if
you
scroll
down
in
the
in
the
proposal
a
little
bit
more,
I
have
some
examples
of
where,
in
asp.net
and
system
text
json,
they
can
actually
jettison
their
own
use
of
dynamic
method
and
rely
on
these
apis
instead,
assuming
that
they
target
net
six.
I
Yeah
they're,
it's
really
a
performance
thing,
because
activator
create
instance
will
always
do
the
right
thing.
There
are
parameter
full
overloads
of
activator,
create
instance
that
I'm
not
showing
here,
and
that
would
be
the
way
to
call
say
that
you
have
a
system
that
takes
my
service
provider
as
a
as
a
constructor
parameter,
very
common
in
di.
A
That
one
I
didn't
quite
catch
like,
are
you
saying
the
overloads
that
take
the
object?
Arrays?
You
would
not
have
factories
for
because
people
need
to
generate
their
own
stops
because
that's
better.
I
So
for
when
you
have
a
parameter
full
constructor,
I
at
that
point
you
need
to
specify
the
delegate
type,
because
I
don't
really
know
what
the
signature
of
the
parameters
that
you're
trying
to
bind
is
and
that's
why
I
have
that
stretch,
goal
api,
which
is
well,
if
we
add,
create
delegate
to
constructor
info
just
like
how
we
have
create
delegate
on
method
info.
You
can
actually
give
me
a
delegate
type
and
I
can
return
a
delegate
that
matches
that
exact
signature.
I
That
is
strongly
bound
to
that
constructor
that
encapsulates
the
action
of
newing
up
the
object
and
then
calling
the
constructor
on
it.
That
would
involve
spinning
up
the
jet.
Yes,
however,
we
would
be
very
conservative
with
how
much
we
spin
up
the
jet
by
the
way
methodinfo.createdelegate
today
also
spins
up
the
jet.
So
that's
not
a
behavioral
difference.
I
I
That's
also
why
I'm
not
using
fun
of
everything
here
like
I'm,
I'm
not.
I.
I
didn't
provide
like
funk
of
t
funk
of
t
and
u
funk
of
t
and
u
and
v
overloads
here,
because
you
can't
specify
things
like
spans
inside
funk
and
if
your
delegate
signature
happens
to
take
a
span
as
a
parameter
like.
I
can't
help
you,
but
by
allowing
you
to
specify
the
actual
delegate
type
itself
now,
we
can
actually
make
a
stub
that
allows
things
like
spans
in
construction
again,
just
like
method,
info.createdelegate.
I
If
you
scroll
to
the
bottom
of
the
proposal,
there's
a
section
titled
stretch
goal
apis,
which
shows
a
a
code
sample,
but
in
in
the
particular
case
that
I
have
in
that
code
sample
I'm
considering
two
services,
my
service
and
my
other
service,
both
of
which
have
constructors,
which
take
an
I-service
provider.
I
The
di
system
would
get,
would
use
standard
reflection
to
get
the
constructor
info
corresponding
to
each
of
them
and
then
would
call
constructorinfo.createdelegate
funk
of
I
service
provider
to
object
or
function
by
service
provider
to
iservice
or
whatever
signature
they
needed.
And
then
we
would
create
a
stub
which
encapsulates
newing
up
the
object
and
calling
the
constructor
and
then
returning
it
back
to
the
caller.
A
I
I
We're
actually
that
that's
why
this
involves
the
chat
in
order
to
implement
this.
Only
this
one
only
this
particular
overload
of
create
delegate
spins
up
the
jet.
Sorry,
only
this
method
group
spins
up
the
jet
activator.createfactory,
will
not
require
spinning
up
the
jet
constructorinfo.createdelegate
will
require
spinning
up
the
jet.
G
I
So
we
can,
we
can
probably
optimize
a
few
things
like
say
that
you
pass
in
one
or
two
or
three
parameters.
We
can
probably
special
case
that
by
having
all
of
those
pre-jitted
as
part
of
corelib,
but
I
don't
want
to
go
too
crazy
with
it.
G
Yeah
one
question
here
is
in
terms
of
di
system
usage
today,
how
much
is
covered
by
just
the
activator
changes
and
how
much
really
requires
the
constructor
changes
I
mean
it
sounds
to
me
like
di
systems
often
are
have
like
a
you
know.
Like
a
I
forget,
what's
called
service
provider,
I
service
provider,
interface
or
whatever,
on
the
constructor
so
like
to
make
asp.net
happy
fully
happy.
Does
it
really
require
constructor
info
or
or
not.
L
I
would
say
most
common
is
taking
the
direct
dependencies
because
that's
what
we
recommend
now
the
service
locator
pattern
where
you
take
an
I-service
provider,
happens
a
lot
as
far
as
like
it's
not
the
recommended
pattern.
I
say
it
would
happen
less
than
taking
your
dependencies
directly,
but
it's
still
very
common.
L
As
far
as
the
parameter
release
constructor
goes
like
it
happens.
We
wouldn't
want
that
to
break,
but
I
would
say
that's
the
least
common
of
all
those
yeah.
That's.
L
Yeah
we
use
it
for
options.
I
guess
like
just
to
get
like
a
default
instance
of
a
lot
of
options,
objects
so
yeah
I
mean
they
all
come
up
a
fair
amount.
I
Yeah,
the
if
you
had
an
arbitrary
number
of
parameters
where
those
dependencies
could
be
ifu
ibar,
ibaz,
literally
anything
unless
you
had
a
bunch
of
services
that
all
had
the
same
constructor
signature.
I
This
api
doesn't
really
help
you,
because
this,
what
this
api
is
doing,
is
it's
basically
allowing
you
to
create
factories
that
all
have
the
same
signature
as
part
of
their
creation
routine.
As
soon
as
the
signature
changes
between
types,
these
apis
kind
of
fall
down,
but
again
so
would
creating
a
delegate
to
method
info
like
if,
if
you
have
two
methods
that
don't
have
the
same
signature,
well,
the
delegate
types
for
each
of
them
are
not
going
to
be
compatible.
I
Correct
they
will
still
be
faster.
Yes,.
L
I
B
G
Api,
I
think
the
api
is
fine.
The
only
question
I
have
just
is,
as
I
said,
the
the
relative.
You
know
value
and
priority
of
the
of
activator
stuff
versus
constructor
interest
stuff,
but
I
think
you
can
figure
that
out
outside
of
that
this
meeting
and
we
should
just
approve
them
both
and
let
you
do
that.
H
I
I
L
A
A
K
Sure
I
think
this
should
be
straightforward.
They
we
already
have
three
overloads
of
a
binder.
Oh
sorry,
a
bind,
and
they
are,
they
take
an
object
instance
and
in
basically
the
aim
for
adding
these
three
new
bind
overloads
is
to
rather
than
having
an
object
instance
having
that,
like
generic
type
t,
so
that
they
will
end
up
calling
the
existing
ones,
but
it
will
just
make
my
assumption
is
that
it's
gonna
make
bind
linker
friendly
and
like
yeah.
So
basically
that's
the
whole
story
behind
this.
K
And
like
the
usage
example,
as
you
see
in
the
description
shows,
the
usage
like
the
usage
won't
change,
but
the
new
overloads
will
be
kind
of
called.
Instead,
no,
they
will
be
taken.
They
will
take
precedence.
K
My
assumption
is
that,
no,
I
don't
I
I
don't
see
any
differences
there,
I'm
not
sure
exactly
what
you're
pointing
to,
but
I
think
the
only
advantage
is
that
when
blind
is
called
now
with
these
three
you
know
overloads
any
call
to
configuration,
bind
will
take
precedence,
we'll
use
these
new
apis
instead
and
that's
about
it.
A
So
the
way
I
understand
it
is
basically
you're
saying
like
the
behavior
wants
to
behave
exactly
like
the
other
ones.
The
only
difference
is
that,
because
they
don't
convert
the
instance
to
object.
When
you
look
at
the
resulting
il
that
this
compressed
by
the
compiler
we
preserve
effectively
the
t
right.
That's.
K
Initially,
another
goal
for
having
this
was
to
kind
of
help
with
source
gen,
but
with
some
of
the
comments
that
I
put
down
like
a
little
experimentation
that
I
did
is
doesn't
seem
like
having
these
apis
would
be
necessarily
needed
for
source
gen,
because
yeah
so
like
it's
just
mainly.
The
benefit
is
going
to
be
for
making
finding
linker
friendly
and
that's
about
it.
L
So
so
the
point
I
was
trying
to
get
earlier
is
the
caller
to
bind
who's
passing
in
an
object
generally,
the
il
for
the
call
site
includes
the
type
but
because,
like
how
else
are
you
using
the
instance?
If
you
don't
know
what
the
type
is
but
like
at
that
point,
you're
typically
only
accessing
the
getters
on
the
instance
so,
like
the
question
is
like,
why
does
like
the
existing?
L
But
why
don't
the
existing
bind
methods
work?
If,
like
you
already
have
il
that
you
know,
has
the
instance
at
the
call
site
and
from
talking
to
david
about
this.
I
think
it's
because
the
linker
strips
the
setter,
but
I'm
no
expert
so
like
this
is
a
legitimate
question
like.
Is
that
what
happens.
M
M
A
Yeah
I
mean
what
will
be
helpful.
I
think
in
this
api
review
is
to
actually
annotate
like
actually
add
the
annotations
to
the
api,
to
make
it
clear
what
they
are
for
and
then
my
other
question
is
like.
Is
this
really
what
we
have
to
do
because,
like
this,
it
seems
a
bit
weird
to
me
to
effectively
create
overloads
of
existing
apis?
L
So
I
think
the
linker
knows
that
you're
reading
the
data,
so
it
knows
that
you
need
the
getters.
So
this
is
like
my
understanding,
which
could
be
wrong,
but
like
so,
the
linker
should
already
know
without
any
annotations
that
whose
ever
calling
bind
is
using
the
getters.
But
it
has
no
way
to
know
that
the
setters
are
needed
by
bind
itself.
Yes,.
A
Why
can't
we
do
the
exact
same
thing
on
the
ones
that
take
object
because
clearly
like
if,
if
if
the
compiler
is
always
able
to
infer
the
t,
that
means
at
the
called
side,
I
have
a
strongly
typed
thing
in
my
hand,
I
don't
have
object.
I
have
an
actual
instance
of
type
customer,
let's
say
right
or
customer
configuration
probably,
and
then
I
pass
an
instance
to
that
method.
So
in
il
you
know
that
oh
what's
passed
as
the
third
argument
is
of
type
customer
configuration,
and
so
whatever
customer
attribute.
B
A
On
the
bind,
one
would
apply
to
that
right,
like
that's
to
me
more,
like
a
question
of
how
the
linker
works,
because
it
seems
to
me
a
bit
silly
to
say
every
single
time
you
have
an
object.
We
have
to
create
a
generic
overload.
That
can
always
be
inferred
because
that
kind
of
seems
to
indicate
that
there's
something
fundamentally
wrong
with
the
linker
annotations.
G
L
Yeah,
I
don't
know,
but
yeah
you
would
already
yeah.
I
think
I
get
what
you're
saying,
though,
but
for
now
we
need
this
right
like
unless
we
can
fix
the
linker
or
improve.
L
C
K
Eric
erhardt
also
he's
on
vacation
now,
but
there
was
one
thing
that
he
mentioned,
and
it's
also
in
the
comment
in
this
issue
is
that
there
is
a
little
limitation
already
tracked
by
a
monolinker
issue
1087,
which
has
to
do
with.
I
mean,
as
is
today.
K
A
A
My
only
concern
is
that
if
we,
if
this
is
what
we
have
to
do
to
make
everything
linker
friendly,
that
might
be
a
very
long
chain
of
things
you
would
have
to
add,
and
at
that
point
the
question
really
is
is
is:
is
there
something
in
the
linker
that
we
should
be
doing
instead
or
annotations
every
existing
ones,
to
indicate
that
the
linker
needs
to
do
these
things,
and
so
that
that's
kind
of
the
only
thing
I
would
hinge
it
on
like
if
you
collectively
believe
that's
what
has
to
happen,
and
you
know
it's
a-
I
don't
know
less
than
50
apis
across
the
framework.
A
More
generics,
what
yeah
so
the
so
the
problem
here
is
right
like
so.
If
we,
if
we
say
this
existing
api,
that
we
have,
which
takes
object,
will
basically
immediately
bind
to
these
new
proposed
apis,
because
the
compiler
can
always
implicitly
infer
the
the
t,
then
why
do
we
do
this?
Thinking
of
the
compiler
like?
Why
can't
we
not
do
this
thing
in
the
linker
states.
A
A
L
We
need
to
put
an
attribute
on
the
actual
generic
type
you
missed
the
beginning
of
this
conversation
right
david.
Of
course,
I
just
came
here.
Okay,
I
was
just
making
sure
okay,
I
see
when
you
join
yeah,
we're
we're
aware
that
we
need
the
attribute.
The
question
is:
if
the
com
link
or
compiler
can
infer
that
an
object
is
to
you.
Why
can't
we
just
put
the
attribute
on
object
and
be
like
whatever
type
you
I.
L
L
L
It
would
have
to
track
every
call
to
that
method
and
try
to
find
the
literal
type
where
it
was
newed
up
or
or
or
I
guess
where
the
type
became,
where
it
was
an
object.
Yeah
I
mean
it
already
has
to
do
that
for
the
generic
overload
right
like
to
if
it's
inferred
like,
if
it's
not
explicitly
specified
it's
not
about
inference,
though
right.
This
is
like
in
the
il
linking
happens
after
compilation
when
it's
burnt
into
the
il.
A
Right,
but
I
think
so,
but
I
think
so,
here's
the
scenario
right
so
imagine
you
have
two
methods,
one
method
that
takes
an
object
and
immediately
calls
the
existing
configuration
binder
dot
bind
just
passing
in
the
object.
Yes,
the
link
at
this
point
has
lost,
because
there's
no
way
for
linker
to
know
what
object
is
without
doing
some
crazy
cross
method.
A
L
L
A
Yeah,
it
could
just
be
a
customer
to
be
directly
on
the
bind
method
right
that
says,
you
know
you
know,
parameter
name
whatever
infer
or
something
right
but,
like
I
I
feel
like
like.
I
don't
have
data,
but
it
seems
like
this
pattern
that
we
have
through
the
frame
where
we
just
expect
objects
to
come
from
local
things
is
decently,.
B
L
But
it
sorry,
if
you
have
these
generic
overloads
and
you
do
have
like
a
local
object
like
you,
would
have
to
cast
anyway
to
use
them
and
if
you're
casting,
doesn't
that
you.
L
C
C
A
L
Isn't
that
the
same
issue,
if
you
jason
deserialize
a
dynamic
type
like
that
this,
so
my
issue
is
this-
is
equivalent
to
getting
the
serialized?
I
guess
one
difference,
it
doesn't
actually
take
the
instance
it
in
that
case
the
instance
is
created
internally
and
returned,
but
I
see
this
the
same
as
any
call
to
to
these
three
lines
where
you're
passing
the
t
as
an
argument
versus
passing.
It's
more
like
the.
A
J
A
L
Be
informative,
be
serialized,
but
in
dc
list
you
can
pass
in
an
object
instance.
Today
you
can't
you
you
can
pass
in
a
type
an
object,
but
imagine
we
had
an
overload
that
took
just
object
where
we
we
internally
called
get
type,
and
then
we
filled
the
object
up.
That's
the
equivalent
here.
So
I
guess
we're
asking
for
a
link
feature
for
those
kinds
of
apis
where
you
can
say
like
this
object.
L
A
L
L
L
A
B
A
Like
my
concern
is
that
this
is
such
a
generic
pattern
that
we
may
have
to
add
like
a
butt
load
of
those
right,
and
that
seems
yeah.
L
Yeah,
the
the
only
thing
I
could
think
of
that's
a
little
bit
different
is,
we
could
add,
an
overload
that
didn't
actually
pass
in
the
instance
and
would
return
one
it's
a
bit
simpler.
Just
because
you
don't
actually
have
to
look
at
the
color
you
you
only
care
about
the
t
pass.
Then
the
generic
t
are
type
passed
in
right,
but
that
would
break
the
calling
pattern
today
that
we.
A
L
A
Which
I
think
I'm
also
fine
with,
because
if
the
expectation
is
the
caller,
has
always
an
instance
of
a
particular
type,
then
autogeneric
inference.
It
seems
fine,
it's
more
problematic
for
cases
where
we
to
today
we
have
object
paired
with
type
right,
because
there
very
often
is
no
replacement.
Yes,.
L
A
Today
is
not
good
for
in
terms
of
throughput
seems
like
we
have
a
lot
of
controversial
issues,
all
right,
44738.
H
Okay,
so
there's
a
type
called
x500
distinguished
name,
mostly
people
think
it's
just
a
fancy
string,
but
it's
actually
very
complicated,
complicated.
B
H
The
way
that
you
the
way
that
you
can
build
one
right
now,
aside
from
you,
already
have
the
the
bytes
that
represent
how
it
gets
encoded
is
you
can
build
one
from
a
string,
but
that
what
kevin's
pointing
out
is
people
create
them
with
sort
of
trivial
string,
concatenation
and
then
end
up
accidentally
putting
in
a
comma
and
then
that
changes
the
meaning
of
their
string.
H
And
so
this
is
just
proposing
a
builder
for
the.
I
don't
know
half
dozen
of
us
who
ever
want
to
build
these
things
from
nothing,
and
so
the
api
has
all
of
the
common
fields
that
would
appear
in
a
x,
500,
distinguished
name,
which
is
what's
used
for
the
subject:
name
of
a
certificate
which
is
email
address,
domain
component
which
isn't
really
used
in
search.
H
It's
used
in
active
directory
locality,
which
is
their
word
for
city
common
name,
which
is
what
you
actually
think
of
as
the
subject
country
or
region,
which
is
a
two
letter
code
organization,
name,
organizational
units,
state
or
province.
These
are
all
just.
If
you
see
a
certificate
subject,
it'll
say
things
like
you
know:
cn
equal
www.github.com
I'll.
Just
look
at
one
and
then
it'll
have
like
you
know:
s
is
something
where's
view
the
certificate
certificate.
H
Yes,
so
cnequalgithub.com
o,
which
is
organization,
equal,
github,
inc,
l,
which
is
locality
san
francisco
s,
which
is
fader
province.
California
c,
which
is
country
u.s.
That's
github's,
current
certificate
subject.
So
this
lets
you
build
all
those
without
accidentally
having
commas
that
change
your
meaning,
like
in
github,
comma
inc,.
G
I
was
going
to
say:
do
I
ever
have
a
similar
issue
on
the
other
side,
meaning
I
want
to
I
get
one
of
these.
I
want
to
parse
it
and
break.
H
G
Yep,
it
seems
like.
Maybe
it
would
be
useful
to
have
a
class
that
lets
you
do
both.
H
Maybe
they
are
different,
x500
distinguished
name
yeah
right
now.
It
really
only
gives
you
the
it's
good
for
string
to
bytes
sort
of
and
bytes
to
string,
which
is
actually
pretty
good
at.
H
There
are
some
other
proposals
that
haven't
been
worked
out
yet
of
what's
the
best
way
of
querying
sub-information
out
of
that
to
get
essentially
the
component
fields
instead
of
needing
to
parse
it
yourself,
but
that's
a
different
than
being
able
to
build
one,
the
one
type
to
build
them
both
wouldn't
have
the
same
semantics.
H
Well,
this
would
actually
be
building
it
using.
So
this
is
one
of
the
asn
encoded
things,
and
each
of
these
is
a
encoded
segment
that
gets
concatenated
together
and
but
yeah
you
can
think
of
it
as
a
glorified
string
builder.
D
Yeah,
okay,
would
someone
ever
want
to
call
this
in
a
more?
What
is
it
called
fluent
like
if
we
change
the
return
type
to
the
builder,
so
you
could
just
chain
a
bunch
of
dot
at
email,
dot,
add
domain
component.
I
A
Yeah,
I
think
part
of
the
reason
is
because
you
want
to
avoid
the
repeated
the
repetitiveness
of
as
beginning
right,
you
can
just
say,
dot
dot,
dot,
which
yeah
I
feel
strongly
that
we
shouldn't
have,
but
I
think
that
was
done
before.
I
think
we
should
not
do
it
now.
I
think
to
me
that
would
be
a
bad
idea.
A
Because
to
me,
the
problem
with
fluidity
is
that
I
think
fluidity
in
and
of
itself,
I
think,
adds
tremendous
amount
of
value
when
the
shape
of
things
differ,
and
you
can
actually,
you
know,
guide
people
in
intellisense
by
returning
different
types,
but
I
feel
like
for
for
things
like
this
like.
Why
would
you
do
that?
To
me?
It's
also
borderline
lying,
because
you
kind
of
imply
that
you
get.
You
basically
hindered
an
immutability
that
doesn't
exist
right,
because
if
I
snapshot
the
intermediary
results,
they
all
point
to
the
same
object.
A
I
I
think
yeah,
the
the
conversation
was
contrasting
stream
builder
against,
like
the
configuration
builder
system,
and
the
response
was
that
the
configuration
builder
system
can
actually
give
you
back
substitute
objects
if
it
really
needs
to
that,
you
can
then
chain
future
operations
off
of,
whereas
stringbuilder
is
literally
contracted
to
always
return
this,
as
would
this,
and
at
that
point,
if
it's
always
contracted
to
do
that,
like
what
was
the
point.
H
Yeah,
so
I
mean
I'm
not
a
fan
of
fluent
personally,
so
I
have.
I
will
not
ask
for
fluent.
I
don't
actually
hate
it
enough
that
if
we
felt
that
there
was
a
precedent
to
do
it
that
I
would
object,
but
I
think
that
that
I
would
have
preferred
that
stringbuilder
wasn't
fluent.
L
A
Yeah
yeah,
I
think-
and
I
think
the
only
thing
I
would
exempt
from
this
is
like
I
think
anything
that
has
the
name
builder
in
it
like
there's
such
a
pervasiveness
for
for
fluidity,
that
I
think
it's
probably
fine,
but
outside
of
things
that
are
not
named
builder,
I
would
be
very
hesitant
because
then
I
think
you
clearly
have
snapshot
semantics
in
mind.
I
mean
builder,
you
kind
of
hinted
this.
This
is
a
something
that
is
mutable
right,
so
I
can
go
either
way
on
those,
but
but
I
feel
like
it
yeah
it.
I
The
the
builder
apis
in
in
system.reflection.emit
don't
they're,
not
fluent,
and
immutable
collections.
Builders
aren't
fluent.
I
I
H
I
mean
because
it's
a
it's
a
build
or
because
it's
a
builder
and
we
have
the
same
thing
with
subject:
alternative
name
builder:
it's
you
can
throw
a
bunch
of
stuff
in
and
then
it
it
produces
an
output.
And
then
you
could
read
the
things
off
the
output,
not
really
in
the
case
of
subject,
alternative
name
builder,
but
that's
a
different
problem:
oh
you're,
right,
yeah,
yeah
and
so
from
here.
H
It's
yeah,
x59,
distinguished
name,
is
the
thing
that
should
really
that
we
should
work
on
being
able
to
get
the
data
back
out
of
it.
But
for
well.
You
know:
we've
added
the
certificate
creation
apis
and
as
more
things
start
using
that,
for
you
know,
generating
on-the-fly
search
for
either
test
purposes
or
doing
little
micro
pki
the
possibility
that
they
end
up
with.
H
Oh,
I
wrote
this
thing
that
you
know
expected
the
organization
name
and
I
never
tested
with
a
comma
in
it,
and
I
put
a
comma
in
and
now
it
throws
and
like.
Oh,
how
do
I
fix
that?
Oh
well,
I
need
to
go
back
and
turn
on
quoted
string,
support
in
the
in
the
x,
509
or
x,
500
distinguished
name
building
and
then
go
wrap
everything
with
quotes
and
like
well
now
what
if
the
thing
has
quotes
in
it
that
changes
the
quote
style
you
have
to
use,
and
this
just
solves
all
those
problems.
I
Yeah
yeah,
so
this,
if
you,
if
you
also
in
the
future,
made
reading
data
off
of
x,
500
distinguished
name
easier,
then
I
think
that
would
complement
this
very
nicely.
H
H
I
A
I
A
H
Yeah-
really
it
just
comes
down
to
if
they
thought
that
they
were
going
to
build
it
with
a
slice
instead
of
a
substring
like
if
they
were
building
it
based
off
something
else,
and
that
was
my
only
thought.
A
H
I
I
Because
one
of
one
of
the
other
ways
that
I
was
looking
at
it
is,
I
think
it
was
yawn
and
steve
tobe
had
asked
in
the
past,
like
as
we
were
working
on
the
utf-8
stuff,
would
we
add,
overloads
for
read-only
span
of
byte
or
utf-8
string
or
whatever
to
these
apis?
For
this
the
answer
would
be
no,
and
if
the
answer
here
is
no,
then
I'd
probably
say
rise
of
chars
also
yeah.
H
H
Overloading
it
seems
better
than
only
taking
byte
array,
because
if
you
were
building
one
of
these
yourself,
it
at
least
stops
you
from
having
to
create
just
the
temporary
array.
Just
to
call
this
method.
I
A
Yeah,
I
mean
that's
all
I
had
anyway.
So
then
we
probably
don't
have
quorum
for
the
rest
of
the
year,
so
that's
probably
it
for
now
so
next
year
we
probably
have
to
pick
ourselves
up
a
little
bit,
because
we
only
did
four
issues
today.
G
H
A
Can
you
pl?
The
only
thing
I
might
demand
is
that
yeah,
we
can
add,
underscores
please,
please
dance
the
api
review
all
right
guys!
That's
enough,
then,
for
today
see
you
next
week
next
year.
Sorry.
H
Yeah,
so
were
you
overloading
the
ad
encoded
or
just
leaving
him
as
we
don't
spend
a
bite.
A
I
did
add
the
I
thought
I
added
the
overloads.