►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
A
B
Good
morning,
everyone
or
afternoon
and
evening,
depending
on
where
it
is,
you
are
today
on
this
episode
of
api
review,
we'll
we're
looking
at
the
api
involved
in
doing
source
generation
for
system
text
json,
so
naomi,
that's.
C
A
A
So
we
expand
this
into
these
goals,
which
are
to
reduce
startup
time
for
apps
that
use
system
textures,
and
we
use
private
bytes
usage
for
apps
that
uses
some
textures
and
improve
serialization
throughput
enough
that
your
system
takes
jason,
reduces
the
size
of
the
apps
and
gets
rid
of
all
the
linker
warnings
caused
by
apps
using
system
textures.
A
Couple
design
constraints
we
want
to
avoid
like
magic
that
involves
any
sort
of
auto
registration,
integration
of
generated
source
code,
for
example,
with
reflection,
some
serializers
like
xml,
do
such
things
to
integrate
the
generated
source
code
into
the
application
and,
as
a
result
of
the
roslin
feature
for
c-sharp
search
generation,
we
can
only
generate
into
users
smd.
So
any
ideas
around
site,
car
assemblies
or
a
shared
smd
for
multiple
assemblies
to
consume
is
not
in
scope
for
this,
and
also
across
different
assemblies.
A
At
the
same
time
can
have
different
like
metadata
composition,
for
example,
like
private
internal
members
in
one
assembly
will
not
be
visible
from
another,
so
it
gets
confusing
when
you
try
to
share
much
of
the
time
that
way.
So,
there's
an
overview
of
the
approach
for
source
generation.
A
Database,
where
we
basically
move
the
reflection
methods
are
gathering
about
a
type
from
runtime
to
compile
time
and
that's
how
we're
able
to
achieve
most
of
these
goals.
So
that
way,
we're
not
doing
runtime
reflection
to
understand
the
type
and
know
how
to
access
members
or
needs
like
constructors
properties,
fields,
etcetera.
We
do
that
during
compile
time.
We
passed
the
message
directly
as
an
argument
as
a
method.
A
This
way
there's
no
magic
and
we
send
explicit
like
integration
into
the
source
code,
and
this
also
helps
with
link
our
goals,
because
if
we
base
it
on
the
options,
then
these
serializer
doesn't
understand
the
type
yet
and
needs
to
do
reflection
and
by
passing
it
directly
to
the
serializer,
we're
able
to
trim
out
code.
That
is
not
going
to
be
used
and
we
also
provide.
A
This
proposal
includes
a
fast
path,
serialization
logic
approach
for
simple
focus,
simple
focus
here,
meaning
that
the
only
contained
members
that
can
be
handled
directly
by
the
lower
level,
hfa
json
writer,
so
in
state
times,
goods,
etc
and
simple
distance.
There's
options.
You
said
yes,
so
I'll
go
into
that
a
little
bit
more.
So
at
this
point
I
will
share
like
a
small
demo
to
go
over
like
what
the
change
looks
like.
A
But
before
we
see
like
the
before
code,
you
basically
pass
an
object
to
the
serializer,
get
the
battery
is
done
and
then
you
can
visualize
it
as
well.
A
So
visual
studio
is
fighting
a
little
bit
today,
but
this
code
compiles
there's,
there's
no
issue
with
it,
so
any
squeaky
lines
are
things
that
are
auto
generated.
A
So,
given
a
class
that
you
know,
you
have
an
inter
property
collection
of
strings
straightforward,
you
specify
to
the
generator
that
you
want
to
generate
source
code
for
the
type
I
have
another
type
here
as
well,
and
the
generator
proceeds
to
generate
information
relevant
about
type,
and
this
is
the
generated
method
editor
for
the
type
specifically
I'll
go
into
what
it
looks
like.
So
you,
instead
of
passing
options
or
passing
nothing
at
all,
you
pass
the
generated
metadata
and
similarly.
A
You
pass
the
metadata
for
the
type
as
well,
so
the
return
type
of
this
is
something
called
json
type
info
of
t
where
the
t
might
matches
with
the
t
of
the
digitalized
method.
So
here
you
see
that
you
don't
need
to
specify
like
a
generic
type
argument,
then
you
perform.
A
In
essentially
the
same
way,
I
also
show
an
example
of
the
path
fast
path
usage.
So
you
see
it's
similar
to
my
class,
so
this
is
a
generator
for
the
point
class
I
show
here.
Then
we
generate
a
a
method
on
that
metadata
class
which
accepts
a
writer
except
an
object
and
accepts
serializer
options,
and
we
can
write
directly
to
the
writer
so
and
this
same
method
that
we
generate
can
be
consumed
within
the
serializer
itself
as
a
fastpass.
A
So
it's
a
composible
with
the
rest
of
this
design,
but
you
can
optionally,
or
the
proposal
here
is
to
expose
this
directly
to
users
to
so
to
provide
that
logic
to
provide
that
logic.
So
what
is
the
generated
code?
We
have
this
top
level
json
context
class,
which
contains
metadata
about
the
entire,
like
assembly,
assembly
level,
attributes
so
every
metadata
class
that
you
every
type
that
you
specify
will
be
represented
here.
A
So
this
is
900,
I'm
just
cleaning
this
up,
so
we
have
a
default
property
and
what
this
does
is
to
create
an
instance
of
this
using
default
serializer
options.
A
Today
the
default
is
internal,
so
we
just
click
on
that
default
and
the
reason
it
is
cloned
is
to
maintain
a
one-to-one
pairing
between
the
context,
class
and
digitalizer
options
instance,
because
we
don't
want
a
situation
where
one
options
instance
options.
Instances
today
contain
like
metadata
for
a
type.
So
if
you
provide
multiple
context
classes,
then
that's
not
a
good
model.
A
For
instance,
if
you
wanted
to
see
options
that
get
converted,
you
would
only
want
the
option
to
get
the
converter
from
one
metadata
class,
so
we
cloned
the
options
and
not
keep
track
and
not
hold
on
to
the
default
one
so
that
we
can
so
that
we
can
force
a
one-to-one
pairing.
Basically,
so
we
use
this
constructor
to
to
do
the
cloning
internally
from
the
json
serializer
context
class,
which
is
the
base
abstract
class,
then
also
we
provide
this.
A
We
generate
this
from
method
where
you
can
specify
your
own
custom
options
and
we
will
cut
another
attachment
time.
We
also
clone
your
the
options,
instance,
and
that
is
cheap
because
at
this
point,
we're
not
doing
any
like
sort
of
metadata
generation.
So
your
options
instance
in
this
case
it's
just
a
simple
procode
that
has
like
a
bunch
of
booleans,
and
you
know
specifying
you
know
what
you
want
to
do
so
so
that's
how
you
create,
like
json
context,
instances
to
use
within
your
application.
We,
this
is
a
one-time
generation.
E
A
It
it
also
does
the
same
clone
I
described
for
the
default
case,
so
the
intention
is
just
to
be
able
to
get
your
own
custom
options,
those
be
cloned
and
then
we'll
maintain
the
clone
instance,
as
well
as
the
options
instance
that
we
keep
track
of
internally
and
from
the
other
thing
to
mention.
Is
that
from
this
point,
where
you
basically
instantiate
an
instance
of
this,
the
options
are
like
locked,
because
it
makes
it
easier
for
the
underlying
implementation
to
reason
about
what
metadata
is
needed
and
not
expected
users
to
change
it.
A
F
Just
take
the
values
like
the
normal
study,
you
know
default
studies,
that
sort
of
thing
and
just
copying
the
mulberry's
properties
right.
That's
all
we're
not
copying
any
caches
or
underlying
dictionaries
that
we
that
we
normally
would
have
on
the
option.
Yeah.
A
It's
very
it's
similar
to
the
copy
constructor
that
we
exposed
in
fiverr,
so
we
also
generate
this
method
to
get
the
runtime
provided
custom
converter
because
we
have
to
own
it.
So
we
look
through
and
optimize
the
implementation
based
on
like
the
number
of
converters,
but
for
most
cases
you
only
have
like
a
couple
like
three
or
four
something
like
that.
So
this
is
logic
that
would
generate
once
to
to
fetch
the
converter.
A
I
appear
to
okay
I'll
circle
back
to
this
one
here,
so
we
also
generate
this
type
info
class,
which
provides,
and
so
this
is
at
the
level.
So
when
one
of
these
is
passed
to
the
serializer,
you
pass
it
along
with
the
type
and
then
the
serializer-
and
this
is
in
cases
where
you
don't
know
the
type
up
front,
so
the
serializer
will
call
get
type
info
and
pass
the
type
and
the
context
will
return
the
metadata
for
the
type.
A
I
okay
now
this
is
my
class,
the
same
class
that
we
specified
here.
This
is
what
generally
json
objects
look
like
the
metadata
for
those.
So
first
we,
this
is
the
my
class
that
is
referenced.
So
if
you
do
jsoncontext.default.myclass,
we
fetch
it
here.
First
do
not
check
and
then
create
it.
If
it's
not
known,
then
the
first
thing
we
do
is
we
check
if
it
has
a
custom
converter?
A
If
it
does,
then
we
we
basically
use
the
metadata
representation
for
a
simple
like
for
a
type
that
has
a
simple,
primitive
converter,
because
that's
the
only
like
converter
module
that
we
exposed
today
so
but
that
model
is
generally
geared
for
things
like
simple
primitives
like
inside
strings,
but
anything
that
has
a
custom
converter
is
treated
in
this
simple
way
where
you
have
like
just
a
custom
converter.
A
So
if
it
has
a
custom
converter,
then
we
centimeter
data
accordingly
and
then,
if
it
doesn't,
then
we
have
a
different
representation
where
we
first
knew
up
a
a
my
an
object,
a
representation
for
like
the
poco
and
initialize
it
with
relevant
information.
So
one
of
the
things
here
is
a
creation
object.
Func
to
say
hey:
this
is
how
to
knit
up
this
object.
A
A
series
object,
func,
which
I
pointed
out
earlier,
to
provide
a
fast
path,
is
null
in
this
case,
because
this
spoke
doesn't
fit
our
requirements
of
what
a
simple
poco
is.
In
this
case,
you
see
the
array,
it's
a
different
question
of
whether
I
should
but
the
gas
proposed
it
does
not,
and
we
pass
a
function
that
initializes
type
metadata
for
the
for
the
properties
of
that
purple.
A
So,
and
this
way
this
year
the
serializer
can
easily
initialize
the
metadata
for
poco
in
the
case
that
either
no
serious
one
object
funk
is
provided.
Then
we
need
this.
We
do.
We
need
this
up
easily
or
a
funk
is
generated,
but
the
options
that
are
used
is
not
compatible
so
meaning
that
a
more
complex
like
option
like
reference
handling
is
is
used.
Then
we
will
easily
need
to
sub
so
just
pass
this
func,
and
this
is
supposed
to
represent
the
number
hunting
for
the
type.
H
If
you
go
back,
I
have
a
bit
of
a
high
level
question
if
you
go
back
to
the
program.cs,
so
in
the
case
of
the
fastpath
approach
that
you're
talking
about
it,
looks
like
you're
requiring
the
customer
to
write
new
code,
was
there
never
a
goal
of
having
the
existing
code
base,
leverage
source
generators
and
just
become
faster?
A
So
I
think
the
primary
reason
why
we
can't
have
users
code
unchanged
is
because
that
is
not
compatible
with
linker
trimming.
We
need
to
have
a
way
to
specify
what
is
needed
in
an
eco-friendly
way.
So,
and
it
goes
back
to
I'm.
I
A
Quite
sure,
like
other
approaches
to
have
users
not
change
their
code,
that
doesn't
involve
some
sort
of
magic.
Like
reflection,
which,
at
the
beginning
of
this
presentation,
I
started
to
be
like
a
non
like
constraint
that
we
don't
want
to
magically.
Do
anything
want
things
to
be
explicit
and
clear
like
why
we
generated
code,
so
we
specify
an
attribute
for
you
to
say
this
is
the
type
that
you
want
and
we
just
want
to
avoid
the
world
where
we're
doing
like
magical
magical
things.
A
D
A
Serialization
is
a
thing
where,
like
code
is
generated
to
different
assembly
and
it's
magically
added
to
the
application.
H
A
That's
just
yeah,
that's
just
one
of
half
of
my
question.
The
first
thing
I
said
was
for
linker
friendliness.
That's
the
the
primary
thing.
G
But
if,
if
someone
doesn't
care
about
linker
friendliness,
they
just
want
improved
startup
time
for
their
server
app
or
whatever,
there's
no
way
that
just
turning
on
the
source
generator
with
their
existing
code
would
allow
them
to
just
get
improved
startup
time
they
have
to
change
their
code.
Even
for
that.
A
With
the
model
and
the
set
of
goals
like
overall
as
we
have
them
today,
how
to
have
them
stated
and
with
the
user
scenarios
that
we
established
for
six
work,
that
where
you
don't
change
your
code
and
things
get
faster,
it
doesn't
doesn't
align
clearly
with
those
with
those
set
of
codes.
A
So
I
acknowledge
there's
a
scenario
for
it,
but
that's
not
quite
the
one
where
we
design
for
the
idea
of
users,
not
changing
their
code
at
all,
was
talked
about
as
a
very
like
lofty
and
ideal
ideal
mode
which
we
did
not
pursue
due
to
the
overall
set
of
goals
that
we
were
designing
for,
but
in
the
future,
like
we,
I
mean
the
question
of
code.
You
know
if
we
we
assert
that
that
is
a
goal
that
we
should
commit
to.
A
Then
you
can
think
about
like
what
does
forward
compatibility
for
that
sort
of
mode.
But
but
the
overall
answer
to
the
question
is:
that's
know
what
that
is
now
what
we're
designing
for
here.
F
So,
just
to
add
on
to
that,
and
maybe
a
little
background
today,
the
serializer
you
pass
in
a
type
either
serialization
or
deserialization,
and
from
that
type
we
look
up
the
you
know
the
quote:
unquote
metadata
for
that:
the
list
of
properties
et
cetera
and
that
uses
reflection.
It
does
ilmid
and
that
sort
of
thing
and
it
does
it
on
a
per
type
basis.
F
We
don't
know
what
types
you
want
until
you
call
a
serialized
method,
so
it
just
does
it
kind
of
you
know
as
you
need
it,
and
with
this
model
we
do
know
the
type
and
we
don't
want
to
use
reflection.
F
So
that
means,
if
you
call
an
existing
serialized
method
without
changing
your
code,
but
you
have
the
code
generated
mechanism,
then
what
would
have
to
happen
is
we
would
say,
hey,
there's
a
context
class
that
has
an
option.
Are
the
options?
Class
has
a
context
class,
and
now
we
have
to
find
the
type
the
metadata
for
that
type
and
that
would
probably
involve
you
know,
populating
the
dictionary
and
then
getting
off
once
and
then
reading
from
that
dictionary
to
get
the
metadata.
F
So
it's
possible
to
do
that
and
you
probably
get
some
benefit,
but
you
still
do
have
the
dictionary
hit,
plus
you
probably
populate
the
entire
dictionary
ahead
of
time,
unlike
what
we
have
today,
where
we
can
do
it
as
needed.
So
if
you
have
a
hundred
pokes
generated,
you
know
we
would
have
to
probably
create
a
dictionary
of
100
items.
The
first
time,
which
kind
of
goes
against
some
of
the
startup
goals.
E
E
If
so
map
that,
to
this
type
and
then
say
clearly,
this
assembly
opted
into
source
generation
that
you
serialize
for
and
now
you
just
get
this
json
context
from
there
like
that.
There's
a
there's,
a
one-time
hit
that
you
pay
for
that.
If
somebody
doesn't
pass
in
a
context
option
but
like
you
still
get
99
of
the
benefit
of
the
of
the
json
context,
without
forcing
people
to
pass
it
all
over
the
place.
A
Yeah,
the
I
guess
the
direction
went
was
that
one
time
that
one
time
hit
was
something
was
part
of
what
we're
trying
to
avoid.
Perhaps
it's
not
as
large
compared
to
the
rest
of
the
reflection,
but.
E
Well,
I
guess
what
I'm
saying
is
like:
if
that
hit
is
too
hard?
I
think
it's
okay
to
say
you
know
if
you
don't
want
to
pay
for
that,
hit
pass
in
json
contacts
not
default
to
the
to
the
serialize
as
an
argument,
but
if,
if
you
just
basically
opt
into
existing
code
to
turn
on
the
the
the
generation,
it
would
be
nice
if
you
get
like
most
of
the
benefits
of
the
source
generation
right
without
having
to
change
all
the
code
that
invokes
the
serializer.
E
E
D
E
D
D
F
F
There
is
a
middle
ground
here
I
mean
if
you,
if
you
know,
if
you're
aware
of
the
context
and
you
wear
the
new
programming
model,
you
could
create
an
options
that
has
a
context
but
still
pass
in
the
options
still
use
all
your
other
code
just
add
one
line
of
code.
Basically,
and
then
you
hit
the
mode
like
I
mentioned
earlier,
where,
where
we
would
have
to
call
into
the
method
that
naomi
showed
that
we
we
know
about
all
of
the
types
and
we
would
have
to
add
them
to
a
dictionary,
etc.
F
After
that
one
time
hit,
the
performance
would
would
be.
You
know,
on
par
with
some
serializer
and
the
benefit
you
would
get
is
you
would
be
avoiding
reflection
and
reflection
emit
I
mean
we
and
that
would
be
very
trivial,
to
implement
it's
if
it's
not
already
implemented
in
the
prototype.
H
So
from
the
api
design
perspective
to
bolster
some
of
emo's
point,
I
think
it
makes
sense.
I'm
looking
at
the
goals
that
you
have
shared,
that
you
want
to
minimize
reflection
usage,
because
you
want
to
improve
startup
time
improve
throughput.
But
does
that
mean
that
we
need
to
have
zero
reflection
calls?
And
so
why
do
we
want
to
have
zero
differential
calls,
meaning
in
the
case
of
like
email
mention?
A
The
the
the
approach
we
take
here
so
that
can
be
considered
for
sure.
A
If
there's
enough,
like
agreement,
that
you
know,
we
want
to
to
provide
that
sort
of
virtual
registration,
but
the
proposal
as
it
is,
is
optimized
for
the
most
iot
friendly
thing,
where
we
don't,
where
any
reflection
that
happens
isn't
as
a
result
of
using
system
taxation,
and
that
seems
to
be
like
the
direction
that
I
want
to
go
for
the
framework
as
a
whole,
and
I
think
the
user
experience
is
not
that
much
that
we've
considered,
I
mean
the
change
like
adding
an
additional
parameter
to
you
know
wherever
you
use
this
realizer
we've
considered
like
an
analyzer.
A
H
This
reminds
me
a
little
bit
of
the
saying
that
make
simple
things,
easy
and
difficult
things
possible
to
me.
Allowing
aot
reflection-free
scenario
is
possible
already.
I
think
the
feedback
is
making
you
make
the
simple
things
simple.
The
other
thing
I
want
to
mention
is
that
the
regular
users
fast
path
usage.
Can
we
make
that
decision
opaque
to
the
customer
so
that
we
just
decide
what
the
fast
path
is?
What's
the
regular
usage
is,
rather
than
forcing
the
customer
to
change
their
code
based
depending.
A
Yeah,
we
do
in
a
sense
like
to
get
the
first
pass.
It's
not
as
fast.
You
just
pass
it
to
the
series
serializer
directly,
so
just
like
this
and
the
series.
That
knows
that
you
can
call
this
method.
This
is
just
in
the
case
where,
and
this
is
optional
in
my
view,
I
mean
it
provides
the
very
best
performance
right
because
you
don't
have
a
little
overhead,
that's
associated
with
going
through
the
serializer
but
yeah
this
realizer.
A
This
is
composible
where
the
serializer
knows
that
if
you
pass
just
this,
this
realization
knows
it
can
call
this
method.
So
this
option
now
just
to
because
this
realizer
right
now
uses
a
pulled
by
terry
buffer,
which
has
like
some
overhead
on
first
use
as
versus
like
memory
stream.
So
in
this
way
you
know
specifically
you
want
to
do
I
mean
that
various
things
you
can
do
about
that
like
say,
you
provide
a
method
to
not
use
a
food
buffer
and
things
like
that.
But
ultimately,
this
is
just
here
as
a
convenience.
A
A
Yeah
for
on
startup
there's
no
difference,
there's
effectively
no
difference,
but
with
throughput
there
it
starts
to
be
a
difference.
I'll
show
those
numbers
later,
yeah.
G
I
have
another
semi-related
question:
we
have
an
issue
where,
if
you
don't
pass
in
an
options
bag,
it
ends
up
creating
a
new
one
for
you
and
then
today
it
ends
up
doing
redoing
all
of
the
reflection
and
stuff
right.
So
if
you,
if
you
throw
away
the
options,
every
time
performance
is
really
bad.
Is
that
true,
steve.
F
G
G
G
G
F
G
D
B
B
G
G
Or
multi-tenant
like
host
with
many
plug-ins,
you
know
system
to
text.
Json
is
going
to
be
used
everywhere.
So
when
you
start
saying
you
know,
these
components
which
are
doing
isolated
source
generation
contribute
their
their
results
to
some
static,
shared
state
for
the
entire
app
domain.
That
can
get
a
little.
You
know
a.
G
What,
if
one
guy
decided,
I
I'm
not
sure
how
how
how
much
you
know
applied
a
applied
converter
for
a
type
that
he
had
that
was
shared
by
another
person
who
didn't
want
that
converter?
I'm
not
sure
how
our
system
would
play
well
with
that,
but
it's
possible
there's
even
collisions
right.
A
Yeah
well
in
in
many
cases
like
users
have
custom
options,
and
it's
it's
not
clear
what
the
solution
will
do
to
accommodate
like
crashing
the
meta
data
for
for
those
like
almost
never
and
nobody
that
uses
the
same.
Taxation
like
at
a
higher
level
at
like
asp.net,
doesn't
customize
the
options.
So
I
think,
unless
you're
doing
like
some
crazy
console,
app
or
micro
service
type
thing
like
that's
the
only
scenario
where
that
will
be
like
useful.
All
right,
well,
not
useful,
but
wait
that
we
can
accommodate.
F
I
mean
nothing
stops
us
from
adding
like
options,
dot
register.
You
know
metadata
or
something
like
that
that
you
can.
You
know,
add
your
own
metadata
ahead
of
time
like
once
when
you're
initializing
the
options
and
then
you
know
just
go
with
that
and
then
pass
in
the
options,
and
we
do
the
dictionary
lookup
like
we
do
today.
F
F
But
you
do
need
to
specify
it
everywhere.
You
want
the
benefits
of
it.
Yes,
and
if
you
look
at
the
programming
model,
though,
like
like
leon
said,
you
typically
are
passing
in
the
options
already
today,
probably
you
know
you
know
75
percent
of
making
up
a
number,
but
some
high
percentage
over
50
probably
are
creating
a
custom
option.
So
this
basically
replaces
the
options
instance
that
you
pass
in
to
serialize
and
deserialize
with
the
particular
metadata
for
class,
and
then
that
has
a
reference
to
the
option.
So
you
basically
substitute
one
parameter
for
another.
E
D
D
E
Well,
no,
that's
not
what
we
were
proposing.
What
we're
proposing
is
saying,
there's
there's
two
overloads
one
that
takes
the
context
and
one
that
doesn't
which
is
the
existing
one
and
the
existing
one
would
just
try
to
find
a
context.
So
if
you
don't
want
this,
you
just
bypass
that
call
you're
just
directly
passing
the
the
context
itself.
A
It's
my:
we
have
a
feature
to
replace
the
default
options
like
a
feature
request.
So
if
we
were
to
go
down
the
that
route,
it's
possible
that
the
user
can
specify
one
default
once
and
then
we
can
maybe
one
time
associate
that
options
instance
with
the
generated
context,
and
maybe
that
will
work
so
you
can
circle
work.
A
D
L
Figure
out,
oh,
but
you
are
setting
a
context,
so
that
means
that
you're
not
going
to
take
the
unsafe
path
there's
no
way.
So
the
only
way
of
getting
a
no
warning
scenario
would
be.
If
you
call
the
overload
that
takes
in
the
context.
G
A
G
So
the
other
thing,
I
guess,
I'm
less
concerned
in
general,
I'm
concerned
in
general
about
the
default
experience
of
someone
just
creates
a
new
app
and
they
copy
and
paste
what
they're.
You
know
the
source
that
people
have
been
using
with
system
text
json
for
several
releases
now
and
all
of
a
sudden
they
get
a
ton
of
warnings.
G
D
D
G
For
regex
you
don't
regex,
you
don't
get
warnings
when
you
use
regex
like
link
the
linker's
not
going
to
give
you
warnings
about
it,
you
can
opt
into
using
the
source
generator.
You
write,
you
know
an
additional
two
or
three
lines
of
code
and
then
you're
using
the
source
generator,
but
you
don't
get.
B
Right
but
I
mean
that's
the
the
problem.
Is
it's
a
reflection
based
thing,
so
all
the
reflection
metadata
needs
to
be
there
so
that
you
get
all
the
hey.
I
needed
reflection,
metadata
warning
like
that's.
We
built
an
api
without
trimming
being
a
feature
that
we
were
designing
for
and
that's
what
we
have
we're
now
fixing
it.
D
The
question
I
was
asking
was
specifically
about
source
generators,
but
in
the
general
sense,
not
just
system
text
json,
but
all
the
source
generators
we're
going
to
build.
Are
we
going
to
say
all
the
apis
that
we're
going
to
want
to
source
gen,
for
you
don't
have
to
change
your
code
in
order
to
opt
into
source
chain.
E
No,
I
think
we
can
decouple
these
two
things.
I
think
it's
okay
to
say
if
you
want
to,
if
you
want
to
get
the
benefits
of
source
generation,
you
may
have
to
do
something
to
your
code.
Well,
the
very
minimum.
For
example,
you
have
to
put
an
attribute
on
something
that
says
you
know
use
the
source
generator
right,
but
I
think
the
question
is
now
like
you
know
if,
if
you're
basically
saying
like
okay,
this
is
not
linker
friendly
right.
E
Are
we
okay
with
saying
we
want
to
push
everybody
to
make
yourself
as
linker
friendly
as
possible
and
that's
going
to
be
noisy
or
we're
saying
moby
just
shipped
defaults
that
may
keep
more
metadata
than
we
want.
So
if
you
want
your
blazer
have
to
be
smaller,
you
have
to
turn
on
some
other
thing.
That
says
you
know,
link
more
aggressively
and
now
you
get
warnings
for
you
know,
please
use
the
linker
friendly
api,
it's
not
the
link,
unfriendly
ones,
and
that
requires
more
code
right.
So
it's
more
about
the
you
know.
E
So
maybe
we
can
table
that,
but
I
feel
like
I
think
stephen
has
a
valid
point
here,
which
is
if,
if
every
single
feature
does
what
we
do
for
system
text.json
like
in
dotnet7.8
at
some
point,
you
know
you
get
a
hundred
warnings
for
default
code,
because
now
everything
wants
you
to
change
everything,
and
then
it
just
becomes
really
hard
to
get
enough
to
work
right.
So
the
so
the
question
is:
can
we
make
this
a
bit
more
dialable
where
you
can
say
yep
my
blazer
app
is
too
big.
E
B
During
the
generation
phase
is
the
are
you
allowed
to
rewrite
existing
code?
No,
no!
Okay!
So
I'm
gonna
say
you
know
the
either
an
analyzer
to
help
with
the
case
or
if
the
generator
phase
could
rewrite
code,
it
would
be.
You
find
a
call
to
jsonserializer.d
serializeoft
with
no
options,
and
the
t
was
something
you
would
put
the
pre-generate
the
class
for
and
then
it
would
just
change
it
to
call
this
code
for
you.
G
E
D
E
And
I
would
have
to
suppress
the
unless
I
want
to
suppress
all
link
up
ones
which
I
could
do
with
a
global
node
one.
I
would
have
to
crack
myself
press
every
call
to
the
system
text
json
apis
that
be
marked
as
linked
unfriendly
right
right,
so
yeah.
That
would
be
the
minimum
amount
of
work
then,
but
it's
still
potentially
a
bit
of
work
depending
on
how.
B
Important,
you
know
we
don't
trim
things
other
than
system
libraries,
because
that
seems
if
we
go
back
to
the
scenario
of
somebody
wrote
a
a
client
library,
for
I
don't
know,
google
photos
api
and
that
now
you've
pulled
that
in
and
it
doesn't
get
trimmed.
I
assume
that's
a
point
in
time
thing,
because
people
wouldn't.
D
D
By
default
by
default,
the
assemblies
that
I
have
there's
a
new
assembly
metadata
attribute
called
is
trimmable
and
any
assembly
that
is
trimmable,
true,
which
we
marked
all
of
them.
In.Net
runtime
is
true.
Any
assembly
marked
with
that
means
I'm
going
to
actually
trim
members
out
of
classes
and
members
out
of
this
assembly.
B
D
E
Yeah,
I
don't
think
we
are
proposing
that
right,
it's
more
about
like
how
do
you
like
how
many
lines
of
code
do.
I
have
to
change
to
opt
into
this
behavior
right,
which
I
think
it's
reasonable,
that
you
say
you
want
to
have
source
generation
somewhere.
You
at
least
have
to
tell
us
what
you
once
was
generated
in
the
first
place
right
so
like
there's
always
going
to
be
some
amount
of
code,
you
have
to
write,
but
I
think
the
question
now
becomes
how
many
other
things
do.
E
I
have
to
change
in
order
to
make
the
overall
system
use
it
right,
and
could
we
make
that
a
bit
smarter?
By
saying
you
know,
we
use
some
amount
of
limited
reflection
to
find
the
thing
we
generated
rather
than
make
you
pass
it
in
all
the
time
and
then
also
give
you
an
option
to
pass
it
in
to
avoid
that
overhead
right.
So
it's
more
about
the!
How
many
steps
kind
of
thing
you
have
to
do
right.
E
D
B
Like
you
could
spit
out
a
module
initializer,
except,
I
think,
you're
only
allowed
to
have
one
that
calls
some
new
json
serializer.register
metadata
thing
to
shove
things
in
a
default
bucket,
but
then
you
can
have
multiple,
then
we'd
have
fair
enough.
Thank
you,
then.
We'd
have
the
an
interesting
security
debate
about
cash
poisoning
and
the
ability
to
overwrite
and
all
sorts
of
fun.
Things
like
that.
A
Yeah
I
mean.
E
The
one
thing
we
said
before,
which
I
think
I
want
to
reiterate
quickly-
is
that
we
said
we
generally
don't
want
to
rely
on
source
generation
for
for
being
able
to
use
a
feature
at
all
right.
We
very
often
said
like
it's
an
optional
thing
you
can
opt
into,
but
we
generally
want
to
make
sure
that
we
build
new
features
that
don't
inherently
require
source
generation
to
work
at
all.
Right,
because
we
know
that
we
can't
support
it
in
all
languages.
E
We
will,
by
default
not
to
still
even
ship
fbb
version
of
those
in
in
most
cases.
So
the
question
becomes,
you
know:
where
do
we
draw
the
line
right?
And
so,
if
we
say
in
order
to
make
civilization
workable
in
the
link
of
wrote
at
all,
you
must
use
trust
innovation.
That
seems
like
maybe
a
bridge
too
far
right,
and
I
think,
especially
when
we
say
most
people
only
ever
civilize
user
types
anyway,
which
we
by
default
don't
trim
either
way.
E
Then
it
seems
like
it's,
maybe
a
bit
over
the
top
to
warn
everybody
and
make
them
rewrite
their
code
right.
So
I
think
it's
more
about
that
kind
of
scenario
right
where
you
just
want
to
build
a
blazer
app.
You
want
to
see
a
light.
Sometimes,
can
I
do
what
I
do
today
or
do
we
make
you
jump
through
more
hoops.
B
Yeah
I
mean,
I
think
there
is
a
very
fair
question
in
here
of
if
you
are,
if
you're
getting
the
serializer
being
called
from
asp.net.
Where
do
you
get
the
benefit
of
this
generation
at
all
and
right
now
it's
it
sort
of
sounds
like
you
can't,
and
so
there's
probably
a
missing
feature
here,
but
we
can
probably
continue
to
talk
about
the
stuff.
That's
already
here
and
see
what
that
may
affect
in
fixing
that
gap.
E
Yeah
so
the
problem
is
you
write
a
method
right
call?
You
know
post
post
user
data
or
sorry
get
user
data
right
and
so
by
convention,
because
it
starts
with
get
they
make
it
a
controller
action.
Your
return
type
is
now
customer
details
or
something,
and
so
because
of
that
convention
they
will
serialize
those
types
transparently
right.
E
J
E
B
A
At
least
that's
what
so.
I
guess
so
it
just
restates
in
case
I
missed
something
else
as
far
as
the
the
mode
for
we,
the
with
the
feature
to
expose
the
default
options
and
change
that.
I
think
that
would
help
with
the
case
of
not
changing
your
code,
but
not
friendly
with
link
in
case.
That's
something
that
we
still
want
to
push
you
just
find
out.
G
Just
a
clarifying
question
on
that,
so
I've
written
my
cool
library
and
my
cool
library
uses
json
serialize
and
json
as
json
serializer,
serialize
and
deserialize
under
the
covers.
My
method
is
generic
and
it
just
calls
serialized
t
and
deserialize
with
t.
How
do
I
change
my
library
code,
you're
saying
I?
I
expose
some
register
method.
That
is
also
that
also
needs
to
be
called,
and
then
I
use
that
to
somehow
populate
a
dictionary
or
something
that
I
pass
to
my
serialize
and
deserialize
methods
or
you.
G
A
L
And
to
answer
your
question
steve,
so
if
you
wanted
to
be
linker
friendly,
if
you
don't
want
to
like
cause
a
bunch
of
warnings
to
happen,
you
could
still
make
your
your
library,
linker
friendly
in
a
sense
that
you
would
just
mark
all
of
the
apis.
That
would
trigger
a
warning
yourself
when
you're
building
that
would
use
this
dc
realized
methods.
You
would
mark
them,
as
requires
on
reference
code
yourself
and
just
put
a
message
in
there
and
say:
hey.
I
don't
know
what
the
type
is.
L
It
cannot
be
statically
analyzed
by
me
because
I'm
a
library
I
don't
know
what
is
the
context
that
you're
going
to
want
to
build.
So
you
just
mark
it
as
requires
on
reference
code,
you
can
still
be
trimmable
friendly
and
then
your
consumers
would
which
would
be
the
end
app.
Then
they
would
have
to
add
the
dynamic
dependency
and
then
suppress
the
message
and
then
everything
would
still
be
linker
friendly.
So
you
could
still
make
your
library
be
linker
friendly,
even
though
you're
calling
the
serialize
without
exposing
adjacent
context.
G
F
F
I
don't
even
know
what
the
numbers
100k
savings
on
system
text
json
assembly,
but
now
we're
generating
code
in
your
user
assembly,
which
adds
space
so
there's
you
know
some
sort
of
threshold
or
break
even
point.
I
don't
know
what
that
is.
Maybe
it's
a
hundred
pokos,
maybe
it's
500
pokos
depends
maybe
on
your
pokemon,
how
many
properties
you
have
and
what
kind
of
code
we
generate
for
the
fast
path.
But
the
decision
to
do
that.
F
D
I
mean
if
you're
going
to
aot
your
code.
It
agreed.
I
100
agree
with
what
you're
saying
like
it's
a
there's
a
trade-off,
but
if
you're
going
to
aot
your
code-
and
so
you
can't
use
reflection,
emit
anymore
in
that
platform,
right
say
like
ios,
where
they
don't,
they
just
don't
allow
to
generate
code
at
runtime,
but
yeah
you're
gonna
be
bigger,
but
you
know
now:
you're
not
gonna
you're,
not
gonna
pay,
the
100x
penalty
or
whatever
it
is.
F
A
good
point
I
mean,
and
that's
something
that
we
didn't
discuss
yet
is
the
fallback,
if
you
don't
have
ref
support
on
your
in
your
platform,
is
to
use
the
super,
slow
reflection,
invoke,
which
maybe
makes
you
two
to
three
times
slower,
something
along
those
lines
and
on
ios
with
this
approach
that
langley
is
going
over.
You
know
you
get
a
2
3x
improvement
today
with
with
this
changes
where
there
is
no
way
to
do
that
without
source
gin.
G
Pretty
good,
I
don't
know
we
have
an
outcome,
but
I
have
a
different
question:
could
clean?
Could
you
go
back
to
my
class.g.c.s
for
a
sec
yeah?
So
you
were
talking
about.
I
guess
I
have
a
question
around
versioning,
so
I
ship
my
assembly
that
contains
this.
What
happens
in
the
future
if
jason's
serializer
adds
another
thing
that
it
would
normally
want
to
store
in
the
json
context?
Obviously
this
doesn't
have
it.
How
does
that
work.
A
So
would
expose
a
new
like
method
that
can
accept
the
the
new
features
and,
depending
on
what
they
are,
if,
if
old,
like
new
code,
if
somebody,
if
we
receive
metadata
that
calls
this
property
like
at
that
point
in
time,
but
the
metadata
is
not
snail.
It's
not
still
because
still
continue
to
support
it.
Otherwise,
like
we
have
the
option
to
do
stuff,
like
an
exception,
saying
not
supported
this
method,
that
has
expired,
but
we
would.
A
The
answer
to
the
question
of
new
features
would
have
a
new
method
that
takes
the
metadata
require
to
to
basically
populate
the
metadata
for
the
new
features.
So
it's
like
these
properties
are
somewhat
conversion
and
then
with
like,
if
you
call
an
old
one,
depending
on
whether
or
not
it's
safe
to
to
to
accept
your
metadata
through,
in
an
exception,
saying
that
you
should
recompile
your
application
or
generate
new
code.
J
A
D
B
D
D
G
D
A
No,
I
was
saying
yeah,
I'm
not
sure
if
there's
an
extreme
case
where
you
would
want
to,
but
generally
stupid,
it's
called
meta
and
then
we
used
metadata.
That
was
provided
at
the
time
that
should
all
still
work,
I'm
just
thinking
in
case
of
say,
breaking
change
or
something
edge
case
like
that
yeah.
E
B
Well,
I
mean
that's
not
really
true
like
if,
if
you're
a
library,
there's
no
reason,
you
can't
use
it
as
an
internal
detail.
What
actually
seems
wrong
about
this,
and
I
hadn't
thought
of
when
talking
with
laomi
previously,
is
to
go
back
to
an
example.
Where
there's
what
did
I
say
before?
Google
photos
a
google
photos,
client
library,
if
you
have
a
normal
application,
so
not
full
aot
and
you've
registered
that
you
want
to
do
source
generated
serialization
of
something
that
involves
one
of
those
types.
B
So
the
fact
that
it's
building
the
entire
type
graph
into
the
final
assembly
means
it's
not
it's
not
resilient
to
library
updates
in
a
positive
sense.
It
would
and
then
it
would
do
weird
things
if
the
things
got
removed,
of
course,
but-
and
that
seems
a
little
weird
though,
without
rewriting
the
entire
universe
to
be
in
terms
of
interfaces
or
calling
patterns,
I
don't
know
what
we
would
do.
F
It
won't
help
you
with
the
raw
serialized
case.
However,.
K
D
The
idea
is
take
take
your
your
photo
case.
If
I
was
referencing
your
your
class
and
I
was
like
all
right-
I'm
going
to
write
to
jason
writer
hand,
code,
jason,
writer
code
right
and
I
know
about
the
10
properties
that
you
have
on
your
photo
class
right
right,
right,
right,
right,
10
times,
publish
ship
right
and
now
you
go
and
add
a
new
11th
property
to
the
you,
you're
the
photo
author
and
I'm
the
app
author
consumer.
You
add
a
new
property
to
your
to
your
library.
D
B
D
A
B
Well,
that's
actually
backwards
because
the
application
knows
what
the
metadata
looked
like
three
versions
ago.
The
library
knows
what
it
looks
like
today:
you're
downgrading
by
accepting
the
data
from
the
user.
E
Yeah
I
mean
like,
I
think
I
think
the
question
becomes
like
how
do
we
communicate
what's
happening
to
users
right?
So
one
option
we
have
is,
we
could
say
if
you're
actually
in
the
library
and
you
enable
source
generation,
and
we
detect
that
the
closure
depends
on
types
that
are
not
coming
from
your
library
but
from
somebody
else's
library.
You
could
that
we
could
give
a
diagnostic
and
say
hey,
keep
in
mind
that
we
bake
in
the
shape
of
this
thing
now.
E
B
B
Earlier
point,
if
you're
doing
aot,
your
choice
is
get
the
link
or
warning
that
you're
calling
the
reflection
thing
or
the
source
generator
warning
that
you're,
depending
on
types
that
you
didn't
write.
E
Yeah
I
mean
like
that's,
why
I
mean
we
need
to
be
mindful
of
signal-to-noise
ratio
for
sure,
but
I
think
the
question
becomes
once
you
like.
I
think
people
will
have
this
mental
model
that
the
source
generator
has
100
fidelity.
They
just
have
to
jump
through
them,
hoops
to
turn
it
on
right,
and
so
the
question
is
now
after
they
turn
it
on,
like
one
of
the
cases
where
you
can
observe
behavior
differences
right
and
how
can
we
make
sure
people
are
aware
of
them
right,
and
that
seems
like
one
easy
to
make
pitfall
here.
A
E
Sport
of
yeah,
I
think
that
I
mean
we
can
probably
like
scope
things
out
like
string
and
hints,
because
we
know
that
those
are
basically
fixed
right
but,
like
you
know
things
that
are
like
you
know,
some
other.
You
know
users,
you
know
type,
basically,
that
you
end
up
sucking
in
that
yeah
that
one
might
be
an
issue
that
exposes
more
data
in
the
future,
which
I
think
I
mean
we
know
from
nuget
graphs.
E
B
Yeah
and
while
it's
probably
not
expected
with
current
net
application
models
that
you
would
end
up
with
a
random
library
from
the
future
without
having
rebuilt
your
application,
it
is
possible
once
you
end
up
with
the
one
library
referenced,
another
library
which
is
referenced
by
the
application,
because
now
it's
everybody
needs
to
always
go
re-run
whatever
or
we're
basically
moving
into
a
shared
source
world.
At
that
point,
as
far
as
serialization
is
concerned,
because
everyone
needs
to
recompile
after
everyone
else
to
see
if
they
got
all
the
the
data
correctly.
E
B
D
Right
disguising
wasn't
a
thing
before
right,
like
xml
serializer,
serializer
data
contract
serializer,
even
like
binary
formatter
right,
like
the
type
really
drove
the
serialization
in
those
worlds.
Right,
like
you
mark
this
attri,
you
put
an
attribute
on
this
on
this
property,
saying
whether
it's
serializable
or
not,
etc.
D
E
E
Yeah
yeah,
I
mean
like
that,
but
that's
what
I'm
saying
like
if
the
basically
authorization
works
like
this,
that
somebody
decides
who
the
root
type
is
and
then
from
there.
The
closure
follows
right
and
some
people
explicitly
designed
the
type
of
civilization
and
and
others
didn't
right.
So,
like
you
always
get
some
amount
of
randomness.
E
Because
of
that
I
think
the
the
the
problem
here
is
that
the
party
that
decides
how
the
civilization
happens,
versions
at
a
different
grade
that
the
type
itself
right
and
that
is
kind
of
the
difference
between
one
term
reflection
and
and
static
generation.
Right,
that's
really
the
only
mean
thing:
yeah.
B
Technically,
you
could
intercept
the
default
xml
serializer
by
pre-generating,
an
xml
serialization
assembly
for
whatever
type
you
were
wanting
to
do
and
you
can
rewrite
what
it's
serialization
would
have
done,
but
that
that's
like
no
one
ever
would
have
talked
about
doing
this.
Because
it's
nonsense,
I
mean
I'm
sure
it's
been
I'm
sure
it
has
been
done
because
people
like
attacking
serialization
code
but.
E
I
mean
just
to
throw
it
out
there
right.
A
different
design
would
be
all
the
libraries
mark,
the
types
that
they
want
to
serialize
right
and
then
at
the
application
level.
You
just
collect
all
of
those,
and
then
you
only
generate
one
json
contest
at
the
application
level
right
and
then
just
find
a
way
to
inject.
That.
B
E
What
I'm
saying
you
find
out
a
way
how
to
inject
it
right?
Okay,
if
the
mechanism
requires
the
user
to
pass
it
in,
that
might
be
complicated
because
yeah,
the
user
doesn't
actually
write
the
call
side
yeah.
The
point
is
that
at
the
application
layer,
you
know
the
the
effective
versions
of
everything
right
right.
B
One
thought
that
I
had
bounced
off
of
laomi
me
last
week
was
you
know?
Either
we
go
the
wcf
interface
for
factories
approach
or
we
say
hey.
We
can
get
rid
of
the
factory
types
because
we're
allowed
to
say
an
interface
has
a
static
member
now,
but
that
this
all
switched
to
things
where
everything
was
being
a
static
interface
driven,
but
that
still
has
the
problem
of
it
leaks
into
your
model
and
steve's
generic
method
case
is.
B
He
has
to
change
a
constraint
to
say
that
he
wants,
and
I
can
serialize
myself
with
jason,
serializer
or
he'll
still
get
the
linker
warning
and
so
yeah.
I
don't
know
that
we
have
like.
B
I
think
it's
well
known,
that
I
dislike
serializers,
and
this
is
just
really
exposing
more
of
the
problems
with
them
existing.
I
do
like
the
code
gen,
though.
A
A
This
is
a
model
for
an
array
collection,
strings
list.
Dictionaries
will
look
similar
to
this
basically
past
the
generated
method
for
the
element
type
for
dictionaries.
You
we're
going
to
get
the
one
for
the
for
the
key
type
as
well
pretty
straightforward.
Either
you
need
the
custom
converter
you
don't
and
for
integer
is
the
primitive
converter
case.
This
is
a
little
still.
We
retrieve
this.
From,
like
internal,
I
mean
from
a
from
a
static
property
to
get
like
a
singleton
instance
of
in
in
32
converter.
D
A
Yeah
and.
A
So
well,
all
this
is
doing
is
just
checking
if
there's
a
custom
converter
and
the
options
that
someone
has
added.
So
when
you
see
that
kind
of
change,
what
because.
A
D
A
A
Cool
then
this
is
another
poco,
my
point
so
here
I
just
wanted
to
show
what
the
generated
serialization
first
parts
look
like,
because
we
just
have
an
internal
and
two
in
two
integers.
It
doesn't
yet
contain
the
code
for
honoring
some
of
the
options,
but
in
a
case
where
you
say
today,
we
have
I'm
proposing
I'm
going
to
propose
a
list
of
options
that
we
will
honor
during
this
method.
Things
like
ignore
null
and
simple
cases
like
that,
but
yeah.
A
So
we
can
consider
like
an
option
for
you
to
tell
us
that
design
time
what
options
to
ignore
like
so
that
we
can
have
like
the
fastest
could
possible
if
you're
not
going
to
use
like
any
customization.
A
Yeah
for
sure,
and
then
we
pass
that
to
yeah
so.
E
A
So
common
case,
we,
if
you
tell
us
like
if
we
can
check
at
runtime
if
you
used
our
default
camera
case
implementation,
so
you
well.
I
guess
you
yeah,
then
we'll
compute
the
value
once
and
cut
and
cache
it
like.
We
can
update
this
code
to
to
be
able
to
like
compute.
It
won't
scratch
it
and
then
do
it
again
and
presumably.
A
Yeah,
I'm
just
thinking
if
you
didn't
tell
us
that
up
front
because
we
don't
know
what
the
option
is
like.
We
can
have
a
design
time
thing
to
say:
hey
I'm
going
to
use
camo
case
and
that
will
make
it
that
will
make
the
implementation
easier.
But
for
now
the
assumption
is
we're
going
to
read
that
from
the
options
the
first
like
the
very
first
I
mean.
B
Yeah
and
if
you
do
have
a
custom
options
where
you
could
have
specified
a
different
policy
line
83,
the
first
argument
could
be,
you
know,
underscore
x,
property
name:
question
mark
question:
mark
equals
new
json
encoded
string
of
transform
according
to
the
option
name,
transformation
like
right,
because,
yes,
I
took
a
note
on
for
implementation,
notes
on
this,
that
you're
going
to
encode
the
string
every
time
and
it
should
use
json
encoded
string
but
to
and
save
that
to
a
field.
So
it
doesn't
need
to
do
the
work
every
every
every
ever.
N
G
I
assume
we
don't.
I
assume
we
don't
support
or
find
breaking
naming
converters,
whatever
they're
called
that
change,
what
they
output
each
time.
They're
called
right
like
they
need
to
be
deterministic,
same
input,
same
output,.
B
F
It's
cash,
so
if
you
randomly,
you
know,
day
of
the
week,
start
adding
stuff
to
it.
You
know
just
the
first
time
you
get
called
for
that
particular
property
on
a
particular
poke
would
only
get
called
once.
G
I
A
You
sh
you
shouldn't,
I
mean
you
can't.
E
A
A
This
func
is
used
within
the
serializer.
You
pass
it
along
with
the
metadata
for
the
type,
so
the
serializer
knows
to
call
this
optionally,
I'm
proposing
that
we
expose
it
so
that
users
can
call
it
like
I've
shown
here,
and
that
does
like
this
gives
the
best
performance
you
can
imagine,
because
I
mean
for
through
for
throughput
scenarios
that
is
before
startup
is
like
the
same
performance
as
just
passing
into
the
serializer,
but
this
does
have
the
problem
that
eric
is
talking
about.
N
A
G
A
Yeah,
I
think
for
all
I
guess,
we'll
look
over
them,
but
I
think
for
all
the
all
the
options
that
we
have.
I
think
they
can
easily
be
expressed
as
like
constants
that
you
can
tell
us
as
design
time
and
in
that,
in
that
case
won't
take
options.
Instance,
because
you've
told
us
what
you
want
to
do
up
front.
E
A
A
A
Yeah,
if
you
we
have
like
an
enum
like
say,
use
like
built-in
built-in
camera
case,
then
we
know
what
implementation
should
be.
But
if
it's
something
else,
then
we
cannot
support
that,
except
for
doing
something
like
this.
G
A
G
B
G
D
A
B
On
online
30
right
now
you
have
two
options:
you
have
the
visible
one
that
you've
passed
null
and
then
you
have
the
implicit
one
because
you're
in
jsoncontext.default
so
you're
in
a
jsoncontext
instance,
you
already
gave
jsoncontext
a
set
of
options.
That's
the
set
of
options
that
matters
you
shouldn't
have
two
sets
of
options,
because,
if
they're
in
conflict,
we
have
no
idea
what
to
do.
A
Yes,
yeah
for
sure
so
that
that
would
change.
I'm
just
wondering
if
there's
more
to
the
feedback
on
that.
E
We
can
either
say
we
have
if
statements
for
everything
that
can
be
configured
like,
we
have
like
all
four
or
five
different
casing
providers
that
we
that
we
might
code
for,
for
we
are
saying
no,
you
have
a
way
somehow,
with
an
assembly
level
attribute
or
whatever
to
say
here
are
the
options
I
want
to
actually
use.
I
actually
want
to
use
camera
case.
I
actually
want
to
use
pesticides
and
then
the
generator
only
has
to
emit
code
for
those
and
preventing
lt
the
throws-
or
you
know,
do
a
runtime
fallback
right.
B
Yeah,
I
don't
know
that
we'd
be
able
to
do
that,
because
the
place
that
the
options
got
specified
in
the
place
that
the
generator
is
like
it,
one
of
the
constructors,
took
in
options.
So
you
you
can't
know
when
you
get
in
this
method,
what
options
you
would
have
been
given.
It
could
generate
two
versions
of
the
method,
one
for
the
default
options
where
we
know
what
the
default
transformation
is
slash,
use
the
json
name
or
whatever
the
name
of
that
attribute
is
for
generating.
B
This
is
the
name
I
will
use
and
then
the
other
would
use
the.
I
will
make
a
field
to
hold
the
json
encoded
string
of
the
name
that
the
options
said
that
I
needed
to
use
once
I
got
here
right,
but
I
don't
think
we
can
actually
do
any
magic
of
asserting
what
types
we
have,
because
we
can't
tie
any
particular
call
with
any
particular
execution,
because
we
had
to
jump
through
an
engine
in
the
middle.
A
Okay,
so
the
model
today
I
have
so
we
keep
track
of
the
internet
options
instance,
and
then
these
are
the
options
I'm
proposing
that
we
can
honor,
and
these
are
the
ones
where
we
will
fall
back
to
the
serialization.
We
let
this
realize
serializer
do
it
and
in
this
mode
I
from
this
set
of
supported
things.
I
was.
A
I
don't
have
this
as
part
of
the
proposal,
but
we
can
so
I
was
going
to
say
we
can
consider
like
something
like
this
telling
us
which
ones
to
dial
back
and
which
ones
not
so
or
no.
It
seems
like
there's
an
alternative
module,
we're
talking
about
where
people
are
telling
us
what
to
to
honor
instead
rather
than
well.
This
is
this
is
the
the
list.
I
guess
it
doesn't
matter.
A
A
A
F
Yeah,
you
know
to
be
fair
that
that
did
come
very
recently.
You
know
the
ability
to
shortcut
and
use
that
funk,
and
it
does
have
some
caveats
right.
If
you
call
that
punk
you're
not
gonna
get
some
of
the
services,
this
serializer
provides,
like
exception,
handling,
you're
gonna,
get
the
raw
reader
exceptions
or
raw
writer
exceptions
or
whatever.
So
you
have
to
kind
of
know
what
you're
doing.
I
think
in
that
particular
case
anyway,
but
yeah.
We
need
to
fix
the
options
parameter.
B
F
Yeah
I
mean
we
can
generate
whatever
code.
We
want
inside
the
serialized
method,
but
it
would
be
redundant
because,
when
you're
calling
the
serializer
that
the
new
methods-
because
it
has
a
tri
catch.
B
Right,
I'm
just
like
the
it
could
still
always
be
a
jason
serialization
exception
wrapping
something
else.
Like
you
basically
control,
I
mean
you
control
everything
of
even
if
you're,
making
new
methods
the
top
level
methods
could
do.
If
we
wanted
try
do
some
stuff
catch,
the
jason
reader
exception
and
wrap
them
as
a
json
serialization
exception,
but.
F
I
think
the
point
here
is
that
when
you're
calling
that
funk,
you're
calling
the
raw
generated
code,
which
has
no
try
catch
right
but.
E
But
I
think
that
I
mean
we
can
probably
also
discover
that
you
want
to
expose
this
so
far.
You
know
fast
past
anyways,
because
I
mean
one
thing
we
should
be
careful
for
is
that
if
the
behavior
differs
drastically,
if
it's
just
catching
exceptions,
maybe
that's
okay,
but
if
you
know
the
you
know,
the
cls
fronts,
for
example:
don't
support
certain
combinations
of
options
or
something,
and
then
the
other
one
would
that
I
think,
might
be
a
recipe
for
disaster,
because
then
people
will
not
be
able
to.
E
A
The
only
thing
I
wanted
to
say
that
might
help
inform
decision.
Is
that,
like
you
do
get
so?
This
is
what
passing
that
generated
context
will
give
you
today
relative
to
what
you
get
with
this
realizer
today,
but
this
is
what
you
could
get
if
you
call
it
yourself
and
this
these
are
throughput
numbers
so,
like
I
guess
my
proposal
here
that
people
will
care
about
this
enough
to
like
like
this
is
the
only
reason
why
you
would
do
this
and
do
the
right
thing
to.
E
E
Right
so
I
mean
I
mean
correctness
is
more
important
than
perf
right.
So
the
question
is
like:
if
we
can
get
this
to
the
point
where
it's
quote
unquote
correct,
I
think
it's
fine,
but
if
it's
like
well
we
don't
support
half
the
options.
So
you
know
your
mileage
might
vary.
Then
that
seems
like
a
bug
farm
right,
because
then
people
will
use
it
because
they
tell
them
it's
faster,
but
then
oopsie
daisy,
you
apply
the
converter
somewhere
and
then
suddenly.
M
F
G
B
Well,
I
mean
yeah.
The
problem
is
because
the
right
now
the
context
takes
the
json
serializer
options
value
and
there
are
things
in
that
value
that
mean
that
you
shouldn't
call
the
the
easy
method.
That's
the
complication,
but
as
long
as
the
thing
gets
generated
in
such
a
way
that
it
can
ask
that
it
can
know
the
answer
of,
should
I
be
using,
or
am
I
allowed
to
have
used
this,
and
maybe
it
has
to
cache
it
on
the
first
call,
then
you
know
it's
would
still
work.
G
Right,
you
basically
have
a
few
options:
either
you
specify
everything
to
the
description
which
I
believe
we
have
in
the
json
serializer
attribute.
So
we
we
make
the
json
serializer
attribute
as
fully
complete
as
possible
such
that
it
contains
all
the
options
that
are
relevant
and
it
knows
at
compile
time
whether
it
can
support
something
or
not,
and
it
only
generates
the
things
that
it
can
support.
G
And
then,
if
you
try
and
write
the
code
that
uses
it
and
it's
not
supported
it
fails
to
compile
option
number
two:
is
you
have
to
pass
something
at
runtime?
You
still
generate
something
at
compile
time
and
the
thing
that
you
call
checks
to
see
whether
the
the
thing
that
you
passed
in
can
be
supported
by
what
was
generated
if
it
can,
and
hopefully
that
is
a
fast
check.
You
fall
through
to
the
fast
case
and
if
it's
not.
D
G
Fall
through
to
the
slow
case,
which
is,
and
so
it's
always
correct,
but
it's
pay
for
play
and
then
and
then
there's
the
other
option
of
well.
We
assume
everyone's
going
to
test
everything
fully
and
and
we
throw
an
exception
if
you
use
the
thing
and
it's
not
supported
and
that
one's
not
great.
A
G
Well,
yeah,
I'm
saying
there's
two
routes
to
pursue.
One
is,
if
you
expose
the
options
on
the
json
serializer
attribute
such
that
the
code
is
generated
based
purely
on
those
options,
and
you
don't
have
the
ability
to
override
those
options
at
runtime,
then
you
can
just
you
can
call
that
method
directly.
B
Yeah
and
then
the
hybrid
approach
would
be
that
you
generate
the
using
only
the
attributes
on
the
type
slash
attribute
or
values
passed
in
the
go
pre-generate.
This
code
attribute
as
static
methods,
so
there
is
never
an
option
that
got
referenced
and
then,
if
you
call
the
static
one,
that's
obviously
the
in
the.
In
the
absence
of
any
options
right.
A
B
Right,
it
would
be
that,
well
I
mean
it
had.
So
it's
if
you
have
the
public
member
and
the
and
you
gave
it
an
option
or
and
you're
built
on
an
options
that
doesn't
support,
calling
the
fast
path.
Then
it
would
just
call
the
serializer
and
the
serializer
would
be
given
the
private
version,
not
the
public
version.
So
it's
like.
G
I
think
it's
what
jeremy
just
said,
my
preference
is:
we
basically
generate
two
things:
one
that's
private
and
used
by
the
serializer.
If
it
can
and
one
that's
only
generated
and
is
public
if
and
it's
static,
and
it
doesn't
accept
options
and
it's
based
purely
based
on
what
you
specified
in
your
attribute.
N
A
B
A
A
B
When
you
are
wrapping
a
type
that
uses
or
when
one
part
of
your
type
comes
from
a
library
that
used
pascal
case
in
there
jason
and
you're,
calling
or
you're
wrapping
it
with
another.
H
B
H
A
A
B
The
the
problem
is
the
serializer
works
on
options,
and
the
statement
here
is:
if
you
want
the
fast
path
code
to
be
public,
it
cannot
be
based
on
options.
So
you
need
to
replace
all
of
the
options
for
this
new
method
that
only
the
generator
is
building.
So
it's
now
a
generator
feature,
not
a
serializer
feature.
B
Again,
you're,
assuming
that
every
type
that
is
in
the
closure
of
this
type
uses
the
same
model,
which
is
not
necessarily
true
granted.
If
we
say
that
the
like
the
local
json
name,
property,
win
or
json
property
name
wins,
then
maybe
it's
already
been
solved
because
the
intermediate
thing
had
to
deal
with
being
called
with
a
set
of
options
that
it
wasn't
compatible
with.
But
let
me
turn
around
and
ask
a
different
question
and.
G
I
don't
know
the
answer:
we
support
constructing
adjacent
serializer
options,
configuring
things
on
it
and
passing
that
in
do
apps,
does
a
given
app,
always
only
create
one
of
those
and
always
configure
the
options,
always
the
same
way
and
pass
that
same
options
to
every
serialized
call.
A
B
And
if
you
had
different
options
for
two
different
route
level
types,
then
then
that
would
be
the
case
where
you
would
now
need
it
as
a
type
level
experience
in
the
json
in
the
source.
B
G
A
I
can
imagine
where
you
need
to
do
two
different
options
for
the
same
type.
Let's
say:
you're,
sending
some
response
to
the
two
different
apis
that
need
different
casing.
For
example,
these
were
reduced
to
different
options.
A
G
B
A
Not
at
the
collision
like
we,
the
first
one
we
see
we
use
one
name
and
then
the
second
one.
We
use
a
fully
assembled
qualified
name,
but.
A
A
B
A
B
B
H
I
I
I
I
So
one,
I
think
one
interesting
thing
is
that
in
asp.net
core,
the
user
has
to
basically
set
up
options
globally.
That
get
that
then
get
sent
to
asp.net
core
via
die,
and
we
call
serialize
and
we
don't
know
we
don't
want
to
be
the
ones
having
to
look
up
the
type
info
at
the
call
site.
So
how
does
that
work?
In
those
situations
where
you,
where
you
aren't
passing
the
contacts
directly
to
the
call
site,
because
you
don't
own
the
call
site,
the
call
site
is
owned
by
something
else.
B
One
possible
answer,
just
thinking
of
how
things
work
is
that
the
asp.net
di
right
now
it
takes
a
serializer
options
that
the
whole
thing
with
this
is
that
basically
becomes
the
dead
path
and
you
shouldn't
be
using
it
anymore
right
and
it
can
take
a
json
serializer
context,
which
is
the
the
parent
of
all
the
stuff
which
includes
the
options,
and
then
the
di
uses
that
that
has
the
lookup
of
given
this
type
where's,
the
pre-generated
metadata.
So
got
it.
It's
still
reflection
based
in
that
it
does
a
a
switch
on.
B
B
A
Okay,
okay,
so
running
through
these,
we
have
the
json
sterilizer,
attributes
kind
of
can
be
dynamic,
is
useful
for
polymorphic
serialization
and
it
just
allows
the
linker
not
to
trim
out
the
type
because
nowhere
else
in
the
object
graph
references
directly.
So
if
you
have
like
an
object
array,
there's
no
way
to
to
track
the
metadata
for
like
a
string
and
integer
property.
So
this
allows
us
to
do
that.
Question.
H
A
Yeah,
so
it's
public-
this
is
a
copy-paster.
So
today
there's
a
this
ongoing
discussion
around
where
we
should
like
whether
we
should
ship
this
within
system
text
json
dll
or
we
should
generate
it
as
part
of
the
user
assembly.
I
am
going
to
circle
back
here
and
not
discuss
it
within
the
context
of
api
because,
like
other
reasons
other
things
to
consider,
but
with
the
I
guess,
the
idea
here
is
like
we
either
ship
this
in
system
taxation
or
we
generate
an
user
assembly
internally
under
this
namespace.
G
We
do
intend
for
the
user
to
write
code
that
says
assembly,
colon,
json
serializable.
It's
just
a
question
of
whether
we
admit
it
into
their
assembly
or
we
ship
it
ourselves.
A
A
H
B
G
B
G
A
My
understanding
of
it
is
that
there
are
some
scenarios
where
we
might
not
be
able
to
provide
the
generator.
As
far
as
like.
G
The
generators
yeah,
the
generator-
is
an
independent
parameter.
So
if
you
don't
the
the
the
recommendation
from
the
rosalind
team
was,
it
makes
more
sense
to
have
the
generator
provide
its
its
triggering
mechanism
so
that
you
don't
you
know
you
you're,
always
in
the
the
user,
is
not
given
the
the
entry
point
into
the
generator
unless
the
generator
is
also
present
and.
K
J
G
G
G
You
know
that
you
know
we
don't
want
to
add
this
to
every
assembly.
That's
that's!
Definitely
I
I
would
say
that
that
characteristic
is
higher
priority
than
the
torn
state
characteristic.
Where
you
you
reference
the
attribute,
but
don't
have
the
generator
present
this.
This
is
a
bit
of
an
ongoing
discussion
with
with
the
rosslyn
folks,
so
I
I
don't
think
we
have
a
great
best
practice
here,
yet
the
I
think
the
existing
best
practice
has
these
rough
edges,
so
yeah.
G
B
B
What
version
did
you
build
against
attributes
or,
however,
the
metadata
is
encoded,
it's
just
it.
It's
it's
just
weird
of
when.
G
B
G
Attribute
here
and
it
doesn't
help
because
it
it
it
will
trim
out
the
it
will,
suppress
the
application
of
the
attribute,
but
not
the
attribute
itself.
Sorry
go
ahead,
david.
I
Question
so
we
aren't
putting
the
contacts
in
source
generation
namespace
right
just
the
attribute.
That's
like
a
typo.
A
We
are
putting
everything
in
like
all
right
metadata
stuff,
because
we
do
not
so
from
the
sample
here,
like
users
do
not
have
to
reference
landing
space
just
pass
the
context
directly.
I
don't
expect
much
usage
is
where
you
actually
try
to
assign
it
or
well.
I
B
B
The
http
context
or
the
yeah
yeah
the
way
that
asp.net
was
going
to
fix
their
di
problem
by
was
by
changing
to
that
type.
But
it's
under
a
sub
name
space
and
marked
as
browser
visible,
never.
A
Yeah
yeah
yeah
for
this
one
in
particular,
yeah.
It's
fine.
If
we
say:
okay,
it's
a
top
level
type
that
uses
my
interactive,
maybe
yeah
higher
energy,
but
for
some
of
the
rest
of
these
like
we
definitely
want
to
keep
them
like
hidden.
Well,
at
least
my
proposal
yeah.
I
A
Yeah,
we
don't
want
to
get
to
a
point
where
we
are
tired
because
of
the
exposed
functionality
or
because
a
lot
of
people
are
using
it
that
we
are
essentially
locked
in.
So
these
the
the
purpose
of
the
approach
of
making
all
of
these
things
that
it's
a
browsable
never
is
so
that
people
don't
interact
with
sleep
much.
A
D
That's
never
gonna
change
like
that's
what
that
that
strategy
is
never
gonna
change
that
we
can't
break
any
of
this.
We
can
never
change
behavior.
We
can
never
delete
one
of
these
things
or
rename
them,
because
people
are
going
to
source
jen,
their
stuff
and
then
ship
that
assembly
and
then
if.net
7.
We
change
something
and
it's
now
it's
broke
so
whether
somebody's
going
to
use
it
or
not,
it's
not
going
to
change
our
strategy.
How
we
version
this
stuff,
yeah.
A
Yeah
I
mean
I
I
I
do
agree,
but
I
mean
if
we
don't
want
people
to
use
it
and
the
reason
why
we're
exposing
it
and
what's
the
harm
in
making
things.
As
for
the
top
level,
stop
way
you
might
interact
with
it,
but
for
things
like
like
just
inviting
for
itself
or
like
you
know,
the
delegates
were
generating
or
like
the
internal
metadata
classes
that
we
need
to
retrieve
like
do.
We
need
to
to
be
friendly
and
let
people
use
that
we
don't
have
first
class
features
around
how
they
should
be
used.
A
H
So
I
don't
know
if
you
talked
about
versioning,
but
eric
you
mentioned
that
in
dot
net
seven
we
cannot
break
it
when
in
doubter
seven
we
have
updates
to
source
generator.
That
will
rewrite
different
code.
Why
would
we
not
be
allowed
to
break
it.
D
A
D
H
I
Do
that
we
shouldn't
work
it
I
have
one
more
thing:
could
we
could
we
make
like
scroll
up
to
the
top?
Could
we
make
the
get
type
info
generic
as
well,
or
could
we
have
a
generic
overload
of
that.
I
B
A
A
Actually,
yeah,
it's
actually
the
generic
one,
we're
returning
we're
just
like
casting
it
to
to
this.
So
it's.
B
I
F
I
I
F
I
But
that
only
works
that
only
works
if
you
control
the,
if
the
caller
is
going
to
call
serialize
directly
and
pass
in
the
information.
Yes,
when
you're
giving
it
like
in
espnetcore,
you
return
types
to
the
system
and
the
system
has
the
the
entire
context
for
for
all
types,
and
it
has
to
kind
of
like
call
serialize
today,
and
all
I'm
saying
is
that
if
there
was
ever
a
point
where
we
had
a
generic
call
site,
we
could
call
the
our
someone
could
call
the
get
type
info.
A
Yeah,
I
guess
I'll
check
offline
with
you
on
how
to
make
it
faster
with
generics,
but
actually.
K
Good
question
about
the
generic
thing,
like
is
the
idea
that,
with
a
struct
you
get
if
the
generic
parameters
destruct,
you
get
a
custom
version
of
the
git
type
info
method.
That's
removes
like
the
dead
code
for
all
the
other
types.
Is
there
something
else
going
on
there.
I
I
don't
think
no,
no
there's
a
different
technique.
You
can
use
that.
Isn't
the
the
struct
to
eliminate
the
other
code
pattern,
because
because
for
the
most
part
I
don't
think
t
would
be
a
struct.
It's
like
some
some
type
defined
by
user,
but
you
can
use
instead
of
a
dictionary
or
a
bunch
of
if
you
can
use
a
generics
to
to
generate
a
key.
I
just
look
up
into
an
array,
so
you
don't
have
to
do
crazy
interaction,
I'll
paste
it
in
the
in
the
chat.
So
you
can
look.
A
B
So
yeah
I
mean
we're
now
technically
at
time
and
basically
haven't
looked
at
any
of
the
api,
so
I
don't
know
that
it
makes
sense
to
start
really
looking
at
the
api.
A
E
A
Yeah,
I
just
wanted
to
ask
like
what
to
prepare
for
like
are
we?
E
A
A
E
Anything
there
it's
going
to
be
past
preview,
4
right,
so
that
we
will
not
have
time
to
do
that
in
the
next
10
days.
I
guess
but
be
sure
these
capture
it
in
the
notes
and
then
I
think,
for
preview,
4.
I'll,
probably
just
spend
an
hour,
because
we
don't
have
many
apis
anyway.
On
on
on
thursday,
that's
the
first
item
and
see
how
far
we
get
with
that.
B
Yeah
and
you
know,
while
we
said
no
breaking
changes,
that
is
no
breaking
changes
once
we
hit
an
rtm
if
we
break
something
between
preview,
4
and
preview
5,
that's
fine.
I
I'll
put
the
the
thing
in
the
chat.