►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
All
right
so
now
we're
live
so
today
we'll
talk
about
two
issues:
one
is
a
data
type
that
our
friends
and
the
other
sdk
have
built,
and
they
would
like
to
put
this
into
the
bcl.
So
I
let
christoph
talk
to
that
and
then
the
second
one
is
tenors,
adding
more
half
methods
which
should
hopefully
be
fast.
B
A
B
B
All
right,
so,
okay,
so
let
me
kind
of
a
bit
of
a
history,
so
we
have
lots
of
apis
in
in
the
azure
sdk
that
basically
move
data
between
the
client
machine
and
azure.
B
So
you
know:
there's
storage
apis
where
you
can
literally
that's
all
they
do
they
store.
You
know
binary
data
in
blobs,
for
example,
there
are
various
messaging
apis.
Where
messages
usually
are
you
know
either
text
or
json.
But
fundamentally
you
know
the
protocol
moves
bytes
around
and
so
so
far
we've
been
designing
these
apis
by
taking
either
read-only
memory
of
bytes
or
byte
arrays,
and
returning
read-only
memory
of
bytes
or
byte
arrays.
B
It's
not
like
it's
a
complete
blocker
for
them,
but
it
takes
them.
You
know
a
bit
of
time
to
figure
out.
I
want
to
store,
let's
say,
a
string
in
the
blob
storage.
What
do
I
do?
How
do
I
convert
a
string
to
bytes?
I
want
to
store
an
object,
just
serialize
it.
How
do
I
serialize
it
and,
as
I
mentioned,
it's
not
a
complete
blocker
for
them,
but
there's
a
lot
of
ceremony
around
converting
strings
to
bites
and
on
the
way
you
know
out
bytes
to
strings
even
more
with
serializable
objects.
B
So
you
need
to
somehow
get
an
instance
of
a
serializer.
Then
you
need
to
you,
know
serialize.
Then
the
users
are
thinking.
Do
I
need
to
delete
the
serializer
store
it
in
a
static?
Is
it
thread
safe,
and
there
are
so
many
of
these
questions
that
they
have
so
something
that
should
be
super
simple,
like
storing
a
string
in
a
blob
storage.
You
know
takes
a
disproportionately
longer
time,
so
we
came
up
with
this
idea
of
adding
this
type
called
binary
data.
An
email
has
it
on
the
screen.
B
B
So
anyway,
yeah
I
wanted
to
kind
of
the
whole
type
show
up
on
the
screen,
but
so
we
designed
this
type
and
we've
had
it
for
some
time
in
the
prototype
stage
and
over
time
it
got
kind
of
better
and
better.
We
run
usability
studies
on
it,
both
as
a
standalone
type
and
in
the
context
of
some
services,
and
we
made
some
tweaks
and
the
most
recent
usability
studies
were
super
positive.
B
B
What
we
would
see
in
usability
studies
people
would
be
okay,
I
have
an
object.
I
need
to
serialize
it
and
I
need
to
pass
byte
array
or
even
worse,
let's
say
the
input
apis
take
a
stream
which
actually
for
storage,
they
take
a
stream
that
a
byte
array
and
suddenly
the
user
kind
of
needs
to
figure
out
how
to
instantiate
memory
stream,
wrap
it
around.
B
B
All
these
problems
went
away.
Basically,
users
seen
a
signature
type
binary
data
and,
as
you
know,
the
first
thing
that
they
will
try
to
do
is
instantiate
binary
data.
So
they
kind
of
new
up
binary
data.
They
notice
constructors.
They
look
through
the
you
know,
options
that
the
constructor
offers
and
they
see
that
it
takes
json
serializable
object.
Okay,
great,
so
they
just
pass
the
object
that
they
have.
B
We
serialize
it
to
json,
store
it
in
a
byte
array
and
then,
when
it
gets
passed
to
storage
apis,
we
just
send
the
byte
array
across
the
wire
and
similarly
on
the
output.
So
in
apis
that
don't
use
binary
data,
we
would
return,
let's
say
read-only
memory
of
byte
to
users,
and
that
is
still
very
confusing
you.
You
also
probably
realize
not.
B
Many
people
understand
the
new
memory
primitives,
but
even
if
we
return
a
byte
array,
people
still
have
problems
because
again
they
have
to
instantiate
the
serializer
or
know
how
to
use
encodings
people
get
confused.
Why
we
have
both
encoding
and
and
encoder
and
which
one
is
which
for
us
it's.
You
know
super
kind
of
natural
because
we've
been
you
know,
we
work
on
these
apis,
but
a
lot
of
people
still
get
confused.
How
to
convert
bytes
to
strings.
B
B
So,
as
I
said,
we
run
usability
studies
and
literally
they
were
you
know,
night
and
day
from
the
previous
studies.
Without
this
type,
we
got
a
lot
of
good
feedback.
Users
were
asking
us
when
this
type
gonna
be
available,
and
then
we
started
to
have
a
discussion.
You
know,
as
I
mentioned,
should
we
ship
it
in
the
vcl,
thus
that
the
discussion
that
we
have
today,
of
course
it
would
need
some
modifications.
B
B
B
Properties
is
a
bit
harder
when
the
return
type
would
have
to
change,
but
we
would
add
a
property
with
you
know,
suboptimal
name
and
then
a
couple
of
months
later
at
the
property.
With
the
you
know,
appealing
name.
E
A
Besides
the
thing
that
it's
sorry
like
there's,
some
echo
so
like,
besides
the
thing
that
it's
obviously
the
right
thing
to
do,
the
question
is:
what
benefit
would
it
give
users
if
this
thing,
ships
in
the
bcl.
B
Yeah,
so
I
I
think
that
the
main
benefit
is
that
if
a
type
is
in
a
in
the
bcl,
it
can
be
used
in
other
third-party
libraries.
So
think
about.
You
know
azure
sdk
as
a
third-party
library,
and
it
would
make
third
la
party
libraries
better
and
easier
to
understand,
because
you
know
people
would
over
time
learn,
there's
distinct
binary
data
and
whether
they
are
looking
for
you
know
apis
in
azure,
sdk
or
in
asp.net.
Frankly,
not
not
only
third-party
libraries,
but
you
know
in
asp.net
or
other
libraries.
B
You
will
have
this
type
and-
and
you
know
it
feels
very
natural
if
it
ships
in
azure
sdk
only
you
know
either
asp.net
wouldn't
have
a
type
like
that
or
it
would
have
a
different
type
which
potentially
could
be
introduced.
Confusion.
So
I
think
that's
the
main
benefit,
because
I
don't
think
we
can
take
this
type
low
enough
to
actually
use
it
in
inside
bcl
apis.
B
So
well,
I
don't
know
if
you
consider
now
asp.net
api's
bcl,
but
it
could
be
used
above
system
text
json,
but
not
below.
C
We
we
now
have
this
wart
of
jason
in
the
middle
of
a
very
essentially.
This
is
introducing
a
new
lowest
level
type
or
it's
not
a
rough
structure,
so
just
above
span,
yeah
and
so
I'd
be
concerned
about
the
to
and
from
object
the
to
and
from
string
feel
like
they
do
need
to
support
custom
encoding
and
the
stream
or
wrapping
a
stream
seems
very
weird,
because
this
is
all
synchronous
like
the
the
synchronous
two
array.
C
But
you
don't
know
if
you
had
a
stream
at
which
point
you
may
need
to
be
async,
otherwise
you're
introducing
sync
over
async.
So
this
it,
my
quick
glance
here
feels
that
this
just
it
makes
a
lot
of
api
simple,
but
the
way
that
it
makes
it
simple
is
by
bringing
back
a
lot
of
problems
that
we
try
and
avoid
having.
B
Well,
so
let
me
go
one
by
one.
I
think
this
utilization
issue
that
you
brought
up.
B
We
would
solve
it
by
adding
an
overload.
So
we
today
today
we
have
this
overload
that
takes
object,
serializer
and
it
controls
the
serialization
logic.
So,
in
fact
I
was
saying
this
is
to
select
serializer
between
you
know,
system,
text,
json
and
other
serializers.
It
doesn't
even
mean
you
know
other
json
serializers
because
object
serializer
just
has
a
method,
you
know
serialized,
so
that
is
currently
the
way
to
you
know
control
what
serialization
technology
you're
choosing
and
if
your
concern
is
but
there's
json
system
text
json.
That
is
the
default.
B
I
would
say
trying
to
avoid
defaults
too
hard,
because
you
know
in
several
years
they
may
change.
I
don't
know
if
that's
that's,
that's
a
good
way
to
trade
off
usability
betw
between
usability
and
kind
of
you
know
future
proofing.
I
agree
with
you
that
if
it
was
a
you
know,
potential
word
going
forward,
then.
Yes,
it's
a
much
bigger
concern,
but
just
having
default
be
different
in
the
future
than
what
you
know
would
be
an
expectation.
C
Well,
because
this
is
feels
like
it's
used
for
data
persistence,
which
means
you
need
whatever
a
default
to
object
does
and
a
default
from
object.
They
need
to
do
the
same
thing
and
that
needs
to
do
the
same
thing
across
versions.
So
I
think
that
once
we
have
a
default,
it
can't
ever
change,
because
it's
for
data
persistence,
it's
not
just
in
proc.
B
Yeah,
that's
what
I
was
saying
so,
but
I
would
not
avoid
having
defaults,
because
they,
you
know
that
potentially
the
expectation
of
what
the
default
is
can
change
in
the
future.
Otherwise,
you
you're
basically
designing
apis
that
have
more
and
more
parameters
because,
you're
being
you
know,
super
scared
of
of
choosing
a
default
that
will
not
last
forever.
C
I
mean
I
like
the
notion
of
taking
of
simplifying
something
of
here.
I
I'm
some
binary
data
we're
going
to
deserialize
it.
We've
made
some
level
of
a
very,
very
simplified.
C
I
guess
at
this
point
it
would
have
to
be
an
interface
for
serialization
of
or
it
would
just
be.
A
wrapper
type
of
here
are
some
bytes,
give
me
an
object
and
if
it
required
configuration
you,
you
had
to
have
done
that
on
the
instance
already
or
the
instance
that
you
gave
to
the
wrapper
and,
and
that
totally
makes
sense
to
me
and
then
that
we
would
need
some
good
singleton
somewhere.
C
So
someone
could
say
from
object,
you
know
default
json
or
or
whatever,
and
but
then
it
says
in
their
code
and
they
know
that
they're
dealing
with
json
as
their
persistent
format
instead
of
in
three
years.
Protobuf
compact
format
is
the
de
facto
standard
and
somebody's
looking
at
something
and
like
well.
Why
can't
I
read
this
payload,
oh
because
you're
reading
default
and
we
wrote
it
protobuf.
C
D
D
D
It
was
still
xml
yeah.
No,
it
could
do
jason
as
well.
D
B
Technique
but
anyway,
so
you
know,
maybe
it
will
change
in
five
years
or
maybe
in
three.
The
thing
is
that
I'm
still
not
understanding
is
the
concern
that
there
is
no
way
to
switch
the
serializers,
which
I'm
saying
there
is
or
or
you
know
we
can
add,
or
that
there
is
a
default.
Those
are
two
separate
concerns
and
I
don't
understand
which
one
is
the.
E
C
Serializer
that
that's
going
to
be
a
minimum
requirement
and
then
but
then
I
feel
that
it's
going
to
be
one
of
those
in
a
few
years,
whether
it
be
you
know
three
or
five
or
twenty
we're
going
to
be
like.
Why
do
we
have
this
thing
that
defaults
to
jason?
It's
such
old,
broken
tech,
and
now
we
can't
like
drop
it
out
of
the
standard
reference
set
because,
like
we
can't
move
it
to
optional,
because
we
need
this
because
it's
the
default
and.
C
Yeah
and
we'll-
and
we
never
oh
yeah-
that's
true.
It
would
also
require
moving
jason
super
far
down
because
oh.
B
C
Right
absolutely
default
serializer
it
could
go
lower
and
somebody
at
a
higher
level
just
says
I
made
a
an
I
serializer
out
of
system
text
json
and
I'm
throwing
it
at
binary
data
and
go
and
so
you've
decoupled
the
technology.
It
only
depended
on
an
interface
or
an
abstract,
based
class
that
we
throw
somewhere
download
that
had
no
notion
of
what
data
looks
like
it.
Just
has
a
you,
give
me
a
t
and
a
some
form
of
data,
and
I
produce
an
object.
B
Yeah,
so
I
would
say
so
again:
there
is,
I
think,
now
three
issues.
Let
me
answer
this,
the
second
one,
the
the
one
that
you
were
saying
that
in
the
future
you
know
the
default
will
not
be
what
what
people
expect.
B
I
see
it
as
you
know
the
perfect
becoming
enemy
of
the
good,
because
there's
no
solution
to
this
problem.
Basically,
if
you
say
we
are
afraid
to
add
to
have
a
default
serial
serialization
format,
because
it
may
change
in
the
future,
then
it
means
serialization
format
cannot
be
defaulted
and
that,
in
turn
means
that
the
apis
are
not
simple,
because
you
have
to
keep
passing
some
in
implementation
of
some
abstractions
or
you
know
which,
which
literally,
is
a
very,
very
severe
usability
issue.
B
Whenever
users
see
an
abstraction
in
a
in
as
a
parameter,
they
don't
know
what
subtypes
implement
the
abstraction
they
potentially
can
be.
Even
in
different.
You
know
assemblies
or
new
get
packages,
so
I
think
again,
having
defaulted
serialization
format
gives
you
gives
you
the
usability
that
this
type
is
designed
for
and
yes,
in
five
years
it
may
not
be
the
most
expense
expected
use.
You
know
serialization
format,
but
as
long
as
we
have
a
way
to
switch,
I
think
it's
it's.
You
know
it's
a
good
trade-off.
Sure.
B
D
B
B
Yeah,
so
as
I
was
saying,
I
think
that
this
type
is
for
basically
things
above
the
pcl,
it's
for
asp.net
for
azure,
core
and
other
libraries
that
build
on
top
of
that
net.
It's
kind
of
similar.
Recently
I
you
know,
we've
been
working
on,
I
I
didn't
participate
much,
but
you
guys
have
been
working
on
the
helpers
for
http
client
that
do
similar
things
automatically,
and
you
know
those
are
higher
level
libraries
and
they
do
default
to
system
text
json
serialization.
B
C
B
A
So
my
only
concern
is
like
I
mean
I
completely
buy
the
default
argument.
The
only
concern
I
have
is
that
it
seems
a
bit
weird
to
say
we
don't
want
to
pay
the
price
for
some
sort
of
switch,
that
you
can
pass
to
the
constructor
to
construct
the
type
and
simultaneously
say
that
like
well.
If
you
ever
change
the
serialization
technology,
then
we
will
add
the
switch,
because
I
think
the
question
isn't
so
much
whether
we
will
need
to
do
this.
A
You
know,
switch
to
rule
sealizer
that
we
added
in
dotnet
seven,
and
so
then
the
question
becomes
like
okay.
At
that
point,
we
will
have
to
pay
the
price
for
having
that
or
live
with
the
fact
that
this
type
just
doesn't
support
the
civilization
format
at
all,
and
do
you
think
that
would
be
acceptable,
or
do
you
think
that
then
we
just
have
to
take
it.
You
know
breaking
change
and
actually
change
the
serializer.
B
So
again
you
you
said
that
we
wouldn't
be
able
to
support
this
other
format
and.
A
Well,
I
mean
it's:
basically,
we
have
two
options.
We
can
either
say
the
constructors
or
factory
methods
that
do
serialization
on
your
behalf,
take
some
sort
of
object
or
not
object,
but
some
sort
of
switch
that
allows
you
to
say
use
the
serializer
or
we
are
saying
no,
it's
always
hard
about
it
to
system
text.json
like
these
are
really.
B
So
this
is
like
we're
discussing
this.
Like
I
don't
know,
maybe
I'm
not
explaining
it
well.
Today
we
would
default
to
system
tax
json
in
the
future.
We
of
course
have
an
option
to
support
other
serializers.
A
B
A
And
so
I'm
saying
I'm
a
bit
concerned.
If
we
say
okay,
we
need
to
have
system
text.json
as
the
default,
but
we're
also
kind
of
acknowledging
that
probably
it's
not
going
to
be
the
right
default
forever
right,
and
so
that
question
then
becomes
one
system.
Text.Json
is
no
longer.
You
know
the
new
sign
thing
on
the
block,
then
what
are
we
doing
with
the
people
that
are
not
able
to?
I
guess
pick
the
right
overload.
B
B
So
that's
issue
number
one:
can
we
support
new
serialization
technologies
in
the
future,
and
I
assert
yes-
and
I
hope
everybody
agrees
that
it's
yes,
the
second
question
is
you
know:
is
it
weird
that
in
five
years
the
default
will
be
not
what
people
prefer
right
and
to
that
one
I
would
say
I
would
have
to
end
like
they
are
not
like.
You
know,
mathematically
provable,
but
I
would
say-
and
they
are
more
like
you
know,
opinions
or
traders.
B
I
would
say
one
I,
I
suspect
json
will
last
longer
than
you
know,
the
three
or
five
years.
So
that's
that's
one
thing,
but
at
some
point
maybe
you
know
in
more
than
three
years
it
will.
You
know
there
will
be
a
new
technology
and
people
will
want
to
use
it,
and
at
that
point,
when
we
have
the
enum,
you
know
passing
additional
enum
values,
saying
I
don't
want
this
serialization
and
what
I
want
some
other
one.
It's
not
a
big
deal.
B
Also,
having
I
think,
having
types
be
simpler
when
you
ship
them
for
the
first
time
is
more
important
than
longer
term
so
when,
whenever
a
new
type
or
like
an
exchange
type
is
introduced,
I
feel
like
it's
better
for
it
to
be
super
simple
and
then
add
features
as
we
go
as
people
kind
of
learn.
What
this
type
is
about
from
very
simple
view
like
this
one
and
over
time
it
grows,
and
it's
you
know.
Sometimes
it's
not
ideal,
but
it's
not
such
a
big
deal
as
shipping
from
the
get-go
something
more
complicated.
B
B
B
D
I
don't
know
if
I
would
want
to
say
that
this
is
like
a
base
exchange
type
if
it's
so
opinionated,
that
it
uses
system
text
json
with
a
very
particular
set
of
configuration,
but
it's
if,
if
we,
if
we
said
like
that
this
is
a-
and
I
think
you
had-
I
think
you
had
said
this
earlier-
but
please
correct
me
if
I'm
wrong,
if
we
say
that
this
is
a
a
type
that
allows
more
easy
usage
of
things
like
system
text
json
alongside
a
bunch
of
other
primitives,
but
it
itself
was
not
a
basic
exchange
type.
D
I
think
that
might
be
an
easier
pill
to
swallow,
because
I
think
when
we
hear
basic
exchange
type,
we
think
like
core
bcl.
We
start
plumbing
this
absolutely
everywhere
in
the
framework.
A
Well,
so
it
wouldn't
be
an
exchange
type
in
the
bcl
right.
So
that's
the
other
thing
I
just
I
discussed
with
frister
right
so
the
way
I
see
this
type
is
it's
more
like
a
holder
for
a
byte
array
and
then
convenience
methods
to
do
conversions
right.
That's
really
what
it
is.
It
basically
ties
all
the
ways
you
can
represent
binary
data
and
provides
to
and
from
methods
effectively
on
it
right,
and
so
it
would
be
an
exchange
type
above
the
bcl
right.
A
A
That's
really
what
it
is,
and,
yes,
it
has
a
cost
as
well.
So
I
wouldn't,
for
example,
actually
expect
low
level
things
that
need
to
be
super
fast
to
use
this
type
either
right.
For
example,
if
you
take
kestrel,
given
that
most
of
these
conversions
actually
involve
copying
data,
it
is
not
super
cheap
right,
but
that's
the
that's
the
price
you
pay
for
having
a
unified
representation
that
people
can
easily
reason
about
right,
but
it
would
unblock
large
chunks
of
things
where
performance
isn't
the
higher
order
bit
and
people
just
struggle
with.
D
A
But
basically
my
point
is
like
because
we
have
these
conversions.
We
also
don't
have
to
right.
So
like
there's
some
things
we
could
do.
The
type
doesn't
do
that
today.
I
guess
similar
for
the
reason
why
we
don't
have
a
implicit
conversion
from
the
only
member
of
bytes
read
only
span
of
mind,
but
we
could
have
implicit
conversions
to
byte
array.
A
You
know
read
only
span
off
by
read
only
memory
of
buy
it
right,
and
so
you
could
basically
pass
this
api
to
anything
in
the
bcl
that
does
take
bytes
and
that's
probably
good
enough
to
for
it
to
act
as
an
effective
exchange
type
above
the
bcl.
B
Yeah
yeah,
so
let
me
because
I
need
to
actually
leave
at
11,
but
so
let
me
go
to
the
second
issue
that
jeremy
raised,
which
is
two
string
and
from
string,
should
take
encodings.
So
we
explore
that
and
we,
I
don't
think
anybody
has
fundamental
problem
with
this.
If
this
is
something
that
is
super
important
for
the
bcl
team,
I
you
know,
I
don't
think
we
have
a
fundamental
problem.
B
C
B
But
yeah
I
mean
you
know
I,
but
the
implication
is
that
it
does
complicate
the
object
model,
because
you
you,
you
know
you
say
new
binary
data
and
suddenly,
instead
of
five
constructors
or
six,
you
have
now
seven.
B
D
B
D
C
Fair
enough
and
yeah,
I
think
the
sync
over
async.
I
think
I
understand
more.
The
model
now,
which
is
all
of
the
from
methods
slash
the
constructors,
are
data
syncs
they're,
not
it's
not
holding
the
stream
reference.
So
it's
going
to
drain
the
stream
as
soon
as
you
call
it,
so
you
called
from
stream
or
from
stream
async,
and
then
you
you
dealt
with
it
at
at
the
building
time
so
effectively.
This
is
just
using
a
bite
or
it's
turning
everything
effectively
into
a
byte
array
right.
B
B
C
I
was
concerned
that
this
was
basically
just
being
a
union
type
with
delayed
processing
and
therefore
that
two
bytes
was
where
the
stream
was
going
to
be
red.
But
if
it's,
if
all
the
froms
are
data
syncs,
then
then
that
makes
more
sense.
I
mean
it
is
it's
a
little
sad
that
I,
that
string
is
going
to
take
whatever
data?
C
C
Yeah
the
yeah
as
far
as
the
serializer,
I
don't
I
mean
we'll
see
how
it
gets
there
when
we
get
there.
But
if
it's
at
all
in
the
shared
runtime,
I
don't
think
an
enum
will
happen
because
the
the
trimming
can't
trim
out
if
you
do
a
switch
on
an
enum.
So
you
know
steve
would
say
to
jason
and
from
jason
should
be
one
method
and
two
protobuf
would
be
another
method.
C
And
then
you
have
the
one
that
that
takes
the
you
give
me
an
object,
and
that
told
me
what
we're
going
to
keep
in
for
the
trimming,
but
they
wouldn't
want
the
the
switch
off
of
an
enum,
because
that
means
that
all
of
those
possible
code
paths
have
to
stay
in
once.
You've
called
that
overload.
B
Yeah,
so
the
this
is
possibly
the
reason
why
I
think
this
is
not
a
you
know,
system
runtime
type,
because
it
basically
would
result
in
yet
another
low
level
type.
That
is
not
super
usable
that
represents
bytes
and
we
already
have
those
in
the
very
core
bcl.
What
we
don't
have
is
this
type
that
basically
provides.
C
B
We
don't
yet
know
well,
there
is
an
issue
of
you
know:
are
the
inputs
or
outputs
so,
of
course,
if
they
are
outputs
like
we
are
designing
now
a
service
bus
library
that
is
close
to
shipping
and
outputs
are
only
binary
data
and
inputs.
B
C
I'm
you
know
just
trying
to
think
ahead
of
what
if
this
gets
added
in
the
middle
right.
So
let's
say
it's
the
first
thing
on
top
of
what
we
classically
think
of
as
the
bcl,
and
so
now
you
have
high
level
things.
Take
this
thing
called
binary
data
people
understand
they
get
a
binary
data
and
whatnot,
and
then
they
need
to
move
and
do
something
with
cryptography
and
now,
all
of
a
sudden,
they
need
to
go
back
and
understand,
span
and
memory
and
and
byte
arrays
and
streams.
C
And
what
are
the
implications
of
all
these
various
different
things
and
at
what
level
like?
Should
they
have
even
skipped
the
binary
data
and
passed
the
stream
directly
into
the
crypto
things?
Because
there's
an
overload
for
that,
and
maybe
it
makes
sense
right.
So
it
just
feels
that
it's
making
this
weird,
like
I
didn't
turn
my
camera
on.
Yet
I'm
gesturing
to
it.
D
A
A
I
think
it's
by
the
way
today,
but
I
guess
the
question
really
becomes
like
I
think
to
me.
That
would
be
the
desired
outcome
that
this
thing
has
implicit
conversions
to
the
most
important
things.
The
problem
with
those
is
that
people
have
to
know
that
they
exist
right.
A
So
we
still
have
this
problem
that,
if
you
call
let's
say
stream.write
that
takes
you
know
everything
but
binary
data
that
you
have
to
basically
know
that
you
can
pass
that
thing
in
right,
but
to
me
that's
kind
of
the
value
of
adding
into
the
bcl,
because
we
can
actually
blog
about
it
and
make
sure
people
are
aware
of
that
type
and
basically
raise
it
as
a
this
is
the
way
you
should
design
high-level
apis
and
then
I
think
it's
also
okay,
if
high-level
apis
don't
take,
you
know,
span
and
bite
all
the
other
ones
and
they
they.
B
Yeah
yeah
so
yeah
exactly
I
you
know
I
was
about
to
answer
jeremy's
concerned
and
I
would
say
I
think,
trying
to
teach
everybody
how
to
use
span
of
bites
is
a
basically
a
you
know
a
bit
of
futile
effort,
and
you
know
it's
great,
that
our
low
level
apis
use
span
and
and
rom,
but
it's
fine,
I
believe,
for
people
who
integrate
those
two
layers
to
basically
fish
out
rom
or
span
from
from
binary
data,
and
you
know
trying
to
basically
you
know:
teach
people,
no
we're
gonna,
teach
you
how
to
use
spam
in
the
rom
by
not
providing
helpers,
so
go
ahead
and
you
know
learn
it.
C
That's
my
concern
of
having
this
as
too
high
of
a
level
that
there's
essentially
shearing
of
people
who
only
understand
high
level
and
then
they
they
can't
go
below
this
line.
Has
your
did
the
usability
studies
you
do
involve
also
needing
to
take
one
of
these
and
send
them
to
existing
bcl
apis
that
don't
take
binary
data.
B
Correct
and
basically
what
people
do
is
either
call
so
to
stream
was
very
popular
for
the
integration
point,
and
then
there
were
some
where
they
actually
required
people
to
understand
read-only
memory
and
how
to
integrate
that,
with
you
know,
array
apis
with
spam,
apis
other
apis
and
then.
B
So
you
know
people
keep
continuing,
continue
being
surprised
that
you
know,
read-only
memory
doesn't
have
an
indexer
and
some
issues
like
this,
but
it
wasn't
complete
blocker
but,
as
I
said,
we
we're
not
going
to
solve
this
problem.
These
two
types,
roman
span
will
forever
be
a
bit
exotic.
I
think
to
half
of
our
developer
base.
B
C
So
yeah,
so
if
we,
if
we
think
it
can
be
successful
as
a
top
of
the
bcl
or
bottom
or
I'll
go,
a
top
depends
on
which
way
you
draw
your
diagram,
then
looking
like,
I
do
wonder
if
we
would
still
want
to
take
the
from
object
that
takes
that
assumes
jason
and
just
go
ahead
and
call
it
from
jason.
And
so
it's
just
like
straightforward
telling
you
what
it's
doing.
D
C
Fair
enough,
because
yes,
it's
from
an
object,
so
then
I'd
have
to
be
called
from
object
to
jason,
which
is
wordy
but
yeah
I
mean
I
guess.
If
it's
a
if
it's
a
high
enough
level
type
and
people
say
it
doesn't
trim.
Well,
then
we'd
shrug
and
say
then
don't
use
it
yeah
or
at
least
that
if
those
methods
don't
trim
well,
we
drug
and
say
don't
use
them.
C
But
I
do
I
do
expect
that
there
would
end
up
being
just
trying
to
think
forward
of
how
we
would
do
it.
I
I
think
that
it
would
be
like
well.
If
I
want
to
do
jason,
I
don't
end
up
needing
this
or
when
I
trim
it
drops
out
protobuf
and
bison
and
sibor,
but
the
moment
that
I
want
to
do
sebor.
It
now
pulls
all
of
them
in.
C
B
A
I
mean
that
was
my
question
yesterday
to
you,
like
I
mean
imagine,
we
would
not
have
any
constructors
and
everything
would
be
factories.
The
nice
thing,
then,
is
also.
We
can
name
things
so
that's
kind
of
more
amenable
for
extensibility,
so
that
still
doesn't
buy
us
of
course
static
extensions.
But
you
know
we
could
imagine,
although
it
would
have
static
extensions
and
then
having
static
factories
would
basically
allow
us
to
push
this
type
further
down.
B
It
basically
blocks
them
for
literally
10-15
minutes
trying
to
search
around
how
to
instantiate
this
type
and
especially
that
it's
extract,
so
it
has
the
default
constructor.
So
let's
say
there
are
no
constructors,
they
find
the
constructor,
they
instantiate
it,
and
now
they
are
like
okay.
How
do
I
put
data
inside
and
they
cannot
find
any
methods
and,
like
so
the
moment,
we
added
more
constructors
and
yes,
some
methods,
they
think
methods
are
still
methods
and
they
are
not.
B
There
are
no
constructors
equivalents,
constructor
equivalents,
but
they
are
kind
of
more,
I
would
say
advanced,
so
what
people
would
would?
What
we've
seen
in
usability
studies?
They
would
start
using
constructors
and
then
over
time
they
would
learn
about
this
type
and
then
they
would
discover
the
static
methods.
B
For
example,
you
know
initially
they
instantiate
it
using
constructors.
They
call
instant
methods
from
time
to
time.
They
are
like.
Let
me
see:
what's
the
shape,
this
type
seems
to
be
kind
of
useful
and
showing
up
in
a
lot
of
apis.
Let
me
go
to
you
know
its
definition,
and
then
they
discover
kind
of
they
learn
over
time,
the
the
whole
shape,
but
when
we
didn't
have
constructors,
it
was
very
confusing
because
of
the
issue
that
I
mentioned.
D
C
B
Unless
we
have
static
extension
methods,
we
don't
like,
we
don't
get
any
benefit
from
wrapping.
The
constructor.
A
Right
I
mean
this
is
more
like
a
question
of
like
how
could
we
design
the
type
right?
The
other
concern
that
I
have
is
if
we
go
with
factory
methods,
I
would
probably
not
have
any
constructors,
because,
as
soon
as
you
have
some
constructors
people,
don't
look
for
factory
methods
anymore
right.
So
if
you
have
no
constructors
or
you
have,
you
know,
and
everything
is
either
a
factory
method
or,
like
an
instance
method
like
a
set
or
something.
A
B
G
B
Because
it's
it
so
we
have
to
have
static
methods.
So
then
you're
basically
saying,
since
we
have
static
methods,
we
cannot
have
constructors
and
then
basically
you
run
into
the
issue
that
I
mentioned
it's
a
struct.
It
has
to
have
a
constructor
people
find
the
constructor
and
then
they
are
confused.
What
to
do
with
this
type.
A
Well,
that's
why
I'm
saying
to
me,
like
the
one
other
option
that
we
have
is
instead
of
having
a
constructor
or
a
factory
method,
you
could
just
have
an
instance
method
that
just
sets
the
byte
array.
B
C
A
B
So
we
care
unless
it
causes
a
problem,
so
you
know
the
problem
that
you
mentioned
that
now
people
don't
find
the
static
methods.
As
I
said,
we've
seen
we,
we
did
actually
seen
a
lot
of
evidence.
What
what's
happening
here
in
usability
studies
and
the
only
construct,
the
only
things
that
are
not
constructors
are
the
async
methods
so.
C
B
B
Fundamentally,
we
cannot
have
async
constructors
and
then
this
is
what
we
observe
this
people.
Don't
look
for
async
apis
on
this
type
anyway,
but
once
they
learn
the
type
over
time
they
kind
of
keep
using
it
and
they,
you
know
they
go
into
the
api
view
and
look
at
the
types
they
discover
that
these
methods
are
there
and
you
know
and
kind
of
they
learn
over
time.
B
So
we
basically
the
answer.
My
answer
would
be:
it's
not
really
important
that
the
additional
methods
that
are
only
factory
methods
are
be
super
discoverable,
like
at
least
we
we
haven't,
seen
a
reason
why
we,
where
we
were
testing
users
and
we
were
like
geez-
they
cannot
find
these
static
methods.
You
know
what
do
we
do
with
this
thing.
A
B
A
B
B
B
A
B
A
C
Okay,
yeah,
I
mean
my
like
I'm
really
just
trying
to
think
of
you
know
what
comments
like
steve
would
be
giving
if
he
were
here
and
that's,
I
would
say
or
eric
since
he
joined,
but
then
he
already
left
about
just
the
future
extensibility
of
the
serializers
and
the
tripability
thereof,
and
I
think
it'll
be
very
weird
if
we
have
a
constructor
that
does
jason,
but
no
one
wants
jason
anymore
and
because
I
I
mean,
I
know
that
we,
we
sort
of
cynically
said
now,
we're
adding
support
for
jason.
D
A
I
mean
my
general
concerns
are
my
general
I
think
take
on
this.
Is
that
not
in
framework
wasn't
exactly
a
fast
moving
stack
right
and
even
there,
as
you
said,
like
we,
we
kind
of
iterated
on
civilization
a
lot
right
and
I
feel,
like
the
speed,
is
only
going
up
right.
We
ship
more
frequently
we
are
more
interested
in
web
technologies
than
we
have
been
before
and
that
stuff
is
evolving
fast.
A
You
could
totally
imagine
that
that
button
is
way
more
important
than
than
our
json
stack
is
right,
and
so
my
concern
is,
if
you
have
a
type
that
is
super
optimized
for
json
and
it
works
great,
but
it
has
a
super
steep
falling
off
for
other
things.
Then
we
cornered
ourselves
pretty
badly
with
the
design
right,
but
I
mean
I
I
think
to
me
like
I
buy
all
these
ability
arguments
and
I
even
buy
that
this
type
doesn't
have
to
be
low
level.
C
C
So
I
mean
this
is
my
just
like:
if
we
got
rid
of
the
the
constructors
that
that
did
serialization
and
we
made
them
only
be
factories
and
we
named
the
one
that
doesn't
take
whatever
the
serialization
abstraction
is,
you
know
from
object
to
json
and
then
it
says
the
jason-ness
in
it,
and
then
it's
not
that
we
gave
a
default.
It's
we
gave
an
easier
to
use,
one.
A
C
And
so
that
would
be
that's
the
the
direction
that
I
would
like
to
go.
I
think,
and
then
that
also
works.
For
you
know
the
the
make
things
nice
and
trimmable
is
when
you
call
from
jason
it
doesn't
need
seaborn,
protobuf
and
gamble,
and
you
know
every
other
thing
that
you
can
think
of,
but
the
then,
when
you
call
the
protobuf
one,
it
conversely
doesn't
need
the
dependency
on
json
anymore.
G
A
Yeah,
I
think
we
have
to
reopen
the
discussion.
This
is
sharp
team
because
I
think
extension
everything
doesn't
go
anywhere
because
it's
too
costly
and
too
expensive
of
a
feature
for
them
to
build.
I
am
personally
okay
with
if
we
just
have
extension
aesthetics
that
would
get
us
a
lot
of
the
problem
solved
that
we
have
today.
Like
I
mean
to
me
the
the
two
things
we
have
asked
in
the
past,
which
was
extension
properties
and
extension
constructors.
A
We
mostly
needed
them
because
of
compat
right,
because
we
wanted
to
take
an
existing
type
that
was
designed
for
the
net
framework
days
and
basically
break
it
apart
without
breaking
source
compact
and
in
that.
Well,
yes,
you
want
extension
everything,
but
that
one
is
no
longer
really
our
goal,
and
so
now
for
the
new
world
we
just
want
to
say:
okay,
we
want
to
design
apis
that
are
usable,
but
also
composable.
A
Then
we
can
say:
well,
okay,
we
don't
have
constructors,
then
we
only
do
you
know
statics
and
that
works
fine
right
and
then
we
can
just
say.
Okay,
the
only
thing
we
really
need
from
the
compiler
team
is
a
feature
that
allows
us
to
inject
statics
into
an
into
another
type,
which,
arguably
all
you
need.
You
don't
even
need
language
support
for
that.
I'm
totally
fine
with
saying
there's
just
some
custom
entity
you
put
on
the
on
the
on
the
on
the
type
plus
the
method,
and
then
the
compiler
does
the
name
lookup.
A
Well,
no,
no
I'm
saying
the
problem
in
the
past
was
we
couldn't
agree
on
syntax,
because
if
you,
if
you
try
to
define
properties
and
events
and
constructors,
what
is
even
the
language
syntax
to
encode
them
right
right
and
so,
but
if
we,
if
we
just
scope
it
to
all,
we
need
is
extension
aesthetics.
You
don't
need
basically
language
changes
for
that.
You
only
need
effectively
name
lookup
rules,
changed
right
and,
and
then
say
the
syntax
is
use
the
custom
attribute
and
that
solves
the.
A
C
Well,
be
a
targeted
feature
for
that,
my
god
on
extension,
everything
is
extension
fields
are
very,
very,
very
complicated,
and
once
you
have
that
you
can't
do
or
if
you
don't
have
that
you
can't
do
properties
or
events,
because
they're
essentially.
A
Don't
even
need
new
state,
because
you
wouldn't
just
have
a
new
property
that
just
combined
state
of
other
properties,
which
is
what
powershell
is
doing,
for
example,
with
their.
What
is
it
annotation
properties
or
whatever
they're
called,
and
so
you
could
do
things
there
as
well.
I
just
don't
think
that
that
to
me
is
more
niche
at
this
point,
because
we
don't
do
these
decomposition
of
existing
types
anymore,
but
it's
really
more
about
forward-looking
stuff.
If
we
want
usability
and
composability
yeah,
I
mean
another
option
that
we
have
is
we
know
just
better
intellisense.
A
I
mean
that's
another
problem
that
we
have
today,
that
if
you,
if
you
have
constructors
and
factories,
how
the
heck
do
you
construct,
how
do
you
discover
the
factories
right
and
if
the
fact
is
on
the
same
type,
then
you're
somewhat
in
luck,
but
even
then
intellisense
doesn't
really
help
you.
You
have
to
kind
of
know
that
okay,
you
know,
delete
the
new
keyword
and
I'm
going
to
say
type
name,
dot
right,
and
you
could
imagine
some
experience
there
in
intellisense,
where
we
promote
factory
methods
in
the
constructor
context.
A
A
So
the
there
is
a
bit
of
a
timeline
issue,
and
even
if
we
were
to
do
the
factory
thing
that
we
did
that
we
said
we
can
of
course
ship
the
package
today,
but
most
likely,
even
if
this
resharp
team
wants
to
do
extension,
statics
for
c-sharp
nine,
it
would
ship
in
november
next
year
right.
So
that
means
sorry,
not
nine
ten.
I
guess
it
is
right,
because
nine
is
for
five.
So
then
the
question
becomes
really
like.
A
C
Well,
I
mean
without,
without
extension,
anything
like
if
we
did
say
this
was
a
class
and
we
got
rid
of
all
the
constructors.
So
everything
was
the
factories
yep.
A
C
Yes
does
lose
some
usability,
but
then
has
gains
consistency.
Then
we
can
name
the
the
thing
that
defaults,
jason
and
and
everything
is
named,
and
everything
is,
I
think
that
gives
us
better
paths
forward
than
than
trying
to
say.
Well,
we
wanted
it
to
be
a
struct,
so
we
can
save.
On
the
you
know,
it's
a
byte
array
and
a
wrapper
object
per
return.
C
A
Yeah,
so
the
other
thing
that
I
said
before,
which
I
still
think
is
not
a
bad
design,
is
just
don't
have
factories
either
right.
You
could
imagine
a
design
where
you
just
you
are
binary
data
and
then
everything
is
just
an
extension
method
literally
on
the
type
instance,
so
you
can
say
set
bytes
right,
set
from
object,
json
set
from
stream
and.
A
D
I
think
we're
making
assumptions
about
how
their
implementation
works
so
because,
if,
if
everything
that
they
have
is
backed
by
a
rom
or
a
byte
array
like
changing,
things,
could
could
potentially
mute
start
mutating
instances.
C
Well,
if
you
just
had,
if
the
only
thing
you
had
was
set
that
took
read-only
span
of
bite
right,
then
you're
saying
I
am
making
a
copy
when
you
call
this.
So
if
you
needed
to
do
some
pooling
in
your
method,
you
do
the
pooling,
give
me
I'm
going
to
copy
the
data,
and
then
you
return
your
thing
to
the
pool.
C
I've
used
my
own
array
on
this
and
then,
when
you
get
when
you
call
the
two
bytes
which
gives
you
the
wrong
byte
yeah,
it's
pointing
to
a
managed
array,
but
nothing's
ever
going
to
set
data
in
that
array
again,
because
there
are
no
there's
no
longer
write
access
into
that
array.
C
The
data,
so
it
is
a
little
weird
and
that
you
can
call
a
thing,
and
now
it
has
completely
replaced
what
it's
doing,
because
they're
like
oh,
I
can
save
on
the
object
thing
by
just
replacing
the
data
inside
this
one
instead
of
returning
a
new
one.
That
would
be
a
temptation
in
the
in
the
hyper
low
allocation
world,
but
that
may
be
okay.
It
does
feel
that
the
type
is
it
gives
us
better
composition
in
our
current
world,
but
it
does
feel
like
that
is
a
definite
hit
on
usability.
C
A
Mean
that's
the
other
thing
where
I
think
maybe
it's
okay
to
actually
leave
it
as
a
struct
as
well,
because
if,
if,
if
all
the
extension
methods,
basically
just
take
this
wire
in
which
they
can
now,
you
actually
have
the
right
semantics.
When
you
call
you
know,
struck
dot,
you
know
set
from
bytes
or
something,
but
then
as
soon
as
you
pass
the
binary
around,
because
you
actually
passed
a
copy
of
the
binary
data,
you
can't
actually
mutate
the
thing
it
points
to
right.
A
It
basically
becomes
immutable
via
that
mechanism,
which
I
think
would
still
be
good
enough
for
usability,
because
all
you
do
is
now
again
var
x,
new
binary
data
x,
dot
set
from
bytes,
and
then
you
pass
this
thing
around
and
if
you
do
something
else
with
that
instance,
it
doesn't.
It
doesn't
affect
the
other
instance,
and
so
it's
it's
not
terrible
either.
I
think
that's
it's
not
the
ideal
design
I
would
like
to
ship,
but
it's
also
a
design.
At
least
I
can
see
myself
shipping
within
two
months
without,
depending
on
your.
C
Like,
let's
say
that
everything
ultimately
calls
from
bites
ross
bite
right.
If
that
one
then
says
wait,
my
my
array
field
is
not
null.
I've
been
initialized
already
and
then
throws.
The
value
can
only
be
set
once
I
think
that
would
solve
all
the
that
would
really
solve
the
you
got
confused
by
mutable
struct,
not
like
you.
You
called
a
method
it
called
set.
Well,
it
wouldn't
have
done
that,
because
that
would
have
thrown.
A
C
A
Be
clear,
I
think
I
think
the
ross
is
not
going
to
be
the
bottom
one,
because
the
ros
one
has
to
copy.
I
think
the
bottom
one
is
probably
f.
Some
internal
one
would
be
my
guess
right,
but
because,
because
the
fact
that
they're
all
copying
right.
C
Yeah
I
mean
that's
why
I
said
I.
I
actually
think
that
the
ross
one
would
be
the
bottom
one,
because
oh.
C
And
every
if
everything
else
is
built
by
extension
methods
at
higher
layers,
they
didn't
have
access
to
internal
storage
to
set
it
directly.
So
things
like
the
json
serialization
would
need
to
pre-rent
an
array
if
it's
trying
to
save
on
the
one
object
allocation
very.
A
C
A
I
mean
what
I
like
about
this
pattern.
Is
it's
it's
easy
to
extend
right
and
it's
very
consistent.
It's
always
an
instance
method.
If
it's
async
it
just
has
an
async
suffix.
If
it's
not
if
it's
sync,
it
just
doesn't,
have
an
async
suffix
it
there's
no
like
oh
yeah,
sync,
apis
or
constructors
and
async
apis
or
factories,
or
something
like
that
right,
like
it's
a
very
it's
a
very
simple
pattern,
and
I
mean
in.
A
I
haven't
seen
easily
to
study,
but
I
I
might
have
my
hunch
is:
if
you
have
no
constructors,
you
just
have
an
empty
one.
You
just
save
our
x
equals
mu.
The
very.
A
C
A
C
Right
yeah,
I
guess,
set
beats
to
import
beats
to
load,
beats
yeah.
As
long
as
you
beat
two,
then
you
said
new
thingy
you
hit
dot
and
at
the
top,
is
the
the
end
put
things.
Of
course,
if
you
have
the
in
telecode
turned
on,
then
it
may
be
like
the
most
commonly
called
thing
on.
This
is
to
object.
Yeah.
B
A
Mean
I
have
no
idea
how
that
feature
works.
Well,
intellicode
is
actually
doing
exactly
what
you
just
said,
because
intellicode
is
not
just
ranking
members.
When
you
invoke
intellisense,
it
will
rank
members
based
on
the
surrounding
code.
So
if
the
very
preceding
line
is
new,
yes,
I
would
expect
like
set
bytes
or
set
object
to
be
to
object.
A
That's
how
that's
already
how
intellicode
should
work,
but
I
also
review
intellicode
has
messed
up
my
intellisense
multiple
times
where
I
expect
a
sorted
list
and
then
I
look
at
this
and
I'm
like
why
and
to
me
the
worst
thing
is
that
things
are
out
of
order
now
because
they
like
they
remove
the
member
right.
So
that's
not
like
you
see
them,
you
see
some
suggestions
at
the
top
and
then
you
have
a
fully
ordered
list.
A
A
But
what
do
you
guys
think
about
the
idea
in
general?
Like?
Are
you
mentally
opposed,
or
do
you
think
there's
a
valid
thing
here.
B
C
The
double
set
block
that
means
that
we
would
we
would
remove
the
comp
like
we
would
be
nipping
in
the
bud
the
complications
that
come
from
immutable
struct
because
effectively,
we've
said
you
you
build
it,
you
get
to
call
which
named
constructor
you
wanted
and
then
it's
now
immutable
again,
and
so
you
would
never
have
a
state
where
you
pass
it
to
some
method.
It
thought
it
was
modifying
something
and
it
and
it
didn't.
C
It
will
make
read-only
fields
complicated,
but
again,
you'll
find
out
very
quickly
on
that,
and
so
I
I
think
it
would
work.
Certainly
we'd
want
to
take.
I
guess
right
now:
he
has
it
as
a
read-only
struct,
so
we
would
lose
read
only
on
the
struct
and
then
all
the
two
methods
would
become
read
only.
D
C
D
C
D
C
I
mean
it
is
a
new,
as
far
as
I
know,
it's
in
at
least
uncommon
pattern,
but
I
think
it
is
the
best
we
can
get
with
current
language
and
then
yeah
that
we
would
take
the
we
need
to
figure
out
what
we
wanted
to
do
for
the
jason
serialization
stuff,
because
we
we
probably
do
still
want
the
word
like
jason
in
the
name,
because
otherwise,
if
you're
ever
in
a
universe
that
has
both
system
text
json
and
protobuf
in
your
usings
and
now
they're,
both
stomping
on
from
object.
D
A
I
mean
if
we
put
the
extension
methods
that
use
json
in
system
text.json.
I
think
it
wouldn't
be
terrible
like
because
then
you
could
either
have.
You
could
even
have
the
exact
same
extension
method
names
for
json.net
and
you
just
put
them
in
newtonsoft.json
right
and
you're,
not
super
likely
to
have
a
using
for
both
newtonsoft,
json
and
systemtext.json,
because
as
soon
as
you
do,
that
like
intellisense,
is
going
to
be
a
mess
anyway
and
for
the
people
who
do
that.
C
A
B
C
That
each,
if
it's
a
serialization
thing
that
it
needs
that
it
should
say
what
it's
doing,
because
from
stream
is
easy,
it's
reading
from
a
stream
it's
doing
whatever
stream.read
would
do
if
your
stream
is
being
populated
by
a
higher
level
composer
that
it
already
made
all
those
decisions
and
you're
just
draining
the
stream.
B
C
It's
it's
only
the
the
complicated
serialization
ones
that
you
would
end
up
with
a
non-degenerate
application
would
end
up
with
a
conflict
on
that
name
right.
So
that's
the
one
that
I
would
just
want
to
make
sure
that
we're
defensive
against
that.
We
start
with
the
good
pattern
instead
of
like
we
take
the
best
name
and
then
so
does
protobuf,
and
now
we're
in
trouble.
A
Yeah,
I
agree
with
that.
I
mean
like
we
can
basically
do
something
like
we
did
from
the
http
client
extension
methods
right
and
that
I
think
has
worked
well.
The
only
thing
that
we
up
in
my
opinion
for
the
extension
methods
was
we
put
it
in
a
new
namespace.
That
was
not
a
great
idea,
because
I
can
never
remember
the
namespace
fair
enough,
but,
like
I
mean
I
know
why
we
did
it,
but
like
it's
it's,
it
was
unfortunate.
We
probably
should
have
put
it
in
system
text.json.
C
A
C
If,
even
if
the
extension
methods
for
json
live
in
the
same
package,
where
binary
data
is
being
defined
depending
on
where
it
goes
in
the
in
the
hierarchy
like
having
them
be
extension
methods
in
the
system,
text,
json
namespace
over
binary
data
makes
sense
to
me.
It's
not
quite
a
thing
that
we've
covered
in
the
guidelines,
but
it
it.
It
feels
very
close
to
guidelines.
We
already
have.
A
Yeah,
so
then
let's
do
this,
let's,
so
I
will
post
the
notes
that
I
currently
have
the
other
thing
that
we
need
to
talk
about.
So
if
we,
if
we,
if
so
depending
on
what
what
we
get
together,
then
the
next
questions
will
be
ship.
So
let's
say
we
do
this
two-month
thing
that
christoph
wants,
then,
basically,
what
it
would
mean
is
he
would
put
this
type
in
a
nuget
package
and
ship
it,
and
so
basically
there's
two
options.
A
A
But
that
to
me
seems
probably
okay,
because
if
we,
if
we
say
like
for
you
know
when
you
talk
about
back
porting
by
definition,
when
you
back
port,
you
put
something
you
that
could
be
low
level
very
high
level
right,
because
you
ship
with
a
net
new
assembly
that
sits
on
top
of
everything
else
right,
so
that
that's
not
really
a
concern
for.
C
I
think
that
once
we've
moved
to
the
we
can
get
the
json
stuff
from
extension
methods
that
we
do.
I
don't
know
that
we
want
to
spike
it
to
the
bottom,
but
we
we
probably
do
like
it.
Maybe
it
might
be
interesting
to
put
this
as
below
system
text,
json
and
system
text
json
provides
its
own
extension
methods.
C
A
So
that's
the
other
reason
why
I
don't
like
putting
in
a
system
text.json,
because
system
text.json
today,
similar
to
immutable
metadata
reader
is
a
is
a
you
replace
the
entire
package
in
dotnet
five
right,
so
that
so
that
gives
us
really
nice
characteristic,
because
we
can
actually
wrap
the
api
service
for
the
for
system.
Text.Json
in
in
you
know,
which
we
can't
in
that
say,
span
right
because
span
is
inbox
and
you
can't
replace
it
with
a
package
versus
in
donate
five.
A
You
can
replace
system
text.js
in
the
package,
because
it's
you
know
you
basically
replace
the
entire
module
then,
and
so
we
you,
we
can
actually
add
net
new
apis
and
then,
even
if
you
install
this
into
dot
net
5,
it
would
just
you
know,
use
the
one
that
ships
with
your
app
could.
A
Yeah
so
yeah
I
mean
like
memory,
is
the
one
that
ships
span
of
the
other
ones
right,
and
I
think
that
one
is
locked.
You
can't
do
anything
in
that
one.
So.
E
A
C
That
means,
and
then
it
would
still
have
forward
saying,
span
lives
in
private
core
lib
or
in
the
case
of
framework
spam
lives
in
that
package
and.
E
A
Deploy
an
application
you
deploy
a
particular
module,
so
the
question
is
now:
if
this
module
exists
also
in
the
platform
layer,
is
it
safe
to
replace
that
module
with
the
one
that
shipped
with
the
app
as
soon
as
that
module
has
changed
locations
because
of
type
forwarding?
It's
no
longer
safe
to
do
that
right.
So
that's
why
you
lock
in
the
the
api
surface
right.
So
that's
why
system.memory.dll?
A
It
just
depends
on
things
that
do
type
forwarding
like
spam
and
other
things,
and
so,
if
you,
if
you
ship
binary
data
with
systemtext.json
for
2o,
you
can't
say
in.net
6
binarydata
lives
in
system.runtime
dll,
because
that
no
means
you
can
no
longer
safely
replace
systemtext.json
with
a
newer
version
right.
Does
that
make
sense.
C
A
C
A
Well,
it's
more
like
you
don't
have
so
basically
you
can't
create
a
a
single
binary
system,
memory.dll
that
would
work
on
all
platforms
right
because
the
thing
is
on
some
platforms,
you
ship
a
definition
for
some
of
the
types
like
span
and
then
some
others.
You
have
to
do
type
forwarding
because
the
types
are
inbox
and
because
of
that
you
no
longer
can
create
the
the
you
know,
a
logical
highest
version
that
contains
everything
you
want
and
that's
why
these
things
are
locked
at
some
point.
A
Yeah
but
the
problem
with
split
implementation
is
you're,
assuming
that
deployment
runs
again,
which
it
doesn't
right,
you
you
you
deployed
for
dot-net
core
2-0
and
then
you
happen
to
run
on.net
five,
and
so
the
module
you
deployed
is
not
the
wrong
module
because
the
module
you
deployed
actually
the
definition
for
a
span.
But
the
more
you
need
needed.
The
type
forwarder
for
spam
right.
C
A
C
A
C
C
It's
actually,
it
may
be
convenient
today,
but
it's
inconvenient
tomorrow.
F
C
G
A
Right,
but
I
think
the
nice
thing
is
like
if
binary
data
actually
becomes
this.
Basically
just
this
data
holder
it
to
me,
it
lives
at
the
same
level
as
stream
and
stream
lives
in
system
runtime
right,
and
so
I
would
be
okay
with
saying
we
added
the
system
at
runtime,
because
the
type
is
basically
empty
because
as
soon
as
you
do
that
you
never
you.
A
Yeah,
I
think
I
would
be
doing
this
only
for
cases
where
usability
is
super
important,
I
I
think
the
or
when
you
really
need
extensibility
right.
Like
I
mean
even
on
stream,
you,
you
are
not
very
likely
wanting
a
virtual
method
that
takes
binary
data
right
because
you
would
just
say
well
just
call
on
the
other
existing
virtual
ones
right.
A
C
A
A
A
A
And
so
that
one
would
be
a
good
candidate
to
say,
maybe
that
one,
you
should
have
an
overload
that
just
takes
binary
data
and
returns
binary
data
right,
because
that's
really
the
one-stop
shop,
where
you
don't
care
about
perf,
you
just
care
about
a
very
super,
simple
thing
and
then
that
one
would
make
sense
right
and,
and
the
key
value
here
would
be
you
basically
not
only
take
it
binary.
They
also
return
in
binary
data,
so
it's
very
uniform
and
that
that
would
be
sensible.
A
A
C
G
C
A
That
will
now
make
our
lives
harder
for
net
six
without
breaking
compact
for
people
that
are
running
on.net
five
today
with
that
package,
and
that
is
the
concern
that
we
that
that
I
have
because
that's
the
thing
we
usually
it
up
and
then
we're
like.
Oh
yeah,
if
you
know
upgrade
sorry
like
you,
have
to
it's
the
newer
version
of
the
package,
because
unfortunately
we
didn't
think
about
that.
A
So
in
a
perfect
world,
when
we
shipped
the
new
get
package,
we
also
include
the
plants
that
have
type
forwarders
in
them,
so
that
you
don't
have
this
upgrade
problem,
but
that
very
rarely
happens
if
we
ship
the
oop
version
before
the
platform
version.
That's
what
we
usually
said
like
ship,
the
platform
version
first
and
then
the
oop
after
because
then
you
can
effectively
ship
the
new
gear
package
already
with
all
the
type
forwards
in
them,
so
that
when
you're
in
a
solution,
you
never
have
an
inconsistent
state.
C
Yeah
I
mean
we
could
we
could
shove
the
thing
in
at
five
as
at
the
last
minute,
which
jeff
is
probably
wincing
at
that
notion,
but
that's
what
I
get
for
not
having
to
be
a
lead.
Yet
if
we
did
oh.
C
G
C
E
A
Yeah,
it's
also
to
me
it's
kind
of
like
if,
if
you
know,
if
you
ship
a
type
that
they
don't
want
to
take
a
dependency
on
because
it
doesn't
realize
their
goals
and
we
just
created
instant
legacy.
So
that's
my
other
concern
is
like
you
know.
If
we
I
mean
shoving
into
2.5
seems
doable,
but
that
would
be
really
hard.
I
mean
the
type
is
small
enough
that
I
can
convince
myself
that
we
could
be
doing
that
because
everything
that
would
be
complicated.
A
We
would
move
to
an
extension
method
anyways,
and
for
that
we
have
a
little
bit
more
time.
Yep,
but
yeah
I
mean
to
me
the
the
question
really
becomes.
A
C
Yeah,
we
would
still
have
the
complication
of
if
we
shove
this
in,
and
we
want
the
jason
thing
we
do
have
to
go.
Add
the
the
json
extension
methods
in
system
text
json
also
for
five
slash
bump
the
contract
for
net
standard
2o,
which
I
think
it
only
has
a
net
standard
2o
contract.
I
think
that's
how
we've
avoided
the
most
of
the
complications,
because
we
didn't
split
the
api.
A
I
think
we
actually
do
have
this.
I
mean
we
don't
have
a
split
api.
We
have
speed
implementation
for
sure.
C
Right
but
I
don't,
I
don't
think
that
the
split
implementation
added
new
net
new
members
and
that
which.
C
Adjusted
based
on
the
way
that
it
builds.
That
would
just
happen
because
we
would
declare
the
the
extension
methods
and
then
it
would
build
it
twice
once
inbox
with
where
it's
internally
calling
methods
that
we
know
exist
in
net
five
and
then
the
other
one
in
the.
A
A
A
A
Never
mind
it's
gone
anyway,
so
I
think
this
is
all
we
had.
Let's
talk
about
this,
maybe
more
detail
later.
A
F
F
C
Yeah
we're
calling
out
that
we've,
we
started
with
not
a
great
number
of
people,
but
we
also
didn't
have
to
make
real
decisions,
and
now
we
have
even
fewer
people.
A
F
All
right,
so
we
had
already
approved
a
number
of
half
apis
to
bit
converter
and
other
places,
but
these
four
were
basically
missed:
they're
the
bit
converter
methods
for
writing
to
byte
arrays
and
spans
respectively,
and
for
getting
the
raw
byte
array
or
span
of
bytes
back
out.
F
F
Or
double
correct,
which
is
also
why
we
made
them
explicit,
so
we
wouldn't
have
compatible
issues
implemented
in
the
future.
What.
G
F
F
E
E
At
the
end
of
the
day
anyway,
so
you
can't
just
have
a
language
one.
You
actually
have
to
decide
what
what
could
execute
when
you
call
it
so
then
the
question
becomes
what
so
we
have.
So
we
will
ship
an
explicit
london.
C
F
We're
not
especially
since
we
already
reviewed,
approved
and
young
just
signed
off
on
the
other
big
converter,
overloads
like
the
half
two
and
16
methods.
Okay,.
C
F
Yeah,
because
we
we're
eventually
going
to
add
intrinsic
support
and
other
bits
to
it,
which
I
need
to
get
the
proposals
up
for.
A
E
G
C
F
Custom
operators,
so
the
way
it
works
is
because
there's
no
aisle
for
it.
The
actual
implementation
is
defined
in
managed
code,
so
it's
written
in
cd
sharp.
You
can
actually
go
and
use
reflection
to
find
op
edition,
but
the
language
has
an
internal
operator
table
that
says
the
language
in
the
language
supports
the
concept
of
adding
two
decimals
together.
F
F
C
E
All
right,
so
then,
I
think
this
is
it
for
today
we
actually
got
everything
done
if
you
wanted
to
get.
C
H
C
E
Well,
I
mean,
like
I
talked
to
him
yesterday
mean
like
he
didn't,
have
an
expectation
we
would
approve
it
today.
Like
I
mean
he
wanted
to
plant
the
seed.
A
C
Yeah,
I
think
that
sounds
like
a
good
next
step,
so
figuring
out
just
pick
a
strong
man
verb
that
you
want
for
the
setter
and
then
you
know
put
a
comment
somewhere
that
it's
functionally
handed
only
so
calling
set
twice
will
throw
which
will
stop
immutable,
struct
complications
from
showing
up
in
the
real
world
right.
H
Rc
too
we're
just
going
to
go
directly
into
asking
for
our
state
based
on
texas
decision
this
morning.
We're
not
going
to
do
like
we're
not
going
to
downgrade
back
to
an
intuitive
approval.
H
So
we're
in
ask
mode
here,
through
the
end
of
the
release
this
month,
is
when
we're
locked
in
gta.
G
Yeah,
I
think
I
think
rc
one
makes
sense.
I
didn't
expect
our
sc1
to
be
something
we
could
do,
but
like
rc2,
officially
snaps
on
the
14th,
I
believe
so
we
have
effectively.
C
Yeah,
so
I
mean
it
still
can
be
directly
pulled
into
the
branch,
but
the
but
rc2
is,
I
think,
essentially
past
feedback
like
that
people.
Real
people
need
to
give
feedback
on
like
the
day
it
comes
out
or
we've
missed
the
window.
C
E
A
G
Not
meeting
that
bar
yeah,
so
I'd
be
shocked
if
you
would
have
been
doing
that.
C
E
E
A
We,
you
know,
we
ship
this
nuclear
package
right.
It
has
a
definition
for
binary
data
and
then
there's
another
type
that
has
the
extension
method
that
lives
in
the
system
effect.js
and
right.
So
you
should
you,
you
get
a
package
system.
A
Data
has
one
assembly
and
then
one
type
in
it
right
and
that
assembly
would
we
only
have
a
single
implementation
for
it
today,
which
would
be
necessary
to
oh
that
just
shifts
the
definition
right,
because
we
don't
have
you
know
we
haven't
shipped
on
n6
yet
so
there's
nothing
for
us
to
type
forward
to
so
now
you
have
your
project.
A
Everything
works
today,
12
months
from
now,
you're
upgrading
your
project
in
appropriate
properties
from
net
5
to
net
six,
and
you
try
to
rebuild
as
soon
as
you
try
to
do
this
now
you
have
to
binary
data,
but
you
have
one
coming
from
the
package
and
you
have
one
coming
from
the
platform
and
for
you
to
solve.
E
C
Okay,
so
it
would
be
a
you
have
to
upgrade
the
package
to
get
the
forward
if
you're
compiling
against
the
net
six
tfm.
That.
C
And
so
that
I
can
do
it,
but
if
you
were
compiling
it
against
that
standard
or
the
net
five
tfm
things
will
unify
correctly
at
one
time,
because.
E
C
The
that
work,
I
think,
that
the
rebuilding
your
your
packaging
getting
a
higher
version
like
as
long
as
it's
you're
building
a
new
thing.
It
would
already
pull
the
highest
stable
version,
so
it
may
be.
It
may
be
generally.
Okay,.
E
C
Right,
but
we
could,
for
example,
just
thinking
ahead.
We
ship
it
is
now
through
whatever
mechanism
we
can
ship
to
the
zoom
in
master.
We
go
ahead
and
declare
the
thing
at
some
point:
we're
going
to
push
the
net
six
tfm
into
the
tfm
graph
and
as
soon
as
we
do
that
we
could
bump
the
package.
So
there's
already
in
the
notion
of
an
x
forwarder
sitting
out
there
for
a
very
long
time.
A
Yes,
that
is
true.
We
can.
We
can
limit
the
time
we
know
where
people
have
shitty
packages.
That
is
a
fair
statement.
Yeah.
C
C
A
C
A
Anybody
it's
just
yeah,
it's
one
of
those
things
that
you
get
one
shot
of
getting
right
and
then
at
that
point
you
just
talk
about
people.
C
G
A
2,
as
well
as
for
five
or
six
or
whatever,.
C
We
need
to
publish
another
stable
version
of
that
package,
slightly
off
cycle.
C
Like
we,
we
just
need
to
figure
out
what
the
logistics
of
that
is.
I
don't
know
if
that
would
be
eric
st
john
or
what
but
the
easiest
answer
would
be.
We
just
check
it
in
and
it
goes
stable
with
five
right
that
requires
ship
room
approval
which
we
you
could
get
if
you
say
well
we're
going
to
do
this
off
cycle
around
that
time
anyway,
it's
just
easier
for
everyone
involved
if
we
check
it
into
this
tree
right,
but
so
yeah.