►
From YouTube: GitHub Quick Reviews
Description
Multistreaming with https://restream.io/
A
We
are
live
with
another
session
of
uh.net
api
reviews.
We
have
a
small
agenda
that
we're
hoping
to
get
through
today
and
then
we
are
really
really
really
hoping
we're
going
to
get
to
the
general
backlog,
though
recent
trend
says
we're,
probably
not
actually
going
to
all
right
so
make
sync
ssl
stream
authenticate
as
overload
with
ssl
options
public
three,
four,
six,
three
eight.
B
B
A
B
A
C
D
G
G
Basically,
what
what
we
would
like
to
add
his
ability
to
annotate
code
with
something
that
tells
linker
that
code
that
is
behind
this
annotation
is
kind
of
not
interesting
to
analyze.
Kind
of
the
problem
with
linker
is
that
linker
tries
to
find
unused
code
in
in
your
app
in
dot
net
5.
G
We
are
adding
a
way
how
to
kind
of
make
linker
see
through
more
on
the
reflection
patterns
that
people
can
have
that
are
really
really
difficult
to
analyze
to
kind
of
find
unused
code,
but
there
will
still
be
many
reflection
patterns
that
people
use
that
are
not
possible
to
analyze.
A
kind
of
there
are
valid
use
cases
for
people
to
use
reflection
in
a
way
that
linker
will
not
be
able
to
analyze
it,
and
if
people
turn
on
linker
on
that,
they
would
get
a
huge
amount
of
warnings
about.
G
Like
oh,
like
there's,
some
reflection
that
I
cannot
figure
out
and
it
wouldn't
really
be
actionable
for
them
to
kind
of
go
through
those
warnings
and
kind
of
scratch
their
heads
about
like.
Oh,
what?
What
can
I
do
with
this?
What
we
would
like
to
be
able
to
do
is
just
for
library
authors
to
to
place
something
on
either
their
library
or
specific
methods
within
the
library
that
tells
the
linker
that
hey
like
here.
I
am
going
to
do
crazy,
crazy
amount
of
reflection.
G
G
For
example,
you
have
have
a
serializer,
and
there
are
some
like
these
unsecured
serializers,
that
kind
of
let
you
have
type
name
in
the
in
the
payload,
and
they
will
just
go
and
look
up
the
type
somewhere
and
kind
of
try
to
deserialize
it,
and
this
is
really
difficult
to
analyze.
Statically
because
kind
of
you
don't
know
what
the
payload
will
be
so
kind
of
the
the
library
router
will
be
able
to
annotate
that,
like
oh
here,
I
have
the
api
that
can
do
this
crazy
and
secure
this
deserialization.
G
And
kind
of
the
the
bigger
picture
is
that,
eventually
in
the
linker
space,
we
would
like
to
extend
this
further.
So
the
question
will
be
whether
we
want
like
specific
attributes
or
or
kind
of
a
general
purpose
attribute,
because
we
would
like
to
also
be
able
to
find
a
code
that
is
single
file.
Unfriendly,
for
example,
like
there
are
apis
even
within
framework
that
are
unfriendly
for
single
file
compilation.
G
For
example,
if
you
have
assembly
the
location
api
you
you
call
that,
but
you
are
a
single
single
file
compilation,
but
what
is
it
really?
The
location
that
this
api
should
return?
G
And
the
third
thing
that
we
would
like
to
think
about
in
the
linker
space
is
detection
of
aot
unfriendly
patterns,
and
that
would
be
like
I
don't
know
reflection
I
made
or
like
whatever
thing
that
you
know
uses
a
lot
of
it,
the
that's!
That's
just
something
to
consider
that
we
are
reviewing
this,
whether
whether
we
would
like
something
more
general
purpose
or
just
like
single
specific
purpose
thing.
G
This
this
would
be
potential
you
can.
You
can
even
put
it
on
on
a
constructor
of
some
class,
that
kind
of
it
once
you
instantiate
it.
It's
going
to
do
stuff
that
is
difficult
to
analyze
kind
of
in
in
dot
net
5.
We
would
like
linker
to
be
able
to
give
you
actionable
warnings
if
there
is
some
reflection,
news
that
couldn't
be
reasoned
about
statically,
but
those
warnings
will
be
basically
like
hey.
G
You
are
calling
this
api
from
this
location
and,
like
I
don't
know
what
the
system
type
is
that
that
you
are
using
and
that
that
might
not
be
too
actionable.
If
you
get
this
warning
within
a
nougat
library,
so
kind
of
this
is
this
is
kind
of
meant
for
maybe
library
outdoors,
that
if
they
run
the
linker
tooling
on
their
library
and
they
they
find
like
here
here,
you
have
reflection
buttons
that
are
difficult
to
analyze.
H
Can
I
try
and
parrot
this
back
to
you
basically
without
this
someone's
going
to
run
the
linker
on
my
library
and
they're,
going
to
get
some
errors
which
may
or
may
not
be
intelligible
to
them,
and
I
can
improve
the
experience
for
them
by
instead
putting
this
attribute
on
the
relevant
method
in
order
to
give
them
a
crafted
message
that
will
make
their
life
better?
Is
that
right?
H
I
J
Would
it
be
useful
to
have
the
url,
because
in
almost
all
other
cases,
where
we
want
to
provide
guidance,
a
string
based
approach
only
allows
you
to
do
so.
Much
very
often,
you
want
to
point
people
to
an
actual
document
that
they
can
read.
And,
yes,
you
can
put
a
url
in
that
message,
but,
depending
on
how
you
are
using
the
attribute,
you
might
find
that
you
don't
want
to
be
in
the
business
of
auto
generating.
J
You
know
some
sort
of
like
url
detection
mechanism
or
something
so
would
it
be
useful
to
just
have
a
url
property
here
that
we
can
set
initialize,
and
then
you
know
the
link
or
whatever
produces.
That
message
can
automatically
include
the
url.
If
it's
set
up.
I
We
do
expect
to
use
urls
there
for
like
some
of
even
other
stuff.
Do
I
understand
correctly
that
the
proposal
is
that
we
would
have
both
message
and
url,
because
for
some
url
will
not
be
a
good
solution
right?
They
probably
won't
like
you
know,
if
I'm
a
random
nuget
author,
I
might
not
want
to
put
the
url
there,
because
it's
just
hustle.
J
Right,
I
mean
that's.
Why
usually
the
way
I
would
do
it,
I
would
have
message
and
it
would
have
a
url
and
it
can
be
said
both
or
neither
right,
okay,
okay,
it
just
means
that
if
you
have
a
url
and
it's
in
the
url,
then
you
know
that
you
should
render
that
if
it's
present
as
a
url,
not
as
a
text
right.
H
C
A
So
would
this
be
if,
if
code
is
loading
a
type
by
name,
because
because
of
layering
or
whatever,
it
can't
take
a
strong
reference
to
it
that
if
you
were
calling
it,
but
you
as
the
as
something
further
downstream
did
have
a
strong
reference
to
the
thing
it's
loading,
then
the
linker
is
not
going
to
trim
it
out.
So
it's
everything's
going
to
work.
I
assume
that
would
be
when
you
would
suppress
it.
It's
like
as
long
as
you
keep
this
thing
rooted,
then
everything
will
work
or
am
I
completely
misunderstanding.
This
scenario.
I
I
G
Okay,
another
another
use
case
that
we
were
discussing
and
thinking
about
would
be.
For
example,
you
have,
let's
say
some
dependence
injection
framework,
and
this
framework
has
different
kinds:
the
different
ways
how
to
how
find
the
components
and
one
of
the
components
is
just
it
just
scans
this
and
has
them
with
the
tools
random
stuff.
G
Okay,
if
you
have
timing
enabled,
then
there
is
no
guarantee
that
the
random
stuff
that
it
will
find
on
disk
you'll
have
all
the
dependencies
available,
because
linker
didn't
see
that
so
kind
of
the
api
that
would
do
this
scanning
would
be
annotated
as
like.
I
please
don't
use
me
if
you
are
trimming,
but
there
might
be
another
way
how
to
initialize
this
bi
container
and
that
that
way
it
might
be
safe
because,
for
example,
you
you
specify
the
types
manually
and
kind
of
that
the
message
would
be
about
that.
A
I
J
J
I
J
Yeah
I
mean,
generally
speaking,
so
when
it
comes
to
grouping,
we
basically
have
two
options
for
attributes.
One
of
them
is
we
can
introduce
a
base
type
so
that
when
you're
in
the
docs
you
can
send
on
the
base
type,
and
then
the
docs
tell
you
here
all
the
derived
attributes
so
they're
somewhat
logically,
grouped
together,
so
that
you
don't
have
just
a
flat
list
of
100
elements
or
it's
namespaces
right.
These
are
really
the
two
prior
mechanisms
that
we
have
for
nullable
attributes.
We
ended
up
not
using
a
base
type
because
we
said
well.
J
The
namespace
only
has
like
two
types.
Today
we
will
add
10
types
to
that.
That's
fine
they're,
effectively
already
grouped
now,
once
we
dump
more
and
more
stuff
into
that
namespace.
That
argument
will
disappear
and
eventually
we
will
find
ourselves
with
this.
You
know
compiler
services,
kind
of
name
space
where
you
have
100
things
in
there
and
then
people
have
a
hard
time
finding
the
one
that
matters.
J
That's
the
only
thing
where
I
said.
Maybe
we
should
take
a
step
back
and
say
be
adding
all
these
attributes
now.
Maybe
there
is
some
sort
of
grouping
that
is
a
bit
more
manual
than
just
code
analysis
right,
but
it's
very
hard
to
do
this
as
a
piecemeal
thing
right,
because
if
you
only
review
one
extra
bit
at
a
time,
it's
hard
to
see
the
system
like
you
know,
grouping
or
whatever.
K
J
J
K
J
Yeah,
I'm
not
interested
in
saying
we
need
to
do
it.
All.
I'm
saying
is
that
when
you
have
cross-cutting
things
like
that,
sometimes
it's
nice,
if
they're
cross-cutting
things
are
centralized,
because,
when
you're
dealing
with
them,
it's
nice,
when
you
can
read
all
about
them
right,
if
you
distribute
them
to
all
the
namespaces,
it
gets
very
hard
for
somebody
to
get
a
view
I
mean
again
like
we
can
also
just
have
a
topic
somewhere
on
msdn.
J
That
says:
okay,
here's,
here's
all
the
steps
you
can
take
and
here's
the
12
attributes
and
the
12
different
namespaces
that
help
you
do
that.
That's
also
a
mechanism
to
do
it
right.
It's
just
that!
Generally
speaking,
this
capability
of
attributes
is
not
necessarily
amazing.
Today
already
but
yeah
like
I'm,
I'm
not
having,
like
you
know
the
perfect
solution
right
now.
All
I'm
saying
is
that
it
seems
we're
dumping
a
bunch
of
the
stuff
now
in
in
the
namespace
and
that's
always
widely.
Concerning.
J
Yeah,
I
would
not
block
on
this.
I
think
the
the
again
like
right
now
we're
trying
to
make
forward
progress
as
fast
as
possible.
So
we
approve
things
as
they
come
in
right,
but
the
problem
with
piecemeal
thing
is
that
you
know
larger
organizational
things
that
namespaces
are
harder
to
do
so
yeah,
I'm
fine
with
postponing
that
and
then
you
know,
take
another
step
and
say:
okay,
now
we
have
these
12
things
should
be.
Should
we
put
them
in
different
spaces.
L
A
I
J
I
mean
I
can
see
this
being
because
interfaces
like
in
asp.net
a
lot
of
the
interfaces
are
effectively
platform
provided.
If
we
ever
try
to
do
something
smart
with
asp.net,
then
I
can
see
that
in
the
eye
context
something
will
apply
to
interfaces
as
well.
J
I
would
generally
say,
if
you
add
assembly,
I
would
almost
always
also
add
module
like
why
not
seems
really
to
omit
that
and
if
you
add
class
I
mean
it
seems
seasonable
defense
as
well.
Basically,
everything.
I
Sure,
like
anything,
which
doesn't
have
a
capability
to
carry
code
with
it,
because
this
is
like
a
statement
about
code,
not
about
data,
so
generic
parameters,
parameters,
fields.
L
If
you're
doing
it
from
the
perspective
of
what
can
carry
code,
then
it
needs
to
be
on
delegate
because
delegate
types
are
actually
they
inherit
from
delegate
and
implement
a
custom
invoke
method
which,
on
c
sharp,
will
never
do
it,
but
an
il
can.
G
I
think
they
are
involved.
Method
needs
to
be
done
implemented.
I
don't
think
people
can
actually
provide
their
own,
but
it's
mostly
associated
with
code,
so
even
even
for
property.
I
don't
know
like
what
that
means
together
and
setter.
Therefore,
requiring
reference
code,
some
kind
of
wine
not
to
put
it
on
the
transitor.
A
Yeah
I
mean
it's
the
same
as
putting
it
on
the
getter
in
the
center.
It's
just
you
know
fewer
words
on
screen
which
goes
back
to
either.
I
think
it's
either
that
we
we
say
it
only
applies
to
methods
and
constructors,
which
are
logically
methods,
or
we
put
it
on
all
of
the
things
that
can
contain
those,
but
the
sort
of
like
skipping.
The
middle
bits
feels
weird.
G
We
could
just
go
with
metals
and
constructors
for
now,
like
I
was
thinking
even
for
the
assembly
like
in
in
those
cases.
Maybe
you
will
want
to
tank
the
whole
nougat
package
so
that
you
can
actually
see
it
in
the
ui
that,
like
oh
I'm,
linking.
Therefore
I
shouldn't
be
even
able
to
use
this
nuget
package.
A
If
you
happen
to
be
running
in
a
an
older
linker
that
doesn't
understand
the
assembly
level
attribute,
then
it
won't
produce
the
warning
when
somebody
was
using
an
assembly.
So
this
does
feel
like
because
it's
essentially
designed
for
consumption
by
an
external
thing.
It's
we
get
it
right
in
the
first
version
and
can't
change
it
or
can't
sensibly
change
it.
A
K
I
don't
fully
understand
the
pushback
of
of
not
putting
it
on
class
properties
assembly.
It
feels
like,
if
you
have
a
library
with
two
classes.
You
know
30
methods,
each
that
are
all
doing
this.
Wouldn't
you
just
want
to
slap
it
in
one
place
and
say
this
whole
thing
instead
of
having
to
put
it
on
60
different
methods.
C
I
A
Yeah,
like
I'm,
I'm
currently
copying
in
all
the
different
attribute
targets
for
the
updated
proposal,
so
I
don't
really
care
one
way
or
the
other.
I
think
we
just
need
to
decide.
Are
we
turning
it
on
for
all
of
them
or
just
the
minimalist
set,
but
but
part
of
what
we
say
here
determines
how
much
work
we
have
to
do
in
the
linker
to
detect
those
patterns
or
whoever's
producing
the
warning,
because
it'll
need
to
look
at
all
the
proper
scopes.
J
A
Well,
it's
there's
just
a
versioning
parity
problem
of,
if
you,
if
you
had
so
if
in
net
five,
we
produce
a
linker
that
understands
how
to
read
this
only
at
method
and
constructor
and
then
in
v6.
We
expand
the
attribute
targets
on
this
to
say
that
it
applies
to
anything
anything
that
is
a
method
or
contains
a
method
or
contains
a
method,
container
container
etc.
J
A
Fair,
I
don't
yeah,
I
I've,
never
written
one
of
these
tools,
so
I
don't
know
if
they
usually
try
tying
themselves
to
a
minimum
version
of
object
or
anything.
But
I
guess
if
this
lives.
J
Yeah
I
mean
I
would
generally
not
expect
people
to
be
able
to
use
the
dot
net
five
link
on
the
dot
at
six
app.
That
seems
asking
for
trouble,
because
now
we
know
we
would
have
what's
compatible
with
our
between
our
tooling
and
our
infrastructure,
which
we
generally
are
so
that
I
would
I
mean
backwards.
Compatibility
is
hard
enough,
like
also
take
on
forwards
compatibility,
so
yeah
I
mean
I,
I
think
my
general
assumption
would
be
if
we
need
to
add
more
targets.
We
can
do
so
later.
J
So
I'm
honestly
fine
with
saying
whatever
the
linker
team
is
willing
to
tackle
in
this
release.
Those
are
the
things
we
expose
and
if
there's
five
more
things
that
could
be
beneficial,
but
nobody
implements
them.
I'm
also
finding
no
legal
targets,
because
the
value
of
restricting
the
targets
is
just
that
people
apply
the
attribute
and
something
we
don't
understand.
They
get
an
error
rather
than
just
not
doing
anything
right.
So
that's
that's.
Realistically.
The
only
thing
we're
doing
here.
N
I
A
Okay,
I
couldn't
find
anything
that
we
had
a
simple
url
parameter
on
the
closest
was
the
upgraded
obsolete
attribute,
which
is
url
format.
I
don't
think
that'll
apply
here.
So
do
we
have
a
good
name
for
the
url
property.
J
G
G
A
Mean
if
the
purpose
of
when
of
when
you
do
this,
is
that
you're
executing
code
without
a
strong
reference,
then
it
sounds
like
you're
describing
the
symptom
or
the
the
code
behavior
that
you
should
apply
this
to
the
fact
that
it
produces
a
warning
with
a
message
is
possibly
going
to
get
abused,
but
there
is
a
clear
purpose
to
it.
So
I
think
the
name's
okay.
J
G
J
Yeah,
I
think
that's
in
that
case,
I
think
I
like
the
name
because
it
kind
of
it
kind
of
says
every
time
you
get
this
there's
some
other
requirement
that
you
have
to
fulfill.
I
think
it
communicates.
J
Yeah
that
one
is
harder
to
describe
an
attribute
name,
because
that's
the
that's,
basically,
the
behavior
that
most
attributes
have
right
obsolete,
like
members
marked,
obviously
can
call
other
obsolete
members
right.
So
that's
kind
of
it's
just
this.
Basically,
the
logical
fallout
of
you
know
avoiding
cascading
errors
right.
K
J
A
Yeah
and
then
sub
note,
we
may
want
to
bulk
move
these.
O
O
J
You
want
to
remove
blocking
as
well.
I
hadn't.
A
All
right
I'll
do
that
in
the
background
after
we
get
context
loaded
for
this
one,
so
get
gc
info
number
three,
four,
six,
four,
eight.
J
It's
too
much
of
rhythm.
I
only
joined
because
we
tried
it
last
week
and
then
the
linker
stuff
took
all
the
time
and
she
dropped
off
is
molly
on
the
call.
J
No
okay,
then
I
think
so.
I
read
it
briefly.
My
understanding
is
that
it's
basically
just
about
a
bunch
of
data
that
the
gc
has
that
it's
effectively
exposing
that,
and
I
think
we
had
a
similar
api
before,
but
we
basically
ended
up
grouping
things
together
so
that
you
can
get
the
data
in
an
atomic
fashion
rather
than
getting
independent
properties,
and
then
it's
unclear
at
the
point
where
you're
asking
them
you
may
not
get.
J
You
know
inconsistent
data
right
if
you
get
them
all
as
one
single
gc
info
then
well,
you
know
that
you,
this
might
still
be
a
snapshot
at
a
time,
but
at
least
the
data
that
you
get
is
all
correlated
with
each
other,
so
you
can
make
general.
You
know
computations
where
things
add
up
in
the
way
you
expect
them
to
that's.
Basically,
all
I
know,
but.
J
Yeah
I
mean
the
question
really
is
like
do
we
have
any
concerns
about
particular
things,
because
then
we
can
just
ask
over
email
and
not
have
to
bring
her
in
again.
Can
you
scroll
down
a
little
bit
jeremy
or
you
know,
whoever's,
driving
jeremy?
What's.
A
H
J
M
H
A
A
So
this
is
basically
saying
we
messed
up
with
the
api
we
previously
exposed.
Well,
since
it
contains
five
longs,
it
definitely
exceeds
24
bytes.
So.
N
Let
yes
rephrase,
but
when
we
when
we
expose
this,
are
we
effectively
obsoleting
the
other
one?
So
that's,
I
think
a
question
we
should
ask.
A
H
J
A
Are
a
bunch
of
things
here
that
I
like?
I
would
want
to
ask
what
the
purpose
is
like
you
know
index
just
what
does
that
mean?
How
does
somebody
reason
about
it?
We
have
compacted
and
then
is
concurrent,
so
it
feels
like
we're
a
little
inconsistent
with
whether
or
not
we
have
a
prefix
on
the
booleans
is
concurrent
only
the
last
gc
event
or
is
that
the
gc
operating
mode
like
so
there's.
A
J
P
J
Yeah
I
mean
also
even
if
it
would
get
rid
of
something
like
worst
case.
Let's
say
we
remove
finalizers
right
and
then
finalize
that
account
will
just
become
zero.
It
will
also
not
be
terrible
right,
so
I
feel
like
there's
not
like
having
the
structure,
not
all
this
class.
I
don't
think
constraints
ability
to
innovate
in
the
gc.
A
Yeah,
I
know
that
we
do
generally
prefer
the
signed
types
part
is
a
part
of
partly
because
of
cls
compliance,
historical
reasons,
but
do
we
think
that
there's
a
I
guess
nobody
has
63
bits
of
memory
in
their
computers
yet,
like
nobody
even
runs
that
many
address
lines.
So
maybe
we
don't
need
to
shift
all
these
to
you
long
just
to
avoid
overflow
problems.
M
L
A
Things
like
the
finalizable
object
count
which
should
be
named
to
finalizable.
Instead
of
finalize
like
that
one's
not
going
to
hit
it's
not
going
to
pass
2
to
the
63
and
the
pin
handles
count,
isn't
going
to
pass
2
to
the
63.
A
J
A
A
No
might
not
be
bad,
since
this
is
since
this
is
data
that
is
just
giving
out.
It
seems
okay,
like
turning
it
into
any
of
the
collection
types
feels
wasteful
and
the
guidance
for
returning
read-only
span
is.
It
needs
to
be
obvious
to
the
caller
what
the
lifetime
management
is
of
that
span,
and
it's
not
obvious
in
this
case,
so
it
should
not
be
spam.
M
In
in
this
case,
it
would
just
be
I
I
guess
once
you
get
an
instance
of
this,
if
it
returns,
the
array
like
the
array
is
tied
to
the
instance.
If
you
mutate
it
well,
you
mutate,
it
don't
do
that
right,
like.
A
As
long
as
as
long,
I
guess
that's
that
would
be
part
of
the
question
for
maoni
is
if
every
time
you
call
this
you're
getting
a
new
array
here,
then
it's
fine
as
an
array.
If,
if
you're
supposed
to
be
getting
a
projection
into
some
state,
that's
only
updated
every
couple
hundred
milliseconds,
then
it
needs
to
be
something
else.
P
M
Kind
of
originally
proposed
read
only
span
because
it
doesn't
matter
what
the
lifetime
is
it
it's
immutable
once
you
get
it
like.
If,
as
long
as
no
one
has
a
reference
to
it,
it
will
eventually
be
gc'd
if
it's
an
instance
member
and
if
it's
a
static
member
well
great,
it's
shared
amongst
everybody.
Yeah.
A
Read-Only
collections
is
a
better
immutable
because
it's
a
lot
harder
to
actually
cheat
and
turn
into
a
pointer
and
overwrite.
Something.
A
J
A
Yeah
and
then
the
gen
info
shouldn't.
J
M
Be
yeah
I
had
commented
on
that
in
the
issue.
It
should
be
sealed
and
have
an
internal
constructor,
because
it's
everything's
good
only
there's
no
reason
for
someone
to
instantiate
this
themselves.
M
M
J
F
F
M
D
L
L
L
No
scroll
down
just
a
little
bit
and
there's
another
variable
which
is
float,
which
is
a
percentage,
and
I
would
expect
the
pause
percentage
to
generally
be
like
a
couple
percent
and
so
depending
on
how
this
is
represented.
If
it's
between
0
and
1
or
above
or
if
it's
between
1
and
100
or
various
other
bits,
it
might
be
better
to
return
double.
Instead,.
A
Is
gonna?
You
know
this
is
not
the
the
thing
taking
up
all
the
space
in
this
type,
so
the
extra
32
bits
are
fine.
M
K
A
J
F
A
A
I
agree,
I
don't.
A
J
J
Yeah,
so
what
I
have
right
now
is:
how
does
this
relate
to
gc
memory
info?
Is
this
being
superseded?
Can
we
should
be
merged?
What
is
index
finalizable
object,
count
should
be
finalizable,
object,
count,
pause,
duration
and
section
drop.
The
m-sec
suffix
are
the
arrays
of
gcf
allocated
each
time.
Should
you
see
generating
generation
info?
Have
an
index
property,
so
that's
more
obvious
rather
than
the
position
in
the
array
is
concurrent
should
be
concurrent.
J
Gc
info
should
be
sealed
pause
time
percentage
should
be
double
pause,
10
percentage
says
it's
based
on
eleventh
time,
but
that
time
since
process
starts
since
last
time
I
called
it
all
since
last
mgc
occurred
and
then
jen
informs
a
better
name,
such
as
generations.
E
A
D
A
O
Okay,
so
there
are
a
few
scenarios
that
involve
the
makeup
default
value:
hunting
for
the
serializer.
So
what
one
thing
is
ignoring
default
values
so
for
reference
types
that
would
be
null
and
for
value
types
that
would
be
default
of
t,
so
we
currently
have
api
to
help
us
to
let
us
ignore
now
when
serializing
or
deserializing.
So
the
first
scenario
is
to
add
api
to
allow
us
to
do
the
same
for
value
types.
So
the
second
scenario
for
fiber
priority
is
being
able
to
pass
now
to
custom
converters.
O
So
I
brought
this
up.
I
think
it
was
a
couple
of
weeks
ago,
so
we,
you
know,
we
discussed
the
the
future
I'll
go
right
again
for
people
who
weren't
here
before,
but
the
general
feedback
from
that
one
was
hey.
There's
some
other
scenarios
involving
default
handling,
such
as
populating
property
value
with
some
default
value.
O
If
you
know
the
type
is
the
clr
default
or
the
type
is
missing
so
yeah
we
can
go
over
some
of
that
feedback,
but
I
just
want
to
emphasize
that
these
two
first
two
scenarios
are
the
scenarios
that
take
priority
for
501.
We
can
adjust
the
rest
as
5v
backlog
or
future.
O
So
if
you
have
proposal
okay
here
we
go
so
right
now
we
have
ignored
our
values
and
I'm
proposing
to
add
a
new
boolean
property
on
json
series
options
called
ignore
default
values
which
would
be
applied
to
both
reference
terms
and
value
types.
So
if
I,
as
far
as
I
know,
this
was
discussed
initially
for
these
serializers,
but
I
guess
the
goal
was
to
design
the
minimum
thing.
O
That
would
be
most
useful
for
most
people,
but
we've
gotten
feedback
since
then
that
people
want
to
ignore
default
values
for
serialization
and
serialization,
when
yeah,
both
globally
and
for
property,
so
yeah.
The
proposal
here
is
to
obsolete
ignorant
values
with
the
goal
of
removing
it,
possibly
in
the
next
release
of
dot
net
sticks
or
what
whatever
comes
next
and
then
everybody
should
just
use
ignore
default
values
instead,
so
it
would
be
valid
for
someone
to
set
both
of
these
properties
right
now.
O
Okay,
so
there's
an
open
question
about
what
about
people
who
want
to
ignore,
know,
values
but
include
value
type
defaults.
So
in
this
proposal
we
already
have
a
json
ignore,
with
condition
lever
that
you
can
set
property
to
to
force
inclusion,
regardless
of
what
the
global
option
is.
So
that's
an
option.
We
can
come
back
to
this
some
more
there's
more
discussion
below
that
discusses,
discusses
alternatives.
If
we
deem
that
this
is
images
scenario,
we
want
to
have
a
more
convenient
api
for
okay.
O
So
that's
the
default
value
handling
scenario,
oh
yeah,
so
the
additional
thing
to
do
here
is
we
currently
have
just
an
ignored
condition
when
no
so
I'm
proposing
to
rename
that
to
when
default.
O
So
for
property
you
can.
You
know
if
ignore
default
values
is
false.
Globally,
you
can
force
a
particular
property
to
be
ignored
when
it
is
default.
The
default
value
I
never
would
mean
would
still
mean,
regardless
of
what
the
global
option
is,
don't
serialize
it
I
mean.
Don't
ignore
me
so
all
right,
so
that's
all
for
ignore
default
values.
So
the
next
thing
is,
if
you
can
scroll
down
into
it,
so
option
for
custom
converters
to
undo
now
so
currently,
custom
converters
for
reference
types
cannot
undo.
O
No,
we
don't
pass
no
on
serialization
or
deserialization,
which
means
that
users
are
limited
for
handling
now.
Basically,
there's
no
way
to
specify
another
value,
even
with
the
custom
converter,
which
I
think
is
a
pretty
bad
limitation
and
we've
got
him
some
customer
feedback
saying
that
hey
we
need
to
use
to
handle
now
and
an
example
is
the
cosmos
database.
They
have
a.
O
O
O
Okay,
so
so
yeah,
so
cosmos
needs
to
be
able
to
specify
some
other
type
when
it
is
now,
you
can
look
at
the
example
later
and
what
is
interested
okay,
so
going
down
to
some
epa
surgery.
Examples
scrolling
down
just
a
little
bit,
so
I
just
want
to
get
through
the
whole
picture
before
I
like
take
questions
on
this
question
so
consider
my
class
that
has
three
properties.
O
Yeah,
okay,
three
policies,
so
a
couple
of
value
types
and
one
reference
step,
then
another
one
where
everything
is
initialized
to
some
non-default
value.
So
if
you
have
ignore
default
values
equals
true,
then
you
serialize
this
object.
Then
it
will
be
empty
because
you
specified
to
ignore
default
values
so
and
the
same
thing
with
this
realization.
So
this
time
I'm
just
realizing
the
thing
where
every
member
is
initialized
and
everything
is
set
to
default
values.
O
All
of
those
would
be
ignored
because
you
said
not
to
ignore
default
value
and
by
the
way,
so
far,
all
of
this
is
in
keeping
with
nutrients
of
behavior,
including
ignoring
default
values
for
the
serializations
for
value
types
so
ignoring
default
values
globally,
but
including
some,
so
we
have
just
need
no
condition.
Never!
So,
even
if
you
specified
globally
that
you
want
to
ignore
default
values,
you
can
choose
you.
Can
cherry
pick
some
not
to
ignore.
O
So
in
this
case
you
serialize
my
boob,
because
you
said
never
ignore
this
property,
so
another
example
is
hand
picking
priorities
to
ignore
when
default.
So,
if
actually
so
this
last
one
ignore
value
should
be
false.
We
shouldn't
no
options,
so
that's
a
mistake
in
the
example,
but
you
want
to
say
ignore
this
thing
when
it's.
O
Yeah,
you
know
when
it's
a
default
value,
so
everything
else
gets
serialized,
but
then
this
one
isn't
because
you
said
to
ignore
it
when
it's
default,
so
there's
full
flexibility
with
regards
to
ignoring
or
including
default
values,
so
yeah
yeah.
So
there's
some
cosmos
scenario
example
that
I
referenced
before
I
didn't
inline
it
here,
but
it's
on
it's
it's
pretty
simple,
a
converter
says:
hey,
I
want
to
handle
no
and
then
we
passed
null
in
to
convert.
I
went
to
realize
it
and
serializing.
O
So
if
anybody
wants
some
visual
example,
we
can
scroll
up
and
check
that
out,
but
otherwise
I'll
just
give
the
notes
to
say
so.
The
question
about
the
custom
converters
handling.
No,
so
the
question
was
hey.
We
don't
pass
nodes
to
consequent
converters
when
the
thing
is
missing.
How
would
we
be
able
to
like
account
for
that?
O
And
what
would
the
api
look
like
and
how
would
this
interact
with
when
you
pass
node
to
the
custom
converter,
so
I
designed
so
I
and
like
someone
other
than
jason
cruz,
stephen
and
david
spent
several
a
couple
of
hours
discussing
this
and
summaries
that
there's
proposed
api.
We
can
to
do
and
we
can
add
to
account
for
that,
and
this
feature
will
not
be
impacted
negatively
or
you
know
they
wouldn't
like
it.
O
O
I
mean
I'll,
do
it
for
more
user
feedback
since
nobody's
asking
for
any
of
these
things
at
this
moment,
but
towards
the
end,
I
just
leave
in
summary,
saying:
hey
if
we
have
semantics
to
replace
or
populate
con
stuff
when
stuff
is
a
clr
default
value
of
or.
G
O
Then
we
will
pass
we'll
set
the
value
you
you
specified
and
will
not
pass
that
to
the
converter.
Also,
okay,
so
I'm
going
to
take
any
any
questions
or
if
there's
any
discussion
that
we
want
to
have.
A
O
The
proposal
will
be
for
the
default
to
replace
the
custom
default
to
replace
the
clr
default.
So
if
you
say
ignore
default
values,
it
will
be
that
value
that
would
in
the
replacing,
not
dcr
default.
A
Says
so
ignoring
the
complexity
of
how
someone
would
express
a
default
value
for
a
complex
type,
ignore
default
values
would
mean
if
it's
going
to
produce
the
the
value
that
you've
declared
in
an
attribute
as
the
default,
then
don't
write
it
down.
J
I
have
a
hard
time
with
the
deceleration
behavior,
because
if
I
send
you
a
payload
where
I
said
property
equals
zero,
I
don't
understand
why
you
would
ignore
that
and
then-
because
I
mean
like,
if
I
tell
you
like-
set
this
thing
to
zero
or
set
this
thing
to
now.
If
the
object
happens
to
initialize
itself
to
different
like
non-clr
default
value,
then
well,
how
will
they
ever
do
that
then,
like
it
seems
to
me
that
people
would
like
to
have
the
behavior
on
civilization,
I'm
not
sure
they
always
want
the
behavior
on
visualization.
O
Yeah
I
mean
that's
considered
one
I
mean,
and
I
think
that's
that's
correct
all
right-
that
we
can
just
apply
the
the
default
value
ignoring
to
this
serialization
when
it
says,
would.
A
O
O
J
Well,
I
mean
I
would
say
that
my
my
suspicion
is
people
probably
don't
protest,
because
they
don't
they
don't
initialize
to
non-standard
values
right,
so
they
probably
never
observed
that
behavior
would
be
my
guess,
like
I'm,
because
jeremy
said
right
now
you
can
never
ever
set
my
rule
to
false,
like
I
don't
think
that's
behavior
anybody
wants,
like
that,
seems
very
backwards
to
me
right.
O
A
I
mean
like
maybe
right.
Maybe
the
point
is
you
need
more
granularity
here,
that
it's
ignore
default
values
on
serialize
and
then
now
you
have
ignored
null
values
on
d
serialize
and
ignore
default
values
on
d
serialize
and
that
those
are
maybe
different
things
or
maybe
not
like
it.
J
J
O
M
O
S
A
J
A
Fair
so
like,
if
part
of
the
thing
that
you
want
to
do
here
is
make
ignore
null
values
obsolete.
You
don't
have
to
respect
any
of
the
same
behaviors
and
ignore
default
values.
It's
a
different
setting,
you're
allowed
to
fix
the
mistakes
of
the
past.
J
Yeah,
I
would
say
like
to
me
null
and
and
and
default,
is
kind
of
different,
because
you
can
argue
that
null
almost
always
means
an
absence
of
a
value
right
versus
false
or
or
the
number
zero
are
not
usually
absent.
Of
of
offset
value
right.
So
I
think
it's
also
fair
to
say
if
you
said
something
to
know
the
behavior
of
today.
You
can
probably
defend
more,
but
if
I
tell
you,
you
set
this
rule
to
false
and
you
drop
it
on
the
floor
and
initialize
it
to
true.
O
Okay,
so
if
we
have
a
new,
an
alternative
is
to
have
a
new,
ignore
value
default
property
and
not
obsolete
it.
No,
no!
J
J
But
I
guess
my
question
is:
is
that
desirable,
behavior,
or
is
that
just
behavior
that
just
happens
to
work
for
people,
because
I
have
a
hard
time
coming
up
with
examples
where
that
is
actually
the
behavior
that
I
want
so,
like
my
gut
feel.
This
is
just
behavior
that
we
happen
to
have
and
nobody
gets
bitten
by
it,
and
so
it's
okay,
but
if
we
design
this
new
thing
to
cover
default
values,
I
think
like
I,
wouldn't
I
guess
what
I'm
trying
to
say
is
like.
J
P
Like
I
think
the
I
think
the
issue
with
json
is
that
you
have
a
lot
of
serializers
that
just
do
a
dump,
serialization
and
dump
out
all
the
you
know,
values
whether
it's
zero
or
null,
and
those
are
you
know,
kind
of
the
lack
of
like
you
said
earlier.
They
were
never
set
and
they
represent
a
lack
of
a
value.
M
P
Think
that's
the
main
scenario
for
not
wanting
to
call
the
setter.
You
know
it
makes
more
sense
for
null.
I
think,
but
the
same
issue
happens
for
primitive
types
as
well.
A
I,
like
yeah,
I
I
disagree.
I
mean
I
cannot
understand
a
serializer
that
doesn't
understand,
ignoring
defaults
and
now
it's
expressing
a
bunch
of
defaults,
but
you
have.
I.
J
P
J
P
O
Sure,
okay,
okay,
so
if
the
feeling
is
that
we
shouldn't
be
like
we
shouldn't
ignore
default
values
on
this
realization,.
I
O
That
be
the
behavior
for
the
new
for
the
new
property.
O
S
O
Q
O
Deserialized,
you
know
when
all
is
not
in
presence
in
payload
yeah
and
then.
M
O
A
And
then
then
the
the
new
setting
I
would,
I
would
recommend
it
not
involve
deserialization
in
any
way
shape
or
form.
You
start
doing
null
assignments
to
properties.
But
if
they're
using
a
custom
converter,
then
you
now,
you
still
have
to
defer
to
the
do
they
handle
null
so
that
you
don't
crash
them.
G
O
M
A
M
I
think
steve
did
come
up
with
a
viable
example
of
that,
where
you
have
you
have
somebody
you
have
somebody
who
is
setting
partial
properties,
and
then
you
want
to
merge
it
into
your
existing
object
rather
than
overwrite
everything
in
your
existing
object,
and
I
can
kind
of
see
that.
But
I
don't
know
how
that
other
entity
would
ever
be
able
to
tell
you
hey,
I'm
explicitly
giving
you
zero
as
opposed.
A
Yeah,
if
it's
for
patch
scenarios
like
in
a
patch
scenario,
you
want
everything
that's
expressed
to
be
set
and
like.
I
think
that
it
means
you
need
a
more
complicated
serializer
to
express.
I
didn't
write
this
down
because
I'm
okay
with
the
default
and
that's
fine.
That's
part
of
the
thing
that
you're
trying
to
do
with
the
the
future
attribute
of
this
is
the
default
value
for
this
property.
Don't
write
it
down
if
it's
this,
and
so
I
think,
that's
all
serialization
concern
and
deserialization.
As
always,
this
was
written,
read
it.
J
So
in
that
sense,
patching
to
me
implies
you
have
to
select
what
you
want
to
patch
and
then
you
have
to
set
it
to
whatever
the
value
you
currently
have,
whether
that's
the
default
or
not.
But
otherwise
it's
in
my
opinion
very
weird
to
to
to
say
I
don't
have
to
patch
default
values,
because
you're
patching
a
live
instance
who's
to
say
that
the
wages
is
default.
M
Because
you
could,
you
could
maybe
argue
that
constructing
an
object
if
it
has
set
these
properties
to
non-defaulted
key
values,
is
morally
equivalent
to
taking
an
object
and
then
patching
it.
But
I
I
have
a
feeling
that,
once
we
add
first
class
support
for
that,
a
lot
of
these
scenarios
will
kind
of
fall
out
and
then
we'll
be
able
to
to
reason
about
them
more
clearly.
P
Yeah,
I
think
we
should
probably
just
touch
bases
with
james
quick
too,
to
see
if
he
has
some
scenarios.
I
I
do
know
that
perf
is
is
something
that
comes
up
with
this
as
well,
because
calling
setters
is
possibly
so
if
90
of
your
values
are
defaults,
you
know
a
lot
more
efficient,
of
course,
not
to
call
the
setter.
P
That's
why
I
thought
we
should
reach
out
to
james
just
to
see
if
this
was
a
perf
scenario
for
other
serializers
or
if
there
is
some
merit,
some
other
scenarios
that
we
haven't
thought
about.
A
But
there's
when
we
get
to
the
next
part
of
this,
that's
something
that
someone
can
can
specify
as
a
more
directed
thing
which
we
can
talk
about
in
a
moment
but
from
the
the
the
big
switch
on
the
serializer.
I
yeah.
I
think
that
you
should
say:
that's
only
ignore
default
values
when
serializing.
J
Yeah
and
the
one
thing
that
I
discussed
yesterday
with
lomi,
because
he
basically
asked
me
for
feedback,
is
you
know?
I
don't
know
how
many
of
you
have
used
the
winforms
designer,
but
they
have
a
very
similar
issue
when
you
design
a
button
in
the
ui,
they
don't
want
to
just
blindly
take
the
entire
object
state
and
write
it
into
the
generated
code.
So
what
they
have.
They
have
a
similar
thing.
J
There's
this
component
model
attribute
that
you
can
apply,
and
you
can
say
the
default
value
of
this
property
is
whatever
you
can
express
as
a
literal,
and
then
they
also
have
the
the
convention.
You
can
define
a
method
and
the
method
is
basically
should
serialize
and
then
the
property
name
and
returns
a
bool.
J
So
if
you
have
a
collection
that
has
complicated
state,
you
can
express
that
the
current
state
of
this
collection
is
the
default,
so
don't
seal
as
it,
and
so
this
way,
basically,
when
you
see
all
that's
the
button
into
the
generated
code
thing,
it
only
has
the
thing
that
has
actually
been
modified
by
the
user
right
and
so
in
that
sense,
I
think
thinking
of
this
as
a
civilization
attack
to
me
makes
sense,
because
if
you
seal
us
something
that
that
is
the
video
that
you
should
set,
I
think
it's
the
easiest
way
to
reason
about
it.
A
Right
because
the
the
note
that
I
have
right
now
is,
it
should
be
renamed
to
ignore
default
values
when
serializing,
which
is
long
if
you
invert
the
meaning
and
allow
the
default
to
be
true,
then
serialize
default
values
makes
for
a
much
more
concise
version
of
that
name.
Yeah.
J
But
I
mean
the
thing
with
the
booleans
is
yay.
I
don't
like
booleans,
where
the
property
name
is
already
indication,
because
then,
basically,
you
have
this
double
negation
in
your
head
that
you
have
to
deal
with.
So
in
this
case,
I
think
having
a
default
value
that
is,
non-false
is
better
than
the
alternative.
J
A
Means,
okay
and
emo:
what
are
our
current
rules
on
obsolete?
Are
we
allowed
to
obsolete
this
property?
Yes,.
J
In
general,
like
obsoleting,
members
is
relatively
unproblematic,
because
the
only
callers
get
it
absolutely
in
types
is
more
problematic
because
they
leak
through
signatures
and
inheritance
chains
and
operating
the
type
usually
means
you
get
hundreds
of
warnings.
So
I
think,
if
you
have
a
member,
I
would
not
push
for
putting
a
diagnostic
id
on
that.
That
seems
over
the
top,
because
it's
just
one
member,
you
only
get
it
for
the
call
size,
and
there
should
be
not
that
many
to
begin
with.
Okay.
O
O
Just
to
note
that
this
is
an
already
existing
api,
it's
called
when
all
at
this
moment.
A
Right
because
that's
here
that
you
wanted
to
rename
that
right,
yeah
right
and
so
does
anybody
else
have
anything
for
the
jason
serializer
options
before
we
start
scrolling
down.
P
I
just
want
to
say
that
that
by
obsoleting
that
could
potentially
break
with
some
people
that
want
to
ignore
value
types,
but
there's
a
worker
on
and
that's
applying
the
attribute
everywhere.
Yep
well.
J
Why?
Because
the
problem.
So
this
is
this
just
two
sides
of
the
argument,
but,
generally
speaking,
removing
low
level
apis
is
impactful
when
people
go
forward
and
google
might
get
to
the
new
thing.
I
think
anything
that
actually
writes
data
that
people
are
very
likely
to
persist
somewhere
like,
for
example,
cosmos
when
you
actually
write
documents
into
a
document
db.
J
The
implications
of
changing
your
donation
behavior
are
pretty
bad,
because
then
you
can
basically
can
no
longer
read
or
write
your
state
that
you
have
written
years
ago
right
and
that
one
is
even
harder
to
reason
about
than
just
migrating
from
one
dot
network
version
to
the
other.
So
I
would,
I
would
generally
say
the
benefit
of
us.
Removing
this
is
very
low.
I
would
just
obsolete
it
and
then
hide
it
and
then
move
on
with
life,
because
there's
very
little
that
we
gain
by
removing
that.
J
The
only
thing
we
gain
is
like
you
know,
having
to
explain
to
hundreds
and
thousands
of
customers
what
what
they
have
to
do
to
get
their
own
behavior
back
right,
which
they
wouldn't
be
able
to
read.
A
P
Great,
we
normally
put
the
that
attribute
that
turns
things
off
for
intellisense
when.
J
We
edit
the
browser.
Whenever
I
am,
I
mean
it's
not
the
same
and
we
get
most
of
the
benefit
of
ops,
leaving
it
and
hiding
it
right.
So,
like
we
like,
then
also
going
out
of
your
way
to
actually
physically
remove
the
api.
It
seems
I
mean.
Maybe
we
can
remove
some
lines
of
code
in
our
product,
but
I
don't
think
it
will
make
our
life
significantly
easier.
R
J
K
J
R
So
I
heard
rename
is
the
proposal?
Did
we
rename
it
or
the
condition
is
new
right?
So
previously
we
had
window,
which
meant.
R
Like
process
digitalize
sterilization.
O
Operation,
either
serialize
or
deserialize,
or
both
like
a
flag
to
say
when
to
apply
so
an
enum
flag.
To
say
when
you
want
to
apply
this,
the
default
would
be
one
of
serialization
of
this
realization
or
post.
O
R
A
Right
so
so
we
want
always
when
default,
never
when
default
serialize
only
and
when
default
deserialize
only
or
I
guess
those
serialized
should
be
serialization.
A
I
think
that
ignoring
default
values
on
deserialization
is
odd,
but
if
it
is
something
that
someone
is
explicitly
applying
to
a
property,
then
that
makes
more
sense
to
me
than
a
than
a
global
switch
at
the
at
the
d
serializer
level.
So
I
I
would
be
okay
with
it
there
as
a
as
a
concept,
but
it
makes
this
it
makes
when
default
then
be
ambiguous.
J
A
Right,
so
if
we,
if,
if
there,
if
anyone
thought
that
it
would
ever
be
feasible
that
we
would
want
to
ignore
default
values
on
d
serialize,
then
then
we
would
really
want
this.
That
wind
default
to
be
a
tri-state,
and
I
think
naomi
suggested
that
that
may
mean
that
we
want
this
to
be
flags
of
when
to
ignore
things,
and
so
it
would
be
default
when
serializing
default
when
deserializing
and
then
always
and
never
but
the.
O
A
Right
but
it's
what
does
it's?
Does
wind
default
apply
to
both
serialization
and
deserialization,
because
if
it's
serializing,
if
it's
only
respected
from
the
serializer
because
again
like
what
does
it
mean
jason
ignore
does
jason
ignore
always
if
it's
specific.