►
From YouTube: GitHub Quick Reviews
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
C
I
I
usually
take
the
notes,
as
I'm
going
it's
it's
fine
in
terms
of
agenda,
so
I
was
thinking
the
option
back
for
file
stream
is
probably
easier
and
then
we
use
the
other
two
like
well
the
remaining.
Whatever
time
you
have
left
for
the
jason
one,
so
we
would
start
with
the
fast
posterization
logic
and
then
we
would
look
at
the
json
content
type
and
what
was
the
point
that
showed
up
now
gym
ability
yeah
here
we
go
that's
another
one.
We
can
look
at
so
awesomeness.
D
I'll
be
dropping
about
a
half
hour
before
review
is
over,
but
otherwise
I'll
be
here.
For
the
first
hour
and
a
half.
F
Yep,
we
are
all
right
good
morning,
everyone.
So
this
is
a
an
api
proposal
that
we
already
reviewed,
but
the
request
is
to
put
the
recently
approved
api
in
a
new
options.
Back,
I'm
talking
about
allocation
size,
there
was
pushback
after
the
api
got
approved
and
it
makes
sense
to
put
all
these
properties
in
a
new
options
bag.
In
case
we
keep
adding
attributes
which
will
eventually
happen
to
file
stream.
F
So
the
first
thing
is
allocation.
Size
was
the
api
that
got
approved
last
time.
I
believe
the
name
was
allocation
size
as
it
is
described
by
adam
there,
and
the
request
is
to
rename
it
to
pre-allocation
size,
which
makes
a
little
bit
more
sense.
F
The
second
thing
is
all
the
most
of
the
other
properties
are
the
same
ones.
We
already
have
as
parameters
in
the
file
stream,
constructors
path,
mode,
access
share
and
file
options
which
will
have
a
default
value
just
like
we
said
it
in
the
file
stream,
constructors,
there's
an
additional
request
to
add
a
buffer
and
a
memory
of
byte.
F
F
Of
course
it
has
its
own
dangers,
but
we
can
document
it
really
well
and
make
sure
that
users
know
about
the
the
potential
issues
of
doing
that.
That's
one
option
was
to
using
memory
of
bytes
and
the
other
one
was
there's
an
alternative
design.
F
A
I
think
carlos
or
stream
fell
off.
G
Yeah
it
sounds
like.
Can
I
ask
a
general
question:
why
is
this
a
struct.
A
The
the
follow-up
to
that
is
like
should
path,
be
a
required
parameter.
Basically,
because
it
looks
like
you
always
have
to
specify
a
path
if
nothing
else.
A
Yeah
but
there's
like,
is
there
any
type
of?
I
don't
know
enforcement
or
whatever
saying
like
hey,
I
guess
if
someone
doesn't
specify
a
path
and
they
try
calling
the
constructor
like
they're
just
going
to
get
an
exception,
that
it
would
be
nice
if
there
were
some
type
of
you
know
some
type
of
compile-time
enforcement.
Saying
hey.
You
know
you're
misusing
this,
because
as
soon
as
you
control
it.
C
You're
gonna
fail.
No,
I
think,
actually
you
get
it.
I
think
the
compiler
will
actually
give
you
well
I
mean
this
is
the
thing
right.
So
if
you
yeah,
if
you
just
new
up
this
truck,
the
compiler
assumes
everything
is
assigned
by
the
constructor,
and
so
you
probably
won't
get
a
warning
when
you
don't
initialize
path,
maybe
it
gives
you
one
front
yeah.
No,
I
don't
think
it
will,
because
it's
because
you
said
it's
not
nullable,
so
it
will
be
the
job
of
the
constructor
to
ensure
it's
not
valuable,
which
it
can't.
D
There's
separate
discussion
about
the
concept
of
required
init
parameters
and
then
also
default,
struct,
constructors
or
sorry,
parameter-less,
struct,
constructors,.
G
C
C
So
the
whole
point
of
having
these
option
types
is
that
you
can
initialize
the
properties
in
any
order
and
then
only
the
ones
you
care
about
which
now,
by
definition
means
the
struct
will
be
mutable
right
and
that's
usually
where
things
go,
go
bad
and
that's
why
we
don't
use
structs
now.
C
I
think
this
design
here
assumes
it's
kind
of
mutable
once
because
it's
only
using
init,
I'm
not
sure
that
that
will
hold
up,
because
that's
a
that's,
a
typical
problem
that
we
have
with
language
features
as
unless
we
actually
use
them
a
lot.
We
don't
know
yet
what
the
pitfalls
are.
So,
for
example,
within
it
I'm
I
don't
even
know
whether
f,
sharp
or
bb
honor
them
right,
so
it's
possible
that
they
just
treat
them
as
and
it's
set
basically.
D
D
This
is
the
type
of
struct
that
should
always
be
passed
by
in,
but
I
would
also
imagine
that
the
file
stream
would
end
up
just
storing
it
as
a
file
stream
options
itself
and
so
the
benefit
there
is
just
removing
in
in
direction
and
an
allocation,
rather
than
having
a
a
class
wrapping
another
class
to
access
your
string,
which
is
itself
another
class.
You
just
have
effectively
the
equivalent
as
if
the
fields
were
directly
exposed
on
file
stream.
C
So
like,
let
me
understand
what
you
just
said.
So
basically,
you
said
it
is
a
mod
rack.
That
means,
unless
I
mean
assuming
a
language,
unlike
f
sharp,
would
actually
honor
mod
racks.
It
would
mean
they
wouldn't
be
able
to
know
what
to
do
right.
They
would
basically
refuse
to
use
the
type
or
the
right.
D
D
C
D
As
long
as
the
properties
are
read
only
then
it
doesn't
really
matter
if
it's
a
class
or
struct
it's
true.
It's
just
a
question
of.
Do
you
want
to
have
a
short-lived
allocation
that
we're
going
to
immediately
throw
away,
or
do
you
want
to
have
a
long-lived
allocation?
That's
going
to
live
as
long
as
the
file
stream
does.
A
A
D
I
I
think
it's
also,
however,
not
necessarily
a
bastard
today
masterization
of
the
api,
if
in
in
most
languages
that
have
structs
versus
value
types,
this
is
the
type
of
thing
that
is
conceptually
a
struct
that
you
pass
as
in.
So
you
don't
have.
You
know
double
or
triple
in
directions,
but
that's
also
not
how
net
typically
does
things
so,
there's
like
an
a
b
side
of
the
coin.
D
C
It's
just
unusual
right,
so,
most
of
the
time,
these
option
times
are
classes
right
because
in
the
past
they
will
all
just
get
set
right,
you're
proposing
get
in
it,
which
you
know
it's
new,
so
I
I
you
know,
I'm
always
hesitant
when
we
do
when
we
use
new
language
features
in
the
vcl,
because
we
haven't
really
used
them
yet,
but
I
think
conceptually.
I
think
that
would
be
fine
right.
I
mean
I
I
mean.
C
I
think
we
have
a
tendency
to
say,
like
you
know,
does
the
allocation
really
matter
right,
because
usually
we
know
that
structs
have.
You
know
prop
usability
issues,
but
I
have
to
be
honest.
I
don't
quite
know
where
the
pitfalls
are
here,
but
using
its
extract.
So
assuming
that
init
works
the
way
we
want,
it
seems
like
it's
effectively
unobservable
for
the
user,
whether
it's
a
class
where
it's
struck,
because
you
just
knew
it
up.
C
I
A
Okay,
how
if
this
is
a
field
in
a
class
you
can
always
reassign
the
field
entirely
and
if
the
field's
being
passed
by
ref
to
the
constructor
mutations
can
be
observed.
G
D
Not
every
property,
it's
that
you
end
up
using
the
object,
initialization
syntax.
So
you
do
new
file
stream
options
and
then
you
do
the
open,
curly
brace!
Then
you
do
path,
equals
blah,
comma
mode,
equals
block,
comma
or
whatever
order
and
dropping
whichever
ones
you
want
and
then
close,
curly
brace
close
semicolon
and
then,
oh,
so
we'll
still
have
default
values
right.
F
Okay,
so
the
main
concern
is
rewriting
the
whole
struct,
which
is
the
case
where
this
instance
could
be
overwritten,
unlike
a
class,
which
is
what
we
usually
do,
even
though
we
have
an
additional
allocation,
at
least.
C
F
C
In
your
particular
proposal
here,
I
think
tanner
suggested
that
filestream
should
take
the
options
type
as
in
right.
Then
I
think
you
have
this
problem
right.
If
you
don't
take
it
as
in
then
you
just
copy
all
the
data
over
which
case
you
wouldn't
have
that
particular
issue.
That
levi
mentioned
right
right.
A
D
Oh,
it's
not
12.
This
is
more
like
64
bytes,
at
least,
but
I
I
think
it's
I
I
don't
have
a
preference
on
whether
or
not
this
is
a
struct
or
class
I'm
just.
I
was
just
trying
to
explain
the
differences
between
them.
I
think
it
mostly
comes
up
as
a
question
of
do.
We
want
to
be
consistent,
or
is
this
a
case
where,
like
asp.net
or
some
partner
is
going
to
be
like
I'm
having
to
allocate
fairly
frequently
in
a
hot
loop
with
a
lot
of
small
files
and
it's
showing
up
as
overhead?
D
Like
imagine,
you're
processing,
ten
thousand
one
kilobit
files,
in
which
case
you
might
end
up
having
lots
of
repeated
allocations.
I
don't.
D
J
A
F
K
K
D
D
C
A
A
E
D
And
so
maybe
it
needs
to
be
string,
path,
file
stream
options
and
then
optional
memory,
byte
buffer.
A
C
Yeah,
okay,
I
mean,
I
think
this
like.
I
think
the
meta
point
I
think,
is
kind
of
every
time.
Somebody
comes
a
proposal
where
they
say
I
I
I
found
a
way
to
reduce
the
locations,
the
user
structure
in
this
clever
fashion.
It
almost
always
has
usability
issues
that
we
at
the
time
either
don't
realize
or
that
that
we
should
have
realized,
or
these
are
the
trade-offs
that
are
usually
involved
right.
C
So
it's
almost
never
unobservable,
and
so
the
question
is:
is
it
worth
it
right,
and
that
is
something
that
I
personally
don't
have
a
good
handle
on,
because
I'm
not
that
much
into
low
level
perf,
but
in
general
we
have
said
in
the
past.
If
you
do,
I
o
allocating
an
object
is
usually
not
the
biggest
problem
you're
having
right,
so
the
the
that's
kind
of
why
I
would
you
know
kind
of
ask
the
question
back
like
does
this
really
have
to
be
a
struck?
C
Do
we
really
get
that
much
out
of
it
and
then,
when
you
design
it
as
a
class,
then
the
next
step
is:
what
can
I
actually
pull
this
in
some
sensible
fashion
like
we
generally
do
with
option
types,
and
then
it
becomes
just
an
exercise
of
making
sure
that
the
type
is
you
know
designed
in
such
a
way
that
you
know
you
separate
per
instance,
state
from
from
shareable
state
right.
So
that
basically
means
buffer
and
path
could
cause
regular
arguments,
and
then
the
design
as
class
might
be
good
enough.
C
D
This
was
what
came
up
in
the
last
review
was
we're
already
getting
to
you,
know
five
or
six
arguments
and
we're
at
the
point
where
it
becomes
inefficient
for
the
abi
to
handle
that
and
it's,
and
with
the
with
the
I
o,
reworking
that
adam's
working
on
we're
likely
going
to
be
wanting
to
add
more
kinds
of
configurability
and
power
options
to
these
types
and
so
file
stream
options.
Here
is
the
way
to
do
that
and
extend
that
in
the
future.
C
Options
type
yeah.
That
makes
sense,
I
think,
if
we
yeah,
I
mean
I
can
certainly
see
that
I
mean
that's,
usually
what
we
said
like
when
you
have
like
more
than
five
arguments.
You
probably
want
some
sort
of
options
type.
The
question
now
becomes,
though,
if
we,
if
you
start
doing
what
was
suggested,
where
we
basically
have
the
first
argument
being
passed,
the
second
one
being
options,
the
third
one
being
an
optional
buffer.
G
Set
of
overall
problems,
so
I
questioned
the
premise
there
so
like
this
idea
that
we
have
to
make
options
always
reusable
for
concurrent
file
streams.
If
it's
a
class
like
do
we
like
relative
to
constructing
a
file
stream
like
constructing
these
options,
I
think
is
still
you
know
as
a
class
relatively
minor,
you
can
still
pull
it.
If
you
don't
use
the
buffer,
you
can
still
use
it
concurrently.
It
is
a
usage
air
like
if
you
know
what
the
buffer
does
like.
You
know
that
you
shouldn't
be
using
the
same
buffer
for
concurrent
file
streams.
G
D
G
D
D
J
D
D
I
think
this
is
different,
because
this
is
allowing
because
the
other
api
is
working
with
the
raw
handle,
whereas
this
one
allows
you
to,
for
example,
use
a
stream
reader
with
a
custom
buffer,
which
is
a
different
type
of
advanced
scenario.
D
In
particular,
like
carlos
called
out,
you
could
allocate
a
large
native
buffer
that
memory
backs
and
then
use
that
very
advanced.
F
Like
this
was
requested
by
a
user
that
has
some
pretty
big
performance
concerns,
so
it's
not
going
to
be
commonly
used
to
answer
to
the
recent
question,
so
I
I'd
say
buffer
contains
that
inside
the
struct,
especially
since
it
it's
not
supposed
to
be
shared.
G
F
Class
yeah
that's
right,
although
we
would
remove
the
option
for
the
user
to
manage
their
own
buffer
and
allocating
it
themselves.
So
the
argument
in
favor
of
the
first
option.
The
first
proposal
is
that
it's
a
very
advanced
scenario
and
the
user
that
requested
it
explicitly
gave
an
example
where
he
they
wanted
to
use
a
memory
of
bytes.
F
Another
thing
about
the
second
proposal:
the
alternative
proposal
is:
if
the
user
does
not
use
the
enum
value
for
pull
buffer
and
we
would
continue
using
what
we
currently
have
in
our
code
right
now,
which
is
using
dc.allocate
uninitialized
array
of
byte
to
allocate
the
internal
buffer.
F
The
default
option,
if
we
use
buffering
it's
to
use
an
allocate
uninitialized
array
of
bytes.
F
K
D
And
has
its
own
issues,
which
yon
is
working
with
john,
has
an
issue
discussing
like
10
of
them
with
maoni
there's
issues
with
like
it,
not
actually
pooling
when
you
think
it
should
with
it
with
it
doing
many
with
it.
Having
way
too
many
gc
collections
that
happen
in
practice,
etc,
it
array
pool
really
needs
to
be
like
a
something
that's
tied
in
with
the
gc
for
it
to
be
what
most
people
want
it
to
be
I'll,
find
the
issue
and
link
it
in
chat,
yeah.
A
So,
as
a
concrete
example,
right
say
that
say
that
someone
has
improper
multi-threaded
access
to
a
file
stream
object,
because
you
can
read
and
write
to
them.
Concurrently,
right
in
in
certain
cases,
say
that
one
thread
is
reading
from
it.
While
another
thread
calls
disposed,
what
happens
to
the
underlying
array?
Does
it
get
returned
to
the
pool,
while
someone's
continuing
to
populate
it?
On
a
background
thread
like
now,
you
have
potentially
applied
data
corruption,
not
just.
F
H
K
A
Yeah,
that's
like
that
if
the
user
is
doing
something
silly,
that's
on
them,
but
to
be
perfectly
honest,
like
our
code
historically
within
the
framework
over
20
years,
has
not
been
resilient
against
multi-threaded
accesses
and
other
nonsense
against
doing
checks
to
make
sure
that
people
aren't
doing
that
and
as
a
result,
if
we
start
changing
global
state
within
these
methods,
we
potentially
could
cause
corruption
like
it's.
It's
a
problem
that
has
afflicted
kestrel
over
the
years.
They've
actually
gotten
a
lot
better
about
it
recently.
K
A
K
I
buy
that.
It
just
seems
to
me
that
that
whether
you
use
a
raid
pool
or
whether
you
use
array
tool,
it
seems
like
it
should
be
an
internal
implementation
detail,
and
you
know
we
do
it
right
and
properly
and
we're,
and
we
are
sure
that
that
that
we
are
not
introducing
issues
here
or
we
shouldn't
do
it
at
all.
D
I
even
had
a
pr
for
list
of
t
rejected,
which
switches
over
to
using
allocate
uninitialized
array,
because
there's
the
chance
that
a
user
is
trying
to
access
it
from
two
threads
makes
the
length
negative
one
and
then,
and
then
you
end
up
with
potential
corruption
and
and
access
and
and
the
ability
to
access,
uninitialized
memory.
That
could
contain
secrets
that
you
didn't
want
leaked
and
so
that
got
rejected.
Because
of
that.
K
F
K
K
A
Along
those
lines
right,
so
let's,
let's
look
at
the
usage
sample
what's
on
the
screen
here.
So
if
I
pass
a
backing
buffer
like
if
I
actually
pass
an
explicit
backing
buffer
to
the
file
stream,
what
does
it
use
that
buffer
for
is?
Could
it
potentially
be
using
that
buffer
outside
of
a
call
to
read
or
write
or
copy
to.
D
Yeah
anytime,
a
user
passes
in
their
own
buffer
or
says
you
are
free
to
like
take
this
array
and
use
it
internally,
rather
than
allocating
your
own
there's,
always
the
chance
that
they're
doing
something
illicit
with
it.
D
We
have
tr
we
we
have
allowed
that
in
a
few
scenarios
and
there's
cases
like
immutable
array
builder,
where
you
are
allowed
to
create
an
immutable
array
from
the
builder
using
the
internal
array
tracked
by
the
builder,
but
never
using
some
array
that
you
pass
in
yourself,
and
so
there's
like
this
balancing
act
there
that
we
that
we
have
in
most
of
the
apis.
We
expose
today.
A
Yeah,
so
what
what
I'm
drilling
in
on
on
this
usage
on
this
usage
example,
is
the
line
that
begins
using
file
stream
write
equals
new
file
stream
advanced.
So
within
those
three
lines
you
create
the
file
stream
you
call
copy
to,
and
then
you
return
the
buffer
back
to
the
array
pool
and
then
it's
some
future
part
of
the
method.
The
file
stream
instance
is
disposed,
so
the
file
stream
instance
presumably
still
owns
the
underlying
buffer,
while
the
call
to
arraypool.share.return
is
taking
place
because
the
file
stream
has
not
yet
been
disposed
of.
D
D
Right
and
and
that's
the
issue
any
time
a
user-provided
buffer
is
passed
in
and
we
don't
copy
it
it
it.
It
ends
up
becoming
a
very
powerful
and
performance
oriented
thing,
but
also
a
potentially
unsafe
and
can
lead
to
undefined
behavior
or
corruption
in
in
places
where,
for
example,
users
didn't
put
the
closing
curly
brace
around
the
using
before
the
return.
M
A
To
be
perfectly
honest,
like
the
the
way
that
certain
the
way
that
certain
other
c
style
apis
solve
this
problem,
is
you
pass
an
allocator
and
a
d
allocator
to
them
rather
than
the
actual
buffer,
so
the
the
file
stream
will
fetch
from
the
allocator
like
hey?
I
just
I
need
some
some
buffer
and
then,
when
the
file
stream
is
done,
it
will
then
return
it
to
the
deallocator.
A
D
C
C
Yeah
because
it
seems
like
the
buffer
one,
we
I
I'm
not
sure
how
much
context
you
have
versus
adam,
but
but
basically
the
question
is:
do
we
really
want
people
to
control
the
buffer?
What
could
we
do?
What
basically
jeffrey
was
saying
it's
like
well,
either
we
decide
that
right
pool
is
fine
and
we
handled
ourselves
or
we
allocate
a
buffer
inside.
But
it's
an
implementation
to
the
file
stream.
You
don't
get
to
pass
in
a
buffer.
F
Yeah
adam
has
well
more
context
than
me,
although
I
know
this
is
a
it's
a
an
advance
scenario
and
it's
meant
for
internal
use.
What
the
buffer
that
we
pass.
So
I
agree
that
if
we
want
to
leave
it
for
a
separate
discussion,
that
would
be
okay
and
we
can
now
talk
about
the
additional
attributes
that
are
mentioned.
D
That
kind
of
advanced
allocation
and
de-allocation
scenario
is
likely
something
that
isn't
just
file
stream,
but
potentially
more
like
span
where
we'd
sprinkle
it
throughout
the
bcl
in
important
low-level
core
types
like
file
stream
or
or
other
allocating
allocating
types.
And
so
we
probably
want
to
come
up
with
an
actual
like
feature
for
that.
H
F
B
A
Is
that
right,
yeah
the
locations
lies,
you
said
yeah
like
it's,
it's
not
enforced,
correct,
it's
it's
like
a
hint
and
if
the
system
can't
honor
it
well,
okay,
sure
whatever
is
that
is
my
understanding
there
correct,
because
clearly
the
api
will
work,
even
if
you
don't
specify
it
correct
the
pre-allocation
size,
yeah,
okay,
so
that
means.
Presumably,
if
you
specify
the
wrong
pre-allocation
size
at
worst,
maybe
you'll
get
a
ding
on
perf
right.
F
F
K
F
Discussion
was
adding
the
attributes
to
those
obsolete
constructors
because
they
are
the
first
ones
that
show
up
when
constructing
a
file
stream,
but
we're
not
supposed
to
use
them
the
first
one,
the
first
first
constructors
that
show
up
when
using
intelligence,
and
we
want
them
to
disappear
since
they
are
not
recommended
anymore,
and
we
were
told
that
this
is
something
that
needs
to
be
approved
here.
Adding
that
attribute
do
it.
I,
I
am
a
huge
fan
of
this
idea.
H
D
A
D
We
also,
we
also
have
other,
like
pre-allocated,
attribute
target
extension
in
asp.net
core,
which
is
lowercase
a.
D
I
went
to
source.net
ere,
isn't
the
word.
I.
D
D
A
C
C
G
A
N
D
D
C
Just
let's
just
let's
just
say
we
record
it
as
an
issue.
Jeremy
can
decide
and
let
me
let's,
let's
move
on,
because
I
want
to
burn
two
more
time
on
discussing
capitalization
rules.
F
C
So
what
I
have
right
now
is
basically
there's
no
notion
of
required
properties
for
extract
classes.
We
should
extract
path
and
keep
it
as
a
constructor
parameter.
Does
this
need
to
be
a
struct?
Structs
always
have
visibility.
Issues
in
this
api
seems
like
the
one
where
the
constructor
does
so
much
work
that
the
location
of
the
options
type
doesn't
seem
to
matter.
We
talked
about
the
peer
location,
one
we're
happy
with
the
with
the
obsoletion
one
anything
else
that
I
missed.
D
D
F
D
A
Because
I
I
see
that
there
are
some
public
constructors
that
that
takes
a
file
handle
as
a
first
parameter
and
it
looks
like
they
to
some
extent
kind
of
mirror
the
constructors
that
take
a
string
as
a
first
parameter.
A
So
I'm
I'm
just
wondering
if
again
for
consistency,
we
should
say
like
well,
if
you
have
a
save
file
handle
instead
of
a
path
like
you
can
you
can
still
pass
all
these
options,
granted
things
like
a
file
mode
and
so
on.
Don't
make
sense
at
that
point.
D
I
guess
that
there
isn't
given
that
given
what's
exposed
today,
but
maybe
there's
some
edge
case
scenario
with
the
handles
that
prevents
it
with
passed
in
handles.
A
A
Actually
no
is
async
doesn't
make
sense,
because
that's
already
a
property
on
the
on
the
handle,
probably
access
any
native
buffer
that
you
pass
in
or
any
any
memory
of
t
buffer
that
you
pass
in
assuming
we
want
to
do
that,
and
so
on.
A
D
J
Sorry,
real
quick,
the
file
stream
options.
Why
aren't
they
get
set.
C
D
If,
if
it's
a
net,
then
the
then
the
file
stream
can
safely
hold
on
to
the
options,
if
it's
not
in
it,
the
file
stream
will
presumably
have
to
create
a
copy
of
every
individual
field
passed
in
because
otherwise
they
could
be
mutated
out
from
under
it.
D
D
J
J
C
D
C
C
C
So
it
seems
like
we
have
the
notes
recorded
at
this
point
like,
should
we
approve
it,
or
should
we
just
push
it
back
with,
you
know,
use
our
feedback
if
you
like
it,
take
it.
If
you
don't
come
back.
C
Sorry,
I
I
needed
to
change
that.
Let
me
just
edit
this
guy
out
here
first
and
then
yeah
yeah.
I
would
I
would
push
to
what's
get
said
honestly.
C
So
the
argument
is,
if
you
use,
if
you
use
get
in
in
it.
Basically,
you
have
to
use
a
collection,
this
other
syntax
in
c,
and
you
most
likely
can
only
use
c
sharp
to
begin
with
right
now,
because
f
sharp
is
still
getting
it
and
vb
probably
will
never
get
it.
So
basically,
you
just
exclude
languages
now.
C
The
question
is:
is
there
any
benefit
in
it
only
and
it
seems
like
the
constructor
will
very
likely
either
already
copy
the
data
into
fields
anyway
or
immediately
forward
it
to
some
call
that
it
doesn't
require
them
to
hold
on
to
them.
So
you
actually
hold
on
to
the
option
types,
and
I
think
the
answer
is
probably
no.
K
C
So
I
mean
yeah.
We
should
look
into
this.
I
mean
this
is
the
problem
with
language
features.
Right
I
mean
unless
we
know
exactly
what
the
downsides
are
on
using
them,
it's
hard
to
say
yeah.
Let's
add
it
to
an
api
right
because
it
seems
problematic
to
you
know.
As
eric
said,
you
get
fancy,
but
then
you
accidentally
exclude
a
large
chunk
of
the
customer
base
about
realizing
it.
D
At
the
same
time,
if
we're,
if
we're
consistently
sticking
with
you
know,
syntax
from
you
know
20
years
ago,
and
that
only
languages
that
are
no
longer
updating
themselves
can
can
support,
then
we're
going
to
end
up
with
a
with
a
modern
language.
In
a
very
non-modern
vcl
I
mean
that's.
C
C
You
know
the
question
is:
is
it
worth
it
to
do
that
right
like
how
much-
and
I
think
in
this
case
the
question
really
is
even
if
we
were
to
say
oh,
we
really
like
immutable
types
right,
but
does
it
does
it
actually
do
anything
like
if
it
actually
buys
you
something?
I
think
it's
fine,
but
if
it
doesn't,
then
I
don't
know.
C
Easier
is
easier,
yeah
but
yeah
all
right.
Let's,
let's,
let's
keep
that
for
now
and
then
you
know
adam
can
tell
us
what
he
thinks,
I'm
pretty
sure
he
will
have
opinions
and
then
we
probably
have
to
talk
about
the
buffalo
one
separately.
Anyways.
C
J
C
C
Right,
thank
you.
Teams
for
stopping
to
present
you
just
switched
okay,
never
mind.
F
C
Is
switching
windows
on
me?
Yeah
go
ahead.
O
So
we've
checked
in
the
first
version
of
the
system,
json
search
generator,
which
takes
the
approach
of
moving
the
metadata
gathering
about
types
that
we
do
on
first
reaction
on
it
of
a
type
from
runtime
to
compile
time,
and
that
gives
some
benefits
like
reducing
the
amount
of
time
it
takes
to
start
up.
Apps
reduce
private
bytes
and
improve
app
size.
O
Another
goal
we
have
for
social
mission
and
6o
is
to
improve
serialization
and
digitalization
throughput,
and
this
api
is
proposing
to
help
us
have
a
mood
in
the
search
generator
where
we
can
generate
serialization
code.
This
realization
is
also
been
discussed
for
six
years
as
well,
but
it's
not
including
this
problem
at
all,
and
just
because
of
scope
and
like
the
transition
is
a
bit
less
trivial
than
well.
O
Let's
show
you
the
dance
realization
due
to
things
like
property,
lookup
and
other
like
technical
scenarios,
but
I
just
wanted
to
mention
that
so.
F
O
Api
proposal,
so
starting
with
the
json
type
in
40,
we
already
have
this
type.
So
all
that's
done
currently
is
just.
O
It's
abstract,
so
users
can
instantiate
it,
so
the
only
member
will
have
on
it.
Here
is
an
action
which
will
take
a
useful
feature
generator
and
an
instance
of
a
type
to
serialize,
and
the
social
network
will
provide
an
implementation
which
honors
some
predetermined
options
indicated
at
runtime,
so
that
leads
to
the
next
type
here
adjacency
options,
attributes
which
directly
maps
with
some
a
subset
of
the
types
we
have.
I
mean
the
options
we
have
adjacent
series
options
which
the
only
ones
included
here
are
ones
that
we
can
actually
support.
O
I
mean
we
where
we
want
to
generate
code
for
those
scenarios,
so
features
that
are.
O
Features
that
are
feasible
to
to
generate
our
source
code,
for
so
first
of
which
is
like
the
default
signal
condition.
You
know.
When
should
we
ignore
properties
on
civilization
like
when,
when
or
when
default
ignorantly
feels
saying
if
a
field
is
really
don't
realize
it
on,
don't
include
it
for
serialization.
O
So
again
we
have
that
on
decentralized
options
itself,
ignorantly
properties
similar
but
for
properties
ignore
runtime
custom
converters
here
allows
us
to
not
generate
codes
that
so
today
we
generally
call
that
checks
whether
custom
converters
have
to
be
honored,
but
this
can
allow
us
to
remove
that
check
and
also.
F
O
That
we'll
see
later,
but
it
just
basically
tells
us
like
what
is
the
naming
policy
to
be
used,
and
the
only
things
that
we
can
express
here
are
things
that
are
that
we
know
the
implementation
for,
like
the
the
built-in
camera
case,
policies
near
the
ocean,
for
that.
O
C
I
love
you
guys.
Can
I
have
a
quick
question,
so
they
so
you're
proposing,
basically
that
these
options
are
applied
at
the
assembly
level
right,
so
they
are
kind
of
all.
My
types
that
are
sterilized
in
that
assembly
will
use
the
same
serializer
options
right
so
they're,
basically
globally
defined
ones
right.
O
To
be
able
to
for
first
part
purposes,
it
would
only
be
this
set
of
options
that
will
generate
selection
code,
for
if
you
use
the
different
options,
instance
at
runtime
we'll
have
a
check
to
see
whether
we
can
use
the
first
part
whether
the
options
are
compatible.
If
they
are
not,
then
we'll
go
back
to
just
using
the
serializer.
So
you
still
in
that
scenario,
you
would
get
all
the
benefits
of
like
all
the
other
benefits
apart
from
throughput,
because
just
realize
I
would
not
be
calling
this
generator
code.
So
just.
O
So
at
the
start
of
serialization
we'll
check
the
values
on
the
options
instance.
So
if
and
then
we
can
compare
some
of
the
values
quickly.
J
O
No,
we
will
have
yeah,
so
today
we
have,
with
the
context,
class
or
type
will
have
an
internal
property
that
tells
us
appropriately
an
options
property
that
tells
us
what
the
expected
first
part
options
will
be.
So
internal
industrializer
will
read
that
information
from
there
so
and
we'll
generate
the
will
generate
the
value
of
that
options.
Instance
at
doing
so
generation,
so
so
we'll
actually
have
an
options.
O
Distance
to
compare
against
so
we'll
now
be
doing
it
with
reflection
at
the
runtime
and
optimize
like
we
can
look
into
computing,
some
sort
of
hash
to
see
to
make
the
comparison
faster
than
attributing
through,
like
these
members
on
the
options
instance,
but
it
should
one
one
time
check
on
on
at
the
start
of
serialization,
so
it
should
be
it's
not.
It
shouldn't
be
a.
O
M
For
for
certain
things,
like
the
naming
policy,
it
is
possible
that
we
generate
code
that
can
dynamically.
You
know,
pull
the
option
or
pull
the
naming
policy
off
of
the
json
serializer
options
and
call
that
but
you're
proposing
that
would
actually
generate
the
the
lower
level
code
for
the
policies
that
we
know
about.
In
this
case,.
O
E
C
And
one
thing
that
I
I
have
to
say
that
I'm
not
super
keen
on
is
that
you
effectively
constrain
the
source
generation
to
one
json
context
per
assembly,
because
that
seems
also
somewhat
arbitrary
right.
It
doesn't.
You
could
still
have
a
fast
path
and
just
allow
multiple
json
contacts
right,
because
it's
like
the
fastlab
is
just
a
function
of
you
having
the
static
information
and
being
able
to
spit
out
the
code
right.
A
I've
I've
seen
some
other
serialization
techs,
allow
you
to
specify
it
at
name:
space
granularity,
not
necessarily
assembly
level,
granularity
to.
C
So
the
model
that
I
have
in
mind
is
that,
instead
of
you
just
spitting
out
json
context,
you
could
imagine
that
the
user
has
to
define
the
json
context
type,
give
it
a
name
right
and
then
put
you
know.
Instead
of
putting
the
assembly
level
attributes,
you
put
all
the
json
theorizer
attributes
on
that
type,
and
then
you
basically
spit
out
the
body
of
that
type.
In
which
case
I
can
have
json
context,
one
json
context,
two
json
context:
three.
They
can
have
completely
disjoint
options,
and
you
know
if
I
just
want
one.
C
I
get
one.
If
I
want
four,
because
I
have
different
contexts,
it's
pretty
straightforward
for
me
to
do
that
right,
but
right
now
in
your
design.
Basically,
I
would
have
to
literally
create
a
separate
assembly
just
so
that
I
can
have
naming
policy
a
enabling
policy
b
right
or
one
has
read
only
fields,
one
doesn't
or
something
right
and
like
it
wouldn't
really
change
anything.
It
would
just
mean,
instead
of
having
it
basically,
instead
of
you
just
magically,
you
know
creating
the
entire
time.
C
The
user
only
has
to
define
effectively
the
you
know
the
type
header
and
then
apply
the
attributes
on
that
type.
That
seems
a
little
bit
more.
I
think,
in
line
with
how
sterilization
generally
works,
because
the
idea
is
that
you
have
these
options
that
are
specific
to
a
call
side
and
with
the
source
generation.
You
allow
the
user
to
have
as
many
call
sets
as
they
want
for
assembly
and
and
it's
a
bit
more
straightforward
than
to
say
oh
yep,
you
can
only
have
one
one
option
for
the
entire
assembly.
O
C
I
mean
that's,
I
mean
that's
a
legitimate
concern
right
because
I
mean
you
would
have
to
create
a
third
type.
Somehow
right
to
that,
you
can
reference
from
both
right.
I
know
the
questions.
How
does
the
user
define
that
right?
But
I
guess
that's
just
the
way
it
is.
I
mean
I
think
yeah
I
mean
code.
Bloat
is
certainly
a
concern
that
is
worthwhile
thinking
about.
O
C
Yeah,
basically,
you
say
on
in
on
this
context.
I
want
to
basically
you
know,
you
know
this
is
basically
the
home
for
all
the
pre-generated
serializers
and
you
apply
all
the
attributes
on
that
type
for
the
things
you
want
to
be
generated
into
that
type
right.
So
I
think
that's
kind
of
the
I
think.
That's
generally,
the
kind
of
the
pattern
of
most
source
generators
is
that
the
user
defines
the
method
or
the
type
and
then
somehow
annotates
that,
with
you
know,
to
be
filled
out
by
a
generator
right.
H
O
C
Yeah
I
mean
what
I
like
about
this
approach
in
general.
Is
that
you
give
the
user
way
more
control
right
you?
Basically
let
them
control
like
all
the
normal
things
they
may
want
to
control
like
what
namespaces
type
get
generated
in.
What's
the
name
of
the
type
is
the
name?
Is
the
type
public
or
not
right?
All
these
things
are
trivially
configurable,
because
the
user
literally
typed
it
out
right.
So
there
really
isn't
any
magic
thing
on
the
side
that
you
have
to
invent
of.
You
know:
okay,
how
does
the
user
control
the
type
name?
C
Oh
there's
this
other
attribute
that
I
can
apply
on
my
assembly
that
controls
the
name
of
the
type
or
something
like
that,
and
then
you
just
duplicate
effectively
what
the
shop
can
already
do
by
just
typing
all
characters
right.
C
I
mean
I
don't
think
it
would
change
all
any
of
your
concerns,
because
I
mean
you
still
have
this
problem
that
you
have
to
somehow
describe
the
option.
Statically
right,
which
is
what
your
attribute
does
and
I
think
yeah
there
is
this
unfortunate
duplication
between
you
know
the
current
sales
options
and
this
new
attribute,
but
I
don't
know
what
else
to
do
because
yeah
we
you
clearly
don't
want
to
ask
the
options
at
runtime
and
then
generate
code
for
every
possible
configuration
option
right.
A
Well,
along
those
lines,
if
I'm
using,
if
I'm
using,
not
source
generators
like-
and
I
specify
this
attribute
at
the
assembly
level
like
what
happens
when
I
call
jason's
serializer
dot
whatever
it
looks
like
if
I'm
reading
the
description
correctly,
it
is
in
fact
honored.
O
It
is
not
okay,
it
wouldn't,
unless
we
wanted
to
have
a
design
around
that,
I
think
the
user
has
talked
about
that
before,
but
I
couldn't
think
of
a
scenario
where,
like
I
mean
where
you
want
to
do
that,
runtime
so
I
mean
I
guess
it's
an
open
question
to
say
like.
A
I
guess
two
two
thoughts
on
that
like
first
it
it
seems
like
it
would
be
weird
if
one
api
respected
it
and
the
other
api
didn't
just
from
a
consistency
standpoint,
but
I
mean
you,
you
clearly
understand
the
scenarios
better
than
I
do.
The
other
thing
that
I
wanted
to
call
out
is
naming
an
attribute
class
the
same
as
the
name
of
another
type
in
the
framework.
In
this
case
json
serializer
options
we
might
run
into
conflicts
there.
A
You
can
imagine
that
if
I'm,
if
I
declare
a
json
serializer
options
attribute
instantiation
in
a
file
somewhere,
I
might
also
be
importing
the
system
text
json
namespace,
all
up
within
that
same
file,
and
now,
like
I
have
two
things
that
are
basically
called
json
serializer
options,
because
the
attribute
suffix
is
alighted,
I'm
pretty
sure
the
compiler
can
figure
this
out,
but
I
think
it
is
confusing
to
people
we
might
want
to
call
it
like
jason
serializer
option
defaults
or
something.
C
Well,
I
think
I
mean
it
is,
I
think
in
many
cases
they
actually
desired
right.
So
the
like
what
comes
to
mind
here
is
good
right.
You
have
to
go
in
type
and
you
have
a
good
attribute
and
it
kind
of
makes
sense
to
name
them
the
same,
because
they're
kind
of
describing
the
exact
same
thing.
I
think
the
problem
here
is
that
they
are
not
really
describing
the
same
thing
right.
C
Like
I
mean
yes,
they
are
both
options,
but
the
the
shape
of
the
json
serializer
options,
type
that
we
have
today
is
fundamentally
different
from
the
attribute
right,
because
one
of
them
is
a
dynamic
extensible
system
where
you
can
put
in
converters-
and
you
have
you
know,
polymorphism
of
the
naming
policy
and
other
stuff
which
this
one
just
fundamentally
can't
have.
So
it
seems
to
me
like
yeah,
I
mean
I
don't
think
the
duplication
is
necessarily
bad.
C
If
this
would
just
be
an
orthogonal
thing,
I
think
having
the
same
name
is
fine,
because
levi
said
the
compiler
can
figure
it
out.
But
I
I
don't
like
the
idea
that
you
know
to
the
earlier
question
of
like
what,
if
I
apply
this
assembly
level
attribute,
and
I
only
use
the
reflection
path.
C
You
know
looking
at
the
code.
Is
that
obvious
to
me,
because
the
name
is
jason
sealizer
options,
it
doesn't
really
shout
like
generation
or
yeah
or
or
whatever,
but
I
mean
that
was
my
other
question
earlier
like
should
we
actually
consider
having
a
namespace
that
is
more
dedicated
to
generation
where
we
can
say,
here's
all
the
stuff
that
you
use
for
source
generation,
because
it's
it
is
unfortunately,
in
many
ways
like
you
know,
an
alternative
way
to
do
the
serialization.
You
have
to
call
different
apis.
C
You
have
to
use
different
things
to
configure
that
and
then,
if
you
create
this
overlap,
you
kind
of
muddy
the
waters
again
for
the
users
and
then
I
can
totally
see
people
having
confusion
where,
like
oh,
I
put
this
attribute
on
my
assembly.
But
you
know
when
I
do
serialization,
it
still
doesn't
honor
them,
and
it's
like
well
yeah,
because
you
do
reflection-based
civilization.
That's
why
it's
not
all
hard
right.
It's.
A
C
Kind
of
I
mean-
or
we
just
say
you
know
the
at
least
you
don't
want.
I
mean
to
your
point
right:
it's
really
bad
if
the
type
name
is
the
same
because
you
kind
of
explicitly
say
they're
related,
but
they're,
really
not
yeah,
so
I
mean
I'm
okay
with
like
jason
sealizable,
even
though
it
doesn't
say
source
generation
like
it's.
You
know,
if
were
the
name
space
that
it's
kind
of
like
I
don't
know,
system,
text.json,
dot,
civilization,
dot,
generator
or
something
right,
and
then
we
put
all
the
stuff
in
there.
O
So
I
know
it's
definitely
something
that
we
want
to
consolidate
like
the
the
efforts
and
the
namespaces
this
so
like
after
that
work
is
done,
then,
why
we
clear
a
picture
like
what
stuff
is,
like
you
know,
general
metadata,
apis
and
what
stuff
is
specifically
for
search
generation,
and
I
think
it
makes
sense
to
move
things
around
on
the
so
there's
our
options
and
we
need
the
attributes.
O
It's
a
bit
difficult
because,
like
what?
How
do
we
instantiate
those
options
at
runtime
like
we?
Don't
want
it
to
replace
the
default
options?
The
that
we
use
within
systematic
system,
because
the
aspects
are
that
simply
so
would
somehow
have
to
generate
an
optional
resistance.
That
has
the
same
value,
and
this
is
outside
of
the
search
chain
like
work
and
somehow
tell
the
user,
where
the
options
instance
would
live
and
that
they
should
pass
it
sincerely
like
it
doesn't
seem.
F
C
H
C
I
mean
you
could
say
that
if
you
you
know,
if
you
generally,
I
mean
the
json
context
that
you
spit
out
could
have
either
property
or
method
that
basically
creates
options
that
match
the
assembly
level,
attributes
right
and
then
that's
the
way.
You
would
acquire
that
if
you
wanted
to
right
but
yeah,
you
should
not
change
the
default
options.
Of
course,
so
yeah.
C
C
Another
concern
is
like:
if
we,
if
we
say
you
can
get
adjacency
as
options
instance,
somehow,
out
of
this
attribute
you're
also
kind
of
making
a
statement
that
one
is
a
strict
subset
of
the
other
right,
which
we
may
not
be
able
to
do
right.
So
I
can
totally
see
a
world
that
we
have
options
that
affect
source
gen,
that
we
can't
honor
at
one
time,
because
it's
too
late
or
something
right
or
the
shape,
is
fundamentally
different
right
and
then
it's
kind
of
backwards
again.
M
C
J
H
M
But
but
this
is
how
most
I
think
apps
will
work,
they
will
new
open
options
and
you
can't
change.
The
options
are
immutable.
One
serialization
or
deserialization
has
occurred,
so
they
are
effectively
locked
and
I
think
that
yeah,
if
you're,
calling
an
external
service
and
they
have
a
different
naming
policy.
For
example,
there
are
cases
where
you
have
to
do
up
a
different
options
today,
but
I
think
for
your
own
code,
especially
one
options.
Instance,
you
know
sufficient.
J
O
M
If
you
have
types
that
mix
and
match
between
that,
I
mean
you
know:
class
a
has
a
property
that
exposes
class
b
and
class
b
is
in
another
assembly,
and
and
now
we
say
you
have
to
have
two
context
classes
for
that.
You
know
that
does
affect
the
high
level
programming
model
if
you
need
different
options
for
for
the
two
different
contexts,
because
today
we
have
a
single
context:
class
that
that
you
know
one
universe
with
the
same
options.
Essentially.
C
Well,
I
think
that
would
be
unchanged
right.
We
would
just
say
you
can't
have
more
than
one
universe
in
a
given
assembly,
but
yeah
within
that
universe.
You
can
only
have
one
set
of
options
still,
so
you
can't
really
have
a
case
where
you
know
within
one
json
context,
one
type
uses
pascal
casing
and
one
pi,
one
set
of
types
uses
camera
casing
right.
C
Right
which
we
I
mean,
I
mean
we
can
do
that,
but
that
only
really
works
if
you
own
the
type
right.
So
this
idea
today
that
you
can
apply
the
attribute
to
type
from
another
assembly
that
would
get
complicated
if
you
can
now
apply
it
to
members
of
that
type,
because
now
you
know
you
end
up
in
this
world
where
you
have
like
in
this,
you
know
type
level.
A
Yeah,
that
makes
sense,
because
imagine
a
scenario
like
you
know:
let's
just
throw
something
out
there:
azure
sdk
right.
They
have
model
types
probably
spread
out
across
multiple
different
assemblies
and
those
types
might
have
different
canonical
ways
of
serializing
themselves.
Like
you,
don't
want
an
attribute
in
assembly
a
to
affect
how
a
type
from
assembly
b
is
serialized
because
it
might
have
its
own
generation
code
already
baked
in
right.
C
Yeah,
I
guess
that's
fair,
I
mean
yeah,
I
mean
maybe
yeah.
Maybe
that's
the
way
we
do
it
then,
and
and
there's
a
semi-level
actually
would
now
be
applied
to
the
json
context
that
the
user
owns.
But
it's
still
the
same
concept
right.
You
just
say:
here's
you
refer
to
another
type,
maybe
a
member
and
say
here
are
some
utilization
specific
options
and
then
yeah
I
mean
that
might
not
be
a
bad
model.
F
J
O
O
J
Yeah
I
actually
like
this
design
even
more
now
that
I'm
thinking
about
it,
because
one
of
the
things
that
I
don't
like
about
using
the
json
source
chin
is
that
it
just.
I
have
to
magically
know
that
there's
this
dot
source,
gen
namespace
and
I
have
to
magically
know
that
there's
a
json
context
type
in
there
right
like
it's.
J
I
have
to
make
a
mental
leap
like
I
put
these
assembly
level
attributes
on
and
now
I
just
magically
know
that
there's
some
other
type
there
where,
if
we
did
make
this
more
like
partial
class
based
yeah,
not
partial
class
for
all
the
types,
but
at
least
that
top
level
type
that
json
context
top
level
type.
I
can
put
my
in
my
own
name
space.
I
can
name
it
what
I
want
to
name
it,
and
now
we
just
generate
a
bunch
of
stuff
into
that
partial
class.
M
And
fyi
lambie
did
have
some
additional
material
that
he's
not
covering
today,
which
does
talk
about
even
other
ways
to
do
that,
for
example,
applying
an
attribute
to
a
serialized
method
and
that
serialized
method
would
would
the
body
would
be
generated.
I
mean
it,
it
does
allow
us
to
do
whatever
we
want
in
a
way
if,
if
we
just
kind
of
fill
in
the
blank,
you
know
pattern.
C
Now
I
mean
yesterday
at
the
community
stand
up
and
we
talked
about
source
generation.
I
mean,
I
think,
the
the
basically
the
the
number
one
thing
that
we
have
here
right
now
is
basically
that
the
generator
generates
new
code,
and
I
think
it
is
desirable
that
the
user
controls
the
place
where
that
code
goes
right,
because
there's
just
too
many
ways
you
could
do
that
right
as
public
is
it
internal?
Is
it
in
this
name
space?
Is
that
type
or
whatever
right?
C
You
know
code
goes
here
right
and
you
know
if,
if
nothing
gets
filled
in
then
you
know
it's
obviously
a
compile
time
error,
because
you
know
you
know
no
type
info
code
generated
most
your
last
method
go
generated
and
the
compiler
will
tell
you
that
sorry
there's
something
missing
here
right,
so
you
get
still
the
same
kind
of
thing,
but
you
don't
have
to.
I
mean
you
still
discoverability
issues,
because
people
have
to
know
to
you
know
type
in
that
type
name
and
apply
these
attributes
on
them.
C
E
J
You
have
to
add
my
not
only
that
also
a
thing
that
vtec
pointed
out
to
me
is
that
when
you
use
the
source
generator,
if
I
give
somebody
code,
I'm
like
hey
here,
use
this
code
and
they
put
it
into
their
app.
It
doesn't
work
by
default
because
if
their
app's
not
named
the
exact
same
thing
as
mine,
then
the
usings
don't
line
up
right.
O
Okay,
so
in
this
case
the
metadata
approach
allows
you
know,
options
like
an
options
instance,
which
can
contain
configuration
that
is
not
represented
here
and
and
that
you
know
that's
the
fallback
where
we
use
the
serializer
for
like
reference
handling,
and
things
like
that.
O
So
I
I
do
believe
still
that
we
need
to
provide
a
way
to
have
people
pass
it
unless
we
want
to
represent
even
things
that
are
not
supported
in
this
like
in
this
mode,
fastpass
mode
in
the
design.
Time
attribute.
J
O
O
O
J
O
M
M
J
O
Okay,
the
other
thing
is
the
serializable
types
should
different
context.
Types
have
different
like
inputs
to
their
like
type
type
closure
like
say
today
is
specified
on
the
assembly
type
and
then
that's
assembly
wide
like
for
context.
We
want
to
have
different
types
that
we
generate
sterilization
and
metadata
for.
J
That
I
don't
have
an
answer
for
right
away.
I
don't
know
I
could
see
us
going
both
ways,
I
guess,
having
the
assembly
level
json
serializable
or
on
each
context.
You
have
to
say
I
want
type
customer
type,
address
type
order
on
this
context
and
type
product
on
this
context
that
that
I
don't
know
yeah.
C
I
would,
I
would
honestly
say
I
would
say:
let's:
if
we
go
down
this,
you
know
we,
the
user,
always
types
in
the
context
type.
I
would
apply
all
attributes
there
and
say
there
is
no
global
fallback
like
it's
on
that
side
and
if
you,
if
you
need,
if
you
have
three
contacts
and
you
want
the
same
configuration,
I
will
start
with,
you-
have
to
copy
and
paste
it
for
now,
because
I
think
otherwise,
you
just
have
a
more
complicated
policy
where
the
type
is
no
longer
self-describing
right.
C
It's
it's
the
union
between
what's
on
the
type
and
what
did
you
apply
the
assembly
or
module
level
or
whatever
right
and
it
seems
more
complicated?
I
would
start
with
a
simple
thing
where
you
know
the
user
types
in
the
json
context,
type
that
defines
the
whole
universe
and
all
the
configuration
is
on
that
type.
O
Well,
one
of
the
one
of
these
ability
things
at
the
assembly
level
just
insulated.
The
activity
was
that
you
have
to
like
specify
all
of
them
at
the
top
of
your
project
and
scroll
back
and
forth,
and
you
know
copy
the
name.
So
that's
why
we
had
the
attribute
on
the
type.
Would
you
want
to
keep
that
in
that
mode.
O
O
Text
yeah
this
realizable
type,
so
we're
putting
the
we
have.
So
we
had
an
adjective
yeah
so
yeah.
We
want
to
still
have
that,
and
that
would
mean
that
for
all
your
context,
types
that
that
would
contain
that
type
as
well
or
they
still
want
to
actually
just
be
on
the
context
and
not
have
it
on
the
type.
C
I
mean
that
one
makes
more
sense
to
me
because
that's
kind
of
I
mean
I
mean
that's
my
general
question
of
like
you
know
the
existing
attributes
that
we
have
like
json
property
name.
For
example.
I
assume
you
honor
those
right
in
the
generator
right
so
sorry
say
it
again,
so
the
existing
attributes
that
we
have
like
json
property
name
for
example,
that
you
can
put
on
a
on
the
property
right.
I
assume
you
honor,
those
in
the
source
generator
already
right.
That's.
O
C
J
So
if
we
went
down
that
approach,
when
we
source
gin
for
adjacent
context
in
an
assembly,
we
would
at
design
time
we
would
look
for
the
other
types
in
that
assembly
that
have
json
serializable
attributes
on
them
and
we'd
stick
those
in
there
as
well.
So
again,
in
the
case
where
I
have
three
json
contacts
and
then
one
class.
F
C
C
That
makes
sense.
So,
for
example,
let's
say
you
have
a
person
type
right
and
the
person
type
has
the
first
name
and
last
name
property,
and
each
of
them
have
this.
Json
property
name
applied
to
them
right
then,
but
you,
but
you
want
the
person
to
be
in
json
context
and
json
context
b.
I
still
think
in
both
json
context.
You
would
have
to
either
apply
an
attribute
that
says
I
want
person
a
or
you
include
some
other
type
that
happens
to
transitively
reference
person
a
or
person
b.
J
N
Class,
I.
C
J
C
H
O
H
O
So
we
have
just
no
name
policy
from
the
attribute
above
so
yeah.
We,
I
call
it
no
name
policy
to
say
like
the
source
generator.
We
need
to
know
what
implementation
is
like.
You
can't
pass
a
type
of
json
naming
policy
because
it
cannot
like
light
up
that
type
and
like
execute
the
convert
method.
So
it
has
to
be
something
we
know
what
implementation
is.
So
that's
why
I
say
either
on
specified
or
built-in
camera
case.
H
M
M
M
O
M
C
A
O
C
Yeah
I
mean
I
don't
have
a
strong
problem
with
the
naming
policy
being
unextensible,
but
it
does
seem
a
bit
weird
that
the
only
one
that's
listed
here
is
building
camera
case.
When
you
know,
as
you
said,
pascal
case
is
trivial.
It's
just
don't
do
anything
like
I
I
at
least
it
seems
desirable
to
list
the
three
ones
or
whatever
that
we
have
built
in
support
for
right.
M
M
Open
up
the
question
like
the
discussion
around
all
of
these
bulls
and
and
naming
policies,
and
whatever
are
they
completely?
You
know
100
always
static,
or
do
we
want
to
loosen
that
up
in
certain
cases
like
if
we
don't
know
the
naming
policy,
for
example,
you
know,
and
that
can
always
that
decision
could
come
later.
I
think
and
then
we
could
add
some
conditional
logic
and
some
caching
logic
to
handle
some
of
these
cases.
M
C
I
mean,
if
I
had
it
my
way
I
would.
I
would
really
try
to
get
everything
statically
describable
and
if,
for
example,
you
want
the
user
to
extend
it,
I
would
come
up
with
an
attribute
way
to
extend
it,
but
in
a
way
that
the
user
statically
tells
you
oh,
I
want
xml
to
be
all
lowercase
and
I
have
to
apply
an
attribute
that
says
you
know
name
mapping
and
then
pass
into
strings
or
something,
but
because
otherwise,
as
soon
as
you
open
this
up
to
polymorphic
extensibility,
it
just
gets.
C
J
C
And
I
really
think
you
want
to
know
the
string
at
the
mid
time
right
because
that
that
really
opens
up
your
way
to
do.
You
know
interesting
things
like
dictionaries
that
you
can
generate,
and
you
can't
really
do
that.
Really,
when
you
don't
know
the
names
until
runtime,
and
I
think
the
other
question
really
is
is
like
what
do
you
do
with?
C
I
think
you
probably
have
to
assume
people
want
to
control
the
names
more
right,
because
that's
the
way
like
things
are
being
emitted
sometimes,
but
I
I
think,
if
my
assumption
would
be,
if
people
want
to
extend
it,
we
would
have
to
find
a
way
to
do
that.
Statically
and
I
think,
that's
still
fine.
I
think
you
can
still
contrive
of
schemes
that
would
not
hurt
the
fast
path
you
just
make
the
compile
time
potentially
slower,
because
you
have
to
do
more
metadata
lookups,
but
who
cares
right?
The
runtime
would
still
be
super
fast.
C
O
Okay,
so
yeah,
let
me
talk
about
it
so
today,
like
the
assumption
is
so
the
way
it's
working
is
today.
This
search
generator
generates
only
metadata
for
types,
and
now
we
are
having
a
mode
where
we
can
generate
a
fast
path
code.
O
So
if
the
json
realizer
options
attribute
is
used,
then
that
tells
us
like
my
proposal
is
that
we
should
generate
metadata
and
serialization,
so
we
generate
the
fastpass
logic
and
also
the
metadata
for
object.
Properties
like
I
mean
object
members,
so
we
should
do
both.
So
this
provides
a
way
to
say
hey.
I
know
I,
wouldn't
I'm
not
going
to
need
a
fallback
at
runtime,
so
I
can
see
I
can
set
the
mode
for
it,
for
a
type
to
sterilization.
O
So
default
is
metadata.
Serialization,
saying
that
if
there
is,
if
there's
a
distance
realized,
I
mean
adjacent
serializer
options
used.
Then
that
tells
us
what
like
that
that's
the
option
for
fastback
right.
So
if,
if
no
properties
are
set,
then
that
means
default
options
if
properties
are
set
and
those
are
the
values
so
do
both.
Then
metadata
only
says
like
hey,
I
know,
fastpass
is
never
going
to
work
and
I
don't
want
more
code
just
generate
the
metadata
so
when
they
are
configurable
and
type
type
pieces
and.
H
C
J
J
O
No,
I
don't
think
that
there's
any
there's
no
options
configuration
here
that
we
cannot
generate
source
code
for
so
I
don't.
I
expect
that
if,
unless
metadata
is
like,
unless
the
mode
is
set
to
metadata,
I
expect
that
we
always
generate
this
realization
code.
M
J
H
C
C
C
Well,
I
mean
I,
I
guess
the
question
is
now
like
what
is
the
the
the
set
of
scenarios
for
which
we
support
source
gen
4
right
and
that
you
know
there's
certainly
some
mvp
aspect
to
it,
where
we
could
support
more.
We
just
haven't
written
the
code,
so,
for
example,
indented
to
me
seems
like
something
that
we
could
trivially
support.
C
It's
just
more
code
versus
other
things
like
custom
converters
might
be
super
complicated
right,
and
so
we
might
never
support
them
right,
and
so
the
question
is
now
like:
where
do
we
see
this
right?
Because
I
mean
we
had
this
discussion
a
few
weeks
ago
right
where
jan
was
saying,
maybe
we
should
just
say
like
you
know,
we
have
the
super
simple
dynamic
system.
That's
reflection
based
supports
everything,
and
then
we
have
this.
You
know
more
optimized
thing
and
that
only
supports
the
subset
and
there
really
is
no
middle
ground.
It's
like
you.
A
I
think
that's,
I
think.
That's
okay,
though,
because
for
instance,
some
some
of
the
examples
that
came
up
were
custom,
converters
or
name
like
custom
naming
policy
stuff
like
that.
That's
not
reflection.
Based
at
that
point
like
we
actually
have
a
target
method
to
call
into
that.
We
know
a
compile.
Time
like
we
could
literally
just
emit
calls
straight
to
those
methods.
O
Yeah,
I
mean
so
those
features
yes,
but
the
scenarios
where
folks
are
using
this
serializer
in
non-trivial
ways
like
non-trigger
features
like
async
and
like
other
features.
Async
is
probably
like.
Maybe
the
most
compelling
one
in
this
discussion,
our
custom,
converters
or
converters.
Here
we
can
support
support,
async
like
we
don't.
We
want
to
generate
like
a
sync
code
that
does
all
the
buffer
management
and
like
moving
on
and
green
and
things.
F
O
F
C
This
is
like,
I
guess
what
I'm
struggling
with
is.
I
don't
understand
the
like.
I
guess
that,
because
it
also
was
eric's
question
of
like
what
is
the
like.
If,
if
I,
if
I
use
this
like,
why
would
I
ever
be
unhappy
with
the
option
sealization?
Why
would
I
ever
have
to
use
metadata
and
sterilization
or
metadata
to
actually
get
stuff
to
work?
O
If
you
are
using
one
of
the
so
I
think
I
later
in
this
issue,
I
show
what
features
will
be
supported
or
not.
So
the
answer
is
like.
If
you
care
about
one
of
the
features
that
will
not
be
supported
generated
code,
then
you
wouldn't,
we
would
need
to
have
like
metadata
and
serialization
or
or
just
metadata.
C
Maybe
we
should
talk
about
that,
because
I
think
it
would
be
helpful
for
us
to
understand.
Is
this
just
a
point
in
time
of
us
not
having
having
typed
in
the
code,
or
is
that
a
conceptual
you
know
without
us
emitting
some
metadata
or
something?
We
just
can't
do
it
at
one
time
situation,
because
then
one
of
them
is
just
yeah.
You
know
we
only
have
features
that
acts
today
and
we're
okay
with
that
and
we
ship
that
and
the
other
one
is
like
okay.
C
We
we
really
have
to
make
a
decision
on
like
how
important
do
you
think
these
scenarios
are
people
that
use
the
source
gen,
because,
basically
to
me,
I
I
I
still
would
like
to
live
in
a
world
where
the
the
the
generated
json
stabilizer
is.
Is
you
know,
I
guess
simple
code
as
and
you
open
it
in
a
reflector
and
like
you
look
at
it
and
it
looks
nice
and
fast
and
efficient,
and
but
also
the
the
feature
is
usable
enough
that
the
vast
majority
of
our
people
could
use
it
if
they're
willing
to
change.
C
O
Yeah
my
my
hunter,
my
feeling
about
this
is
that
if
we
don't
have
so
there
are
some
features
that
we
would
that
we
could
support
in
future
like
converters
encoder
things
like
that,
possibly
some
things
like
async
and
reference
handling
would
be.
You
know
to
to
ever
do
that
and
the
other
consideration
is
the
amount
of
code
that
we
do.
That
we
will
generate
like
size
is
a
concern
for
some
folks.
Do
you
want
so,
if
we're
generating
all
the
serializer
features
in
code,
which
will
never
be
all
of
them?
C
O
O
J
J
If
you're
using
the
metadata
approach,
you
still
get
a
bunch
of
benefits
right
like
we,
don't
have
to
use
refmed
anymore
right.
That's
that's
super
valuable
for
a
lot
of
things.
It's
trim
compatible
right
that
that's
that's
valuable.
In
some
cases
too,
the
startup
yeah
there's
still
value,
even
you
know,
but
the
metadata
fallback
allows
you
to
do
everything
that
the
that
the
serializer
can
do.
C
Yeah,
don't
don't
get
my
feedback
as
like
you
know,
I
absolutely
want
to
kill
metadata
right.
I
just
try
to
understand
where
that,
where
that
dividing
line
is
right,
and
because
I
mean
to
me,
it
still
resonates
with
what
jan
said.
It's
like
you
know,
because
I
mean
every
time
we
see
this
vcl
apis.
If
we
try
to
you
know
land
in
the
happy
middle
ground,
we
very
often
end
up
in
this
valley
of
no
customers
right.
It's
like
it's.
C
It's
not
quite
efficient
enough
for
people
that
actually
care
about
the
efficiency,
but
also
not
quite
usable
enough,
so
that
people
still
use
the
reflection
based
approach
and
that's
kind
of
the.
I
don't
have
a
good
handle
on
that.
It's
just
that!
That's
why
I'm
trying
to
ask
these
maybe
very
pointed
and
proven
questions,
but
I
kind
of
try
to
understand
like
if
we
cut
this
entirely
like
what
would
actually
fall
over
like
what.
What
what
features
can
I
use
right.
M
I
I
mean,
I
think
this
scenarios
are,
if
you
know,
you're
going
to
change
the
options
at
runtime,
then
you
either
have
to
do
metadata
and
serialization
or
metadata.
If
you
know
you're
never
going
to
change
the
the
options
then
use
a
serialization
flag
and
you'll
just
get
an
error.
If
you
do
change
them,
you'll
get
an
exception,
and
then
you
don't
also
have
extra
code
bloat
for
metadata.
L
M
Yeah,
that
would
be
an
option
to
the
the
serialization
flag
that
leone
added
there,
it
would
say
just
generate
the
serialization
logic
and
the
quote-unquote
metadata
is
baked
into
that
code
and
there's
no
fallback.
There's
no
dynamic
capabilities
and
and
no
support
for
features
like
reference
handling
and
async,
and
that
sort
of
thing
right.
L
Yeah,
I'm
saying
that
there's
there's
there's
multiple
fallbacks
that
we're
talking
about
here.
I
was
just
trying
to
clarify
that
because,
based
on
what
steve
said,
there
was
like
this
assumption
that
you
you'd
set
the
fast
path
and
then,
if,
if
you
choose
a
different
option,
it
runs.
If
you
needed
different
options
at
run
time,
then
you'd
see
an
exception
it
it.
L
It
depends
is
like
because
there's
three
layers
that
we're
talking
or
three
different
levels
that
we're
talking
about
here,
there's
fast
path,
there's
sterilization
with
metadata
and
then
there's
dynamic,
which
is
you
know,
no
source
generated
influence.
So
that's
always
trying
to
clarify.
C
Right
so
yeah,
I
guess
my
question
is
like:
if
you
care
about
trim
ability
right
like
why,
couldn't
we
say
you
have
to
make
civilization
work,
you
can't
rely
on
that
data
and
civilization
like,
but
do
you
know
what
I
mean
like
it's
basically,
this
like?
Why
do
we
need
this
middle
ground
or
why
can't
we
just
say
if
you
don't
care,
you
just
use
reflection
based.
L
Yeah
right,
then,
tough
luck,
I'd
say
remember
that
there
are
many
users
of
this
feature
and
not
everyone
is
considered
what
concerned
with
linkability.
So
there's
a
subset
of
users
who
like,
for
instance,
consider
people
like
like
bing,
where
you
know
they
or
or
even
cosmos
or
others
who
who
may
want.
You
know
the
full
of
the
larger
set
of
features
provided
by.
L
The
metadata
approach,
but
but
they
they
they
won't
know
that
up
front.
There's,
there's
the
benefit
of
not
requiring
writable
pages
that
we
get
with
metadata
compared
to
yeah.
I
guess
it's
back
to
steve's
now
that
sorry
for
walking
myself
through
it,
it's
back
to
steve,
like
the
metadata,
helps
you
deal
with
multiple
options.
I
think
that's
the
biggest
benefit
of
it
if
you,
because
if
you
know
that,
if
you
can
commit
to
a
single
set
of
options,
then
you
wouldn't
need
the
metadata
approach.
C
J
C
M
J
J
M
Yeah,
so
I
think
maybe
that
goes
back
to
eric
comment
too.
Is
that
the
the
and
and
the
other
thing
about
the
benefits
you
get
there?
There
are
benefits
with
using
metadata
versus
io
emit.
Today
I
mean
you
get
a
lot
of
the
startup
benefits,
not
everything
you
you,
you
might
get
some
throughput
because
we're
avoiding
some
dictionary
lookups
and
you
use
less
private
bytes.
So
there
are,
you
know,
benefits
to
using
the
metadata
other
than
the
you
know.
Performance
benefits
and
trimming
benefits
as
well.
C
O
In
some
cases
we
might
have
to
write
a
little
bit
of
quality
to
the
generator
to
actually
parse
that
metadata
from
like
attributes
and
stuff,
but
it's
really
minimal
compared
to
to
modifying
serialization
generation
logic,
so
both
of
them
require
us
to
add
more
code,
but
the
metadata
approach
allows
us
to
write
way
less
code.
That's
right.
C
So,
okay,
so
if,
if
we
live
in
a
world
where
we
need
these
modes,
I
think
the
proposal
here
with
the
enum
makes
sense.
I
mean
I
don't
know
what
else
you
would
do.
It's
a
bit
unfortunate
that
that's
a
decision
the
user
has
to
make,
but
I
I
mean
I
think
the
proposal
here
also
to
do
both
is
probably
fine
as
the
default,
because
it
gives
people
the
most
features.
C
J
M
J
Right,
like
so
just
think,
brand
new
brand
new
user.
I
I'm.
I
want
a
serialized
person.
I
have
my
adjacent
context.
I
say
I
want
a
serialized
person
and
I
say:
okay
serialize,
I
don't
pass
any
options
in.
I
don't
do
anything
all
I
say
is
I
want
to
serialize
it.
What
we're
saying
is
you're
not
going
to
get
the
fast
path.
In
that
scenario,.
K
J
So
sorry,
by
default,
if
nobody,
if
nobody
specified
the
generation
mode,
I'm
saying
by
default,
we
should
generate
both
metadata
and
the
fast
path
and
the
fast
path
uses
the
default
options,
because
you
didn't
tell
me
which
options
to
use
and
then
at
runtime,
if
you're,
using
the
default
options
which
you
get
by
default,
then
we'll
use
that
fast
path.
Code.
O
O
O
J
Well,
no,
no,
that's
not
the
default
behavior.
What
I
understood,
laomi
to
say,
was
the
default.
Behavior
is,
if
you
just
say
I
wanted,
I
want
to
opt
into
json
serialization
and
I
didn't
provide
adjacent
serialization
options
at
the
attribute.
Then
I'm
only
generating
metadata
is
that
true,
naomi,
that.
O
Is
true,
that
is
what
that.
O
C
C
L
C
C
C
Yeah,
I
mean
that's
a
fair
point,
but
then
also,
I
think
they
I
mean.
You
could
argue
that
if
you
do
source
chain,
you
should
specify
options.
I
mean
we
could
also
say
we
just
failed
and
say
you
know
you
you,
you
always
have
to
specify
an
options.
Instance,
you,
don't
you
always
have
to
specify
what
options
you
want.
You
don't
get
to
rely
on
ambient
defaults
that
you
may
not
be
aware
of
what
they
are
unless.
C
C
M
M
O
C
All
right,
because
I
mean
like
the
number
one
use
case
for
just
stabilization-
is
effectively
calling
a
web
server
right,
and
so
you
want
stuff
to
actually
bind
right
yeah.
So
if
they,
if
they
give
you
back
camel
case
coding-
and
you
can't
use
the
fastpass
utilization
code
then
well,
that's
not
super
useful.
J
O
C
C
J
C
C
In
terms
of
next
actions,
I
think,
like
you
know,
we
gave
a
lot
of
high
level
feedback
and
very
little
super
specific
feedback.
I
probably
will
push
it
back
to
needs
work,
but
I
think,
like
the,
let
me
just
paste
in
the
notes
that
I
had
and
you
can
tell
whether
I
missed
something.
C
Like
I
haven't
really
changed
the
api
ship,
I
just
copy
paste
it
in
for
completeness,
so
we
know
what
we
actually
looked
at
today.
Didn't
actually
scroll
up.
You
can
see
the
notes,
so
I
think
the
big
one
is,
you
know,
that's
probably
the
major
design
change
on
your
side.
It's
like
this.
You
know
thinking
of
multiple
different
json
contexts,
kind
of
thing
that
would
probably
imply
that
the
json
suggestable
attribute
would
only
be
applicable
to
classes,
because
I
don't
think
we
want
to
support
structs
for
json
contexts
or
interfaces.
C
That
seems
odd,
and
then
we
also
would
probably
remove
the
assembly
level
attribution
as
well
right.
Everything
else
seems
kind
of
still
applicable
by
the
policy,
the
generation
mode
and
then
for
the
jason
still
has
options.
He
kind
of
said,
like
yeah.
The
naming
is
not
necessarily
awesome
because
it
implies
this
relationship
with
the
existing
options
which
we
may
not
want,
and
then
there
was
this
whole
namespace
discussion
of
like.
O
C
C
C
O
And
then
okay,
no,
it's
fine,
but
the
other
thing
is
so
if
we
mark,
as
needs
work
now
like,
is
it
okay
to
still
check
something
in
the
aligns
with
the
feedback
that
we.
C
C
O
Then,
but
I
just
want
to
mention,
I
got
some
feedback
around
like
other
patterns,
if
we
scroll
like
somewhere
down
in
the
issue,
just
to
mention
that
some
considerations
for
future,
though
sorry
I'm
scrolled,
let's
go
further
down
the
patterns
around
generate.
Like
partial
statistic,.
O
Sorry
so
here's
an
idea
from
jan
here
and
like
just
scrolling
that
up
a
little
bit.
Oh
this
one.
C
O
Yeah,
that's
my
thought
as
well
for
it
so
just
like
mentioning
here,
and
I
just
documented
that,
like
alternatives
considered
and
things
like
that,.
C
Yeah
I
mean
I
I
do
like
this.
Also
I,
like
the
name
quite
frankly
like
I
think
I
when
I
talked
with
eric
offline
at
some
point,
I
had
a
similar
proposal,
but
it
was
time
level
based
because
I
like
the
name
generated
somewhere,
because
it
makes
it
clear
that
you
know
something's
happening
here
right.
M
M
You
know,
if
you're
desert
licensed
in
villa
jason,
for
example,
and
you'd
get
a
normal
reader
exception.
Do
we
care
about
that
raw
exception
propagating
today?
We,
you
know
catch
it
and
throw
a
json
exception,
which
has
additional
information
like
the
property
path
and-
and
things
like
that,
so
there's
kind
of
a
question
that
I
have
about
kind
of
like
quality
of
service
on
some
of
these
low-level
apis,
because
it's
not
the
serializer.
But
do
we
try
to
emulate
some
of
the
functionality
that
has?
I.
C
Mean
I
think
you
get
to
decide
largely.
I
think
you
could
I
mean
the
way
I
mean
this
is
the
other
thing
I
want
to
avoid
like
a
gazillion,
different
things
we
need
to
generate.
So
that's
the
other
reason
why
I
like
types
because
you
get
to
decide
you
know
on
this
json
serializer,
so
this
json
context
type.
C
You
could
generate
nested
types
that
are
derived
from
something
that
already
have
a
you
know:
a
serialized
method
on
them
of
t,
basically,
where
they
take
a
writer
and
then
that's
the
one
you
emit,
but
they
also
have
other
overloads
that
just
take
streams
and
stuff
so
that
you
can
handle
in
the
base
type.
And
then
you
could
imagine
a
world
where
the
lowest
level,
one
that
just
takes
to
read
a
writer,
doesn't
do
any
sort
of
exception
propagation.
Just
literally,
let's
fly
off
and
then
the
higher
level
wants
to
take
streams.
C
Maybe
they
do
the
wrapping
and
then
throw
a
json
exception
or
something
right,
and
then
you
can
layer
it
a
little
bit
more
pay
for
play
friendly
without
having
to
generate
a
gazillion
different
combinations
of
you
know,
input
and
output
types
right.
I
think
they
that's
the
other
reason
why
I
don't
like
these
method
level
attribution,
because
then
it's
very
hard
for
us
to
extend
right
versus
if
you,
if
you
emit
a
type
that
derives
from
some
base
type,
it's
much
easier
for
us
right.
C
F
O
C
C
J
O
Connection
yeah,
the
serializer
will
call
that
early
on
if
it
can,
and
then
users
can
also
call
that
themselves.
It's
very
similar
to
the
the
pattern
is
very
similar
to
the
the
one
we
just
saw
downstairs.
I
mean
right.
J
C
Right
so
like
I,
I
guess
the
other
thing
is
like
it
would
be
nice
if
the
if
the
generated
json
context
or
whatever
would
just,
I
guess,
not
exposed
to
metadata
itself,
it
would
just
expose
the
serializers
whether
it's
implementation
detail,
but
to
me
there's
like
two
reasons
for
them.
One
of
them
is
like
you
know.
We
already
have
too
much
reflection
based
types
in
the
framework
and
the
other
one
is
like.
Are
we
really
confident?
C
We
never
want
to
change
them,
because
if
we
can
hide
them
entirely
and
can
just
say
the
only
thing
people
pass
around
are
these?
You
know
things
that
deal
with
that.
Then
it's
maybe
easier,
but
I
understand
that
yeah
you
have
to
split
between
the
you
know
the
low
level
serializer
and
the
type
info
that
does
the
that
does
more
work
at
one
time
right.
M
But
yeah
there's
also
flow
of
control
issues,
you're
right
once
you
hand
over
control
to
a
serialized
method
like
this,
it
becomes
very
hard
to
generate
code
that
can
handle
any
kind
of
fallback
cases
like.
If
you
run
out
of
data.
You
know
in
a
stream,
you
have
to
go
back
to
the
reader,
perhaps
go
back.
M
E
C
Are
generally
happy,
or
did
I
make
somebody
fundamentally
unhappy
with
my
comments.
C
All
right
so
then,
let's
call
it
a
day,
and
then
I
guess
next
tuesday
we
should
then
tackle
the
other.
Two
issues
is.
That
is
that
only
enough
for
you,
leone.
C
C
All
right,
then,
unless
there's
more,
I
would
call
it
there
and
wish
everybody
a
great
weekend.