►
From YouTube: .NET GitHub API Review
Description
Powered by Restream https://restream.io/
A
A
A
A
B
B
So,
the
last
time
we
talked
about
the
proposal
to
add
new
apis
for
span
and
for
slicing.
We
decided
up.
I
just
lost
oh
okay,
nevermind.
So
last
time
we
decided
that
we
liked
the
idea
in
principle,
but
that
there
were
some
concerns
about
overload
resolution.
Specifically
the
concerns
result
from
the
apis
that
are
at
range,
insert
range
and
remove
range
as
well
as
no.
I
think
that
was
those
were
it
ad
range
insert
range,
remove
range,
and
so
the
problem
is.
B
B
B
So
the
current
way
that
those
apis
are
named
is
add,
range
from
span
reinsert
range
from
span
and
remove
range
from
span,
and
I
believe
the
questions
that
we
need
to
answer
today
are
basically
just
bike,
shedding
the
the
particularly
the
from
span
prefix
or
a
postfix.
It
kind
of
doesn't
work
great
for
remove
range
from
span.
For
example,
are
you
removing
a
rain
that
are
you
removing
the
immutable
array
range
from
the
span,
or
are
you
removing
the
span?
B
A
A
A
Yeah
I
mean,
because
I
don't
know
ad
range
is
such
a
common
name,
that
I
think
people
will
expect
to
add
a
collection
by
just
showing
you
know
looking
for
ad
range
and
if
there's
no
overload,
then
they
will
be
confused
and
the
nice
thing
with
the
suffix
is
that
even
if
you
type
add
range,
you
know
the
other
thing
still
shows
up.
If
it's
a
completely
different
name,
then.
Yes,
if
I
just
look
at
all
the
members
of
a
mutable
array,
I
might
be
able
to
select
the
other
one
by
name.
A
But
then
the
question
is:
is
that
how
people
work?
I
would
expect
most
people
to
just
dot
into
it
and
immediately
start
typing
ad
range,
and
if
that
that
filters,
it
down
to
just
things
that
have
ad
range
in
it,
and
so
the
other
one
would
just
disappear,
and
then
people
would
be
very
confused
or
would
just
conclude
that
yeah,
you
just
can't
do
it
with
this
man
and
then
just
write
a
follow
up
themselves.
That
would
be
my
expectation.
C
B
D
B
Let
me
let
me
cover
the
other
options
that
we
could
do
if
it
were
just
the
array
overload
right.
If
that
was
the
only
thing
that
mattered,
we
could
just
add
an
ad
range
of
an
of
an
array,
and
then
that
would
just
resolve
the
ambiguity,
because
it
would
have
a
most
specific
overload.
The
problem
comes,
the
problem
comes
when
you
have
string,
because
string
is
equally
convertible
to
both
of
these
things
and
you
can't.
B
We
don't
have
generic
specialization
in
c
sharp,
so
you
can't.
We
can't
have
an
immutable
array
of
chars,
specifically
providing
an
ad
range
of
string
that
that
correctly
handles
this
thing.
The
so
the
other
option
we
could
take
is,
we
could
define,
add
range
that
takes
a
span
as
an
extension
method
on
perhaps
the
partial
immutable
array
class,
but.
D
C
B
We
could
just
define
add
range
as
an
extension
method
at
a
range
that
takes
a
span
as
an
extension
method.
The
problem
with
that
is
that
you
know,
if
you
just
pass
an
array
to
this
thing.
That
will
mean
that
the
the
high
enumerable
will
get
chosen,
because
that
is
the
point
of
doing
it
on
an
extension
method
is,
as
an
extension
method
is
to
provide
a
ranking
basically
right.
E
B
A
A
A
B
A
Yeah
like
to
me
the
the
the
bar
isn't
like
it
will
always,
it
will
always
compile
right.
The
bar
is
more
like.
Okay.
If
I
have
this
issue,
how
many
places
in
my
code
base
do
I
have
to
touch
up
and
how
hard
is
the
fix
right
if
it's
one
or
two
places
and
the
fix
is
trivial
and
believe
it's
rare
enough,
then
that's
okay,
if
you
believe
almost
everybody
is
hitting
that,
then
it's
clearly
not
okay,
right,
like
that's
the
right.
That's
why
I'm
saying
to
me
it
kind
of
feels.
A
I
mean
the
array.
One
clearly
right,
I
mean
arrays
happen
all
the
time
strings
with
collections
with
chars
seems
you
know.
Yes,
I've
written
code
like
this,
but
most
of
the
code
was,
you
know,
sample
code
somewhere,
but
like
it's,
not
production
code.
Usually
so
I'm
wondering
how
many
people
will
actually
have
that
issue
in
practice.
B
So
so,
to
make
sure
that
I'm
understanding,
clearly
emo
you're,
suggesting
that
we
do
the
ad
range
just
add
range.
That
takes
a
span
and
then,
additionally,
add
add,
ranges
that
take
in
an
array
so
that
we
resolve
the
common
ambiguity
and
say
that
the
string
ambiguity
or
any
other
ambiguity
that
results
from
a
user-defined
type
where
they,
where
they
have
both
a
string
where
that,
where
they
convert
both
to
enumerable
and
read-only
span,
is
that's
as
an
acceptable
break.
Is
what
I'm
hearing.
A
That
is
my
suggestion,
because
I
can't
think
of
another
case
where
you
commonly
have
a
conversion.
I
mean
it
would
it
would
have
to
be
logically
a
collection,
type
right,
and
so
the
vast
majority
of
them
are
provided
by
us
right.
So
we
don't
really
have
collections
today
that
implicitly
convert
to
read-only
span.
A
The
only
thing
we
really
have
is
string
so
like
that's,
why
I'm
wondering
how
many
places
you
can
actually
be
hit
by-
and
it
seems
like
string-
is
the
only
case
with
a
string
in
arrays,
right
and
and
for
rays.
We
already-
we
often
already
have
overloops
anyway,
and
so
I
feel
like
that
seems
like
the
the
easier
fix
maybe.
A
D
No,
I
think,
that's
it
I'll
I'll
trust,
fred,
that
user-defined
conversions
are
in
the
same
tier
as
interface
conformance.
I
thought
user-defined
was
a
separate
wave
which
would
have
made
this
easier.
I
mean
it
actually
would
make
it
wrong,
because
we'd
want
the
span
one
more
than
the
innumerable
one,
but.
A
G
F
D
D
D
B
B
B
D
B
B
Yeah,
create
the
create,
is
fine
because
we
already
have
those
those
cases
handled
basically
create
already
take
already,
has
an
overload
that
takes
a
single
t
and
that
handles
the
string
case,
and
then
it
already
has
an
overload
that
takes
an
array
and
so
that
handles
the
array
case.
And
technically,
if
you,
you
know
you,
if
you
have
create
of,
and
you
explicitly
specify
char
and
then
you
pass
a
string
that
could
again
be
considered
ambiguous
between
innumerable
and
read-only
span,
but
I
think
that's
even
less
likely
than
calling
ad
range.
D
A
B
B
G
A
A
A
A
B
B
D
C
B
Yeah,
so
that's
what
you're
talking
about
is
the
implicit
slicing
support,
so
that
will
translate
and,
like
you
take
in
a
mutual
array
and
you
you
index
it
with
us
with
a
span
or
with
a
range
I
mean,
and
it
will
slice
that
and
so
we'll
call
slice
and
get
an
immutable
array
back.
But
we
if
we
wanted
to
have
an
as
span
because
we
already
have
an
existing
s-span
on
immutable
array.
But
the
proposal
last
time
was
that
we
have
on
the
other
types
where
we
have
as
span.
C
B
A
B
B
D
B
B
B
D
B
B
E
E
E
B
E
B
E
E
D
D
A
A
H
A
D
A
B
H
A
A
A
A
A
D
H
D
A
F
A
F
K
Yeah,
I
can
go
with
that.
So
basically,
this
comes
after
a
couple
of
requests
from
people
who
would
like
to
see
this
converter
be
unsealed
and
the
reason
for
that
is
they
want
to
use
the
json
converter
attribute
in
conjunction
with
this
converter,
with
custom
constructor
arguments.
So
this
is
a
really
simple
proposal
to
install
this
class
while
sealing
all
the
virtual
methods
that
the
converter
exposes.
K
I
should
have
prepared
an
example,
but
it's
definitely
quoted
in
this
issue
and
in
a
few
other
ones,
but
the
idea
is
that
you
want
to
be
able
to
pass
a
version
of
this
jc
stringenum
converter
into
a
json
converter
attribute,
which
is
applied
to
class
definitions
or
sorry,
member
definitions
with
custom
parameters
in
the
json
naming
policy
or
in
the
allow
integer
values
parameter,
so
so,
basically
extending
modifying
the
the
default
parameters
that
are
being
passed
into
the
converter.
Does
that
make
sense?
L
K
So
there's
actually
been
a
request
for
that,
but
the
my
feeling
was
that
we,
it
would
be
simpler
if
we
unsealed
this
particular
converter,
because
all
other
public
converters
that
we
expose
are
in
fact
unsealed,
and
you
know
it
seems
like
a
pretty
standard
way
to
do.
This
is
to
is
by
extending
extending
this
class.
K
K
L
A
L
K
K
F
D
Because
I
think
I'm
sort
of
with
steve,
if
the
only
scenario
if
we
started
with
something
sealed,
because
we
had
a
reason
to
I'm
not
going
to
ask
what
the
reason
was,
because
I
think
I
know
what
it
is
and
I'm
looking
at
the
guidelines
have
we
started
with
the
class
being
sealed
and
the
only
reason
we're
unsealing.
It
is
because
somebody
wants
to
do
something
with
an
attribute.
Then
it
sounds
like
we
should
just
empower
the
scenario
at
the
attribute
instead
of
at
the
by
unsealing,
the
type.
D
K
Yeah,
so
I
I
mean
my
earlier
assertion
about
this:
being
the
only
unsealed
converter
might
be
either
that
or
I
think
it
might
be,
the
only
public
converter
that
has
a
constructor
that
accepts
arguments
and
as
such,
you
might
want
to
inherit
the
the
converter
factory
to
be
able
to
use
the
attribute.
You
know,
I
think
I
I
think
extending
the
json
converter
attribute
to
also
accept
constructor
arguments
is
a
valid
workaround
but,
like
I
said
that
has
an
element
of
being
type
safe.
I.
K
And
you
know
for
for
what
it's
worth
the
only
real
workaround
we
have
for
this
scenario
at
the
moment
is
either
what
lyomi
proposed.
So
basically,
inheriting
the
json
converter
attribute
itself
and
overriding
some
methods
that
involves
doing
a
bit
of
reflection,
logic
or
the
other
alternative
is
to
wrap
the
the
enum
converter
with
a
custom
converter
factory
of
your
own,
making
that
hardwires
the
defaults.
K
C
A
Question
and
that
one
I
don't
have
a
good
sense
for
but
like
it
seems
still
like
if
everybody
just
derives
the
type
to
just
hard
code,
some
parameters
that
are
common,
then
my
first
question
is:
should
those
be
maybe
built-in
types
or
should
we
just
have
you
know
I
don't
know
a
more
convenient
way
to
construct
it,
or
are
we
just
basically
making
something
that
requires
10
lines
of
code
now,
four
lines
of
code?
What
we
really
want
is
the
one
line
of
code.
K
A
K
A
I
mean
it's
not
terrible,
but
it
does
feel
very
much
boilerplatey
yeah
yep
yeah.
I
don't
have
any
concerns
for
that.
It
just
seems
to
me
like
we
are
just
only
halfway
there,
but
I
mean
if
the
only
thing
we
can
get,
I
mean
if
the
difference
is,
let's
do
nothing
or
let's
get
halfway
there.
I
I
think,
I'm
with
let's
go
halfway.
There.
G
K
Down
yeah,
no
similar
story
as
the
previous
one.
This
is
a
very
minimalistic
change
effectively
we
want
to.
I
want
to
extend
the
json
converter
attribute
so
that
it
can
be
applied
to
interfaces.
Currently,
it's
constrained
to
classes
and
structs
people
have
been
working
around
this
issue
by
inheriting
the
json
converter
attribute
and
changing
the
attribute
usage
for
the
attribute.
Extending
it
for
interfaces
seems
like
a
natural
thing
to
do.
We
already
support
converters
for
interface
types,
including
internally,
so
that's
it
really.
K
K
D
K
K
D
G
K
G
I
And
then
the
idea
is
is
that
when
the
attribute
is
on
a
on
a
type,
it
would
emit
a
panel
one
or
a
pound
two
or
pound.
Three
like
iterative
changes
when
an
edit
is
is
done,
and
then
the
framework
will
be
able
to
load
the
new
type
and
so
that
it
costs
from
a
customer
standpoint.
They
can
make
whatever
edits
they
want
in
their
their
web
pages
or
whatever
in
the
cshtml,
and
it's
about
it
will
emit
the
new
type
won't
run.
D
I
A
I
So
the
hope
is
is
that
we
can
put
this
in
the
in
the
framework
itself
so,
for
example,
in
cshtml,
this
is
like
code
code
generated
by
the
the
framework
itself.
It
will
just
emit
the
attribute,
and
so,
and
so
it
should
be
99
seamless
for
customers,
but
we
want
to
add
the
attribute
so
that
third-party
frameworks
can
use
it
or
use
if
users
or
have
like
a
special
need
in
their
own
code.
To
add
to
to
do
this,
they
can
do
so.
A
I
see
so
the
so
yeah.
If
the
idea
is
that
you
know
normal
human
beings,
you
know
excluding
framework
or
compiler
authors
for
a
second.
They
would
never
have
to
use
the
bracket
syntax,
they
would
just
use
the
the
framework
and
then
the
generated
code,
like
the
you
know,
dot
cs
that's
generated
by
the
compiler
or
the
framework
might
actually
reference
the
attribute,
but
the
user
generally.
Doesn't.
A
If
that's
the
case,
I
think
the
namespace
proposal
makes
sense
to
me,
but
normally
we
don't
use
compiler
services
for
stuff
that
users
are
expected
to
use,
in
which
case
I
would
probably
put
it
in
system
diagnostics,
code
analysis,
because
that's
where
the
other,
you
know,
linker
style
attributes
are
in,
for
example,
but
if
the
idea
is
that
most
of
the
time
users
never
have
to
interface.
With
that
thing,
it's
generally
used
by
tooling.
I
think
it's
fine
to
put
it
in
compliance.
D
I
think
it's
an
overreaching
term
and
especially
if
users
aren't
expected
to
type
it,
we
should
add
like
four
more
particles
to
it,
to
make
it
be
extremely
scenario
specific
and
it
doesn't
matter
because
users
aren't
going
to
type
it.
But
reloadable
seems
like
a
thing
that
somebody
may
have
in
their
own
api
system,
meaning
something
completely
different.
So
we
should
avoid.
D
D
A
A
L
So
what
do
you
think
this
is?
This
is
an
indication
to
the
compiler
to
generate
a
new
version
of
something.
So
you
know
any
of
those
words
I
don't
know
generate
blah
or
regenerate
or
replace
with
new.
I
don't
know
something
along
those
lines,
but
it
it
doesn't
have
to
be
specific
to
edit
and
continue
or
hot
reload.
It's
just.
G
D
A
A
Yeah
I
mean
so,
while
the
name
is
not
super
important
in
terms
of
you
know,
because
users
don't
have
to
apply
it,
they
will
typically
see
it
when
they
decompile
right
and
people
do
decompile
their
own
code
quite
a
bit.
So
we
should
at
least
make
sure
that
when
they,
when
they
look
at
it,
that
it
you
know,
at
least
when
you
read
it,
you
kind
of
get
an
idea
what
it
does.
I
A
I
mean,
I
think
the
namespace
is
fine,
given
the
way
you
described
that
it's
being
used.
I
think
I
mean
if
the
like.
If,
if
people
commonly
have
to
add
a
using
to
it,
then
I
would
not
put
it
in
compiler
services,
because
the
namespace
is
pretty
large
and
the
vast
majority
of
stuff
in
the
namespace
is
like
for
either
super
fringe
scenarios
or,
like
you
know,
effectively
for
the
compiler
right
so
like
we
generally
don't
put
stuff
in
there
that
we
expect
people
to
actually
manually
reference.
A
But
if
it's
almost
always
done
by
some
sort
of
co-generation
framework,
you
know
like
a
you
know,
I
don't
know
winforms
or
asp.net
or
something
it's
totally
fine
and
I
think
yeah,
if
in
any
decent
decompiler,
when
you,
you
know,
you
know
basically
open
it
up
in
the
view
like
when
you
hover
over
it.
It
shows
you
what
namespace
it's
from
so
like.
If
people
see
system
runtime,
compiler
service,
they
assume
plumbing,
which
is
probably
the
right
conclusion
here
anyway,
and
then
it
just
becomes
like
okay.
What
does
this
actually
actually
mean?
A
G
D
D
D
D
It's
the
thing
I
commonly
reference
for
functionality
that
never
got
ui
to
expose
it.
That
has
a
reg
key,
that
no
one
ever
thought
was
gonna
get
used.
But
now
it's
a
documented
reg
key
because
css
or
whatever
they
were
called
at
the
time,
had
to
tell
had
to
tell
a
customer
change.
The
setting
and
it'll
fix
your
problem.
A
D
A
C
Okay,
so
this
issue
talks
about
supporting
property
origin
when
serializing
json
data.
Today
the
serializer
uses
reflection,
rather
when
retrieving
the
list
of
properties
and
fields
on
an
object
in
order
to
write
it,
and
we
write
that
data
in
the
order
which
is
from
our
reflection
call.
So
we
go
from
the
like
declared
type
itself
and
then
walk
up
the
base
classes
up
up
until
the
top.
C
So
from
most
arrived
to
to
this,
and
for
various
reasons,
customers
need
the
adjacent
to
be
written
in
a
specific
order,
whether
you
know
the
consumer
of
the
json
requires,
you
know
specific
options
like
id
first
or
you
know
whatever
scenarios.
So
in
the
lots
of
scenarios
where
my
wanted,
you
seem
to
be
like
a
deterministic
order.
C
If
there
are
ties,
if
they
are
ties,
then
we
use
the
reflection
order
where
we
would
see
stuff
on
the
derived
class.
First,
the
text
just
means
duplicate,
say:
two
properties
have
the
same
order
say
you
might
have
that
if
you
derive
from
some
base
class
and
then
you
inadvertently
use
the
same
order
as
like
some
other
property
on
the
base
class.
C
So
no
addition
you
can
specify
in
marks,
or
that
I
mean
we
won't
publicly
like
document
that
or
encourage
users
to
to
do
it.
I
just
we
just
don't
really
see
any
value
in
like
doing
all
sorts
of
validation
on
like
you
know,
so
that's
pretty
much
the
other
and
I
mean
proposal
in
a
nutshell.
Some
example
here
of
how
to
be
used-
and
you
know,
there's
precedence.
You
need
to
solve
the
json
and
other
serializers
for
this
same
feature,
and
you
know
supposed
to
be
pretty
usable.
A
I
mean
one
question
I
have
is
like,
if
I
assume
people
care
more
about
what
comes
first
rather
than
what
comes
later
right.
So
I
would
assume
that
you
know
city,
for
example,
you
kind
of
don't
want
in
between
id
and
first
name
right,
you
kind
of
because
you
basically
said
for
city.
I
don't
care
so
you,
so
you
didn't
put
an
attribute
on
it
at
all,
so
it
seems
almost
like
the
sentinel
value
should
be
in
max
value
and
then
among
those
that
you
also
don't
care
you
just
you
know,
alphabetically
sort
them.
A
C
D
A
A
Behavior
and
now
you're
basically
saying
well,
you
can
also
specify
a
value
lower
than
in
max
value,
in
which
case
you
know.
Among
those
you
know,
you
control
the
sort
order,
but
that
seems
more
like
what
people
probably
want
like.
I
would.
I
would
guess,
if
you
have
something
like
an
azure,
you
know
sdk
kind
of
thing
where
you
have
like
5
000
properties,
you're
like
okay,
the
20
things
people
care
about.
Is
you
put
them
first
and
then
you
sort
order
them
and
then
the
rest,
you
just
don't
care.
Alphabetically
sorting
is
okay,
yeah.
D
I
mean
another
option
because
I
can
think
of
a
few
cases
where
you're
like
look.
I
don't
I
don't
care,
but
I
want
the
array
to
be
last
so
that
all
the
simple
properties
got
read.
First,
you
don't
have
a
way
to
force.
Something
to
be
last
is
that
maybe
json
property
order
can
also
be
applied
to
a
type,
and
that
says
what
the
unspecified
value
value
is.
C
A
A
D
C
It
does
have
this
feature.
I
honestly,
I
haven't
verified
that
we
are
like
whether
we
are
equivalent
in
terms
of
the
strategies
we're
discussing
here.
Something
I'd
want
to
verify
afterward,
but
so
far
the
discussions
are
making
sense
to
me,
but
they-
and
they
have
this
feature
in
the
same
like
the
same
order-
property
the
same
json
property
attributes,
just
you
know
how
they
resolve.
I
mean
ties
are
also
treated
the
same,
but
some
of
the
stuff
we're
discussing,
I'm
not
sure
whether
they
have
the
same
behavior
there
as
well.
C
A
Surgery
like
frederick
in
chat,
was
suggesting
that
default
videos
use
short
max
value
because
65
000
members
is
enough
for
everyone,
but
that
seems
not
unreasonable,
because
I
mean
it's
at
least
the
number
that
you
can
reference
right.
I
I
don't
like
four
billion
as
a
number,
because
it
seems
kind
of
extremely
arbitrary,
but
like
yeah.
E
C
A
D
A
Somebody
just
said:
65
000
members
is
not
completely
unreasonable.
I
think
that's
a
that's
something
that
should
be
on
record.
No,
I
mean
yes,
I
mean,
like
we
see
things
like
this.
I
mean
we
say
just
yesterday.
I
saw
somebody
posting
an
enterprise
example
of
an
ioc
usage
where
the
constructor
took
like
60
60
interfaces
or
something
and
then
you
have
to
declare
60
fields
and
then
60
assignments
and
people
said
that
you
know
c
sharp
needs
to
have
a
shorter
syntax
for
that
and
most
people
said
like
well.
A
Maybe
you
should
not
take
that
many
interfaces
in
the
first
place,
but
yeah
I
mean
I
mean
the
problem
in
practice-
is
that
nobody
writes
code
like
this
right
once
you
go
above
you
know
a
hundred
or
a
thousand
like
it's
generated
code
right
and
and
when
you
talk
about
generated
code,
then
yeah
like
the
sky,
really
is
the
limit
right
and
whether
you
do
ten
thousand
or
a
hundred
thousand.
It's
no
longer
really
a
a
problem
right.
A
D
D
D
D
Right
if
first
name
and
last
name
on
this
type,
both
said
json
property
order
two
then
it
should
squiggle
that
and
say
you
seem
to
be
wanting
to
control
your
order,
but
you've
left
it
ambiguous
and
then
it
should
also
check
the
type
hierarchy.
As
you
know,
as
much
as
it
can
to
say,
hey
your
base
class,
you
started
at
six.
Your
base
class
now
has
gone
up
to
eight
you're
you're
mixing
with
your
base
class.
Maybe
you
didn't
mean
two,
so
certainly
not
an
error,
because
the
runtime
is
going
to
handle
it.
C
A
A
It
seems
desirable
that
if
I
have
that
that
I
can
create
a
total
order
across
my
fields,
so
you
don't
basically
just
sort
by
which
type
introduce
them
and
then
by
order,
but
you
basically
allow
me
to
say
yeah.
I
know
that
the
base
type
has
you
know.
The
sword
range
is
10
20,
30
40
and
on
the
derived
type
I
can
insert
something
in
between
right.
Otherwise
you
have
this
problem
very
well.
A
D
Right
well,
he
he
described
the
most
common
case
that
he
expected
for
two
things:
having
the
same
value
in
creating
a
tie
was
that
one
came
from
the
base
class,
so
I
think
that
they
are
all
sorting
together
and
not
sorting
by
type
yeah.
That's
basically,
and
if
you
want,
if
you
are
designing
a
base
class
to
be
inserted
I'll,
you
know
basic,
then
you'll
follow
basics
rules
and
increment
by
10..
D
A
D
G
D
A
G
A
D
D
A
A
E
To
be
fair,
this
isn't
wrong
and
if
we're
saying
that
this
is
wrong,
then
there's
other
issues
with
this
type
definition.
This
will
marshall
correctly.
It's
just
that,
it's
being
it's
just
that
on
one
side,
it's
a
short
which
is
less
convenient
for
some
interrupt
code
when
the
corresponding
manage
type
is
unsigned,
but
this
is
by
far
not
the
only
place
where
we're
not
exactly
matching
the
signature.
E
E
L
L
E
A
I
mean
my
concern
is
less
vb.net
because
I
don't
think
these
types
will
be
used,
but
those
languages
it's
more
hard
to
reason
about
code
that
you
know
is
in
existence
for
15
plus
years
right
and
now
now
you
change
the
type,
and
you
know
you
have
all
these
subtle
over
resolution
issues
and
yeah
I
mean.
Would
I
introduce
the
property?
No,
because
realistically
you
can
just
cast
and
it's
about
the
same
lines
of
code
characters
you
have
to
enter,
so
I
would
probably
just
leave
it
as
that
and
call
it
good.
A
D
E
So
the
really
funny
thing
here
is
that
clip
format
is
actually
the
only
one,
that's
actually
an
enum
dw
aspect
and
time
ed.
They
are
pseudo
enums,
in
that
in
native
they're,
represented
as
d
words
and
you're
just
supposed
to
know
which
macros
you're
supposed
to
pass
in,
but
we've
typed
them
as
as
as
enums
in
the
manned
signature.
A
D
K
A
A
F
A
A
You
know
more
hoops
to
do
that,
so
I
think
that
that
api
makes
sense,
but
I
think
to
me
the
the
concerning
aspect
here
is
that
steve
said
we
are
about
removing
support
for
dynamic.
So
if
we
do
that,
then
we
shouldn't
approve
this
api.
Obviously,
so
it
seems
to
me
at
the
very
minimum.
If
that's
what
we
do,
we
should
just
mark
this
issue
as
future
and
leave
it
open
or
if
we
believe
we
will
never
add
dynamic
back,
we
should
just
alright
close
it.
D
D
A
L
I
think
if
I
think
this
was
basically
just
we
had
decided
when
this
this
attribute
originally
came
in.
It
had
a
bunch
of
constructors
and
there
was
a
decision
made
in
the
api
review
to
remove
the
constructors
and
just
have
get
setable
properties
and
in
the
attribute
you
use
name
equals
value.
Syntax
for
citing
things
right
and
eric
is
asking
to
add
back
at
constructors.
J
D
J
D
And
these
all
get
because
from
if
it
wasn't
attributes
this
would
be
a
nonsense.
Ordering
of
the
overload
string
is
always
present,
so
it
would
should
always
be
the
first
parameter,
but
then
it's
the
once
it's
in
the
attribute.
Well,
maybe
the
event
id
should
come
first,
because
otherwise
you're
burying
the
lead
and,
like,
I
think,
that's
the
circle.
We
talked
ourselves
into
and
then
said
screw
it
remove
all
of
them
and
just
because
nothing's
required
everything
has
a
fallback.
J
D
Right
I
mean
we
can
do
it
for
sugar
and
say
that
this
one's
weird
and
and
things
but
like,
I
think,
the
reason
we
removed
them
was
those
things
that
I
brought
up.
I
don't
care
a
whole
lot,
I'm
just
trying
to
make
sure
we
don't
forget
why
we
did
what
we
did
and
then
make
a
different
decision
and
then
remember
why
and
then
come
back
again.
J
D
A
D
D
J
A
Saying
your
mental
model
is,
there's
always
going
to
be
a
message
right,
but
it's
usually
the
longest
argument,
probably
right
so
making
that
last
makes
sense
and
you
just
insert
more
data
in
front
of
it,
which
refines
your
message,
which,
in
that
sense,
yeah
everything
is
a
unique
message.
Group
a
method
group
isn't
necessarily
the
wrong
mental
model.
Here.
J
A
N
N
Oh
sorry,
no,
I
don't
blame
him
it's
a
month
and
a
half
ago,
and
so
the
only
reason
this
got
put
back
up
is
because
pranav
was
asking
it's
really
important
to
add
event
name
to
the
attribute,
because-
and
the
reason
being
is
because
right
now,
the
way
logger
message
works
is.
Is
it
takes
the
method
name
that
you
have
and.
I
N
That
as
the
method
as
the
event
name
and
in
asp.net,
you
never
want
to
change
the
event
name
once
you
ship
it
because
like
people
will
be
querying
based
on
those
event,
names,
it's
like
a
public
thing
and
so
what
he,
what
he
was
requesting
is
to
add
one
more
constructor.
That
also
takes
the
event
name.
So
if
you
now,
if
you
scroll
down
so
this
guy
here
right
there
and
so
my
opinion
on
this-
maybe
I
should
have
put
it
on
there.
N
D
A
A
N
So
my
opinion
on
this
on
this
is:
we
should
leave,
what's
already
been
approved,
approved
and
not
do
this
new
overload
at
all,
because
I
think
I
think
you
can
just
do
comma
event.
Name
equals
blah
in
asp.net
code
and
the
typical
developer
is
perfectly
fine
with
using
the
method
name
as
the
event
name.
A
N
I
mean
go
ahead
in
the
pr,
so
the
where
this
came
up
from
the
first.
The
first
time
was
me
trying
to
use
logging
log,
the
logging
source
generator
in
asp.net
code,
and
I
got
at
least
two
comments
that
we
shouldn't
be
relying
on
the
name
of
the
method
for
the
event
name,
because
somebody
could
just
rename
that
method.
And
now
it's
not
obvious
that
that's
a
breaking
change,
because
it's
just
a
private
internal
method.
N
A
A
I
mean
I'm
kind
of
like
I
don't
know
like
do
people
understand
what
they're
doing
here,
because
I
mean
you're,
fundamentally
defining
a
method
that
that
is
supposed
to
send
data
over
the
wire
right.
So
it's
the
same
way
that
if
I
design
it
json
object
is
being
serialized
yeah
I
mean,
unless
I
specify
a
name,
I
would
assume
it
uses
the
name
of
the
method
right.
That
seems
like
a.
A
A
J
Right,
like
there's
no
reason
to
change
event
names
like
if
you
don't
have
to,
and
I
can
get
that
people
don't
normally
see
changing
like
private
or
internal
method.
Names
is
breaking.
I
think
if
they
get
used
to
using
this
attribute
like
yeah,
but
I
see
how
passing
it
explicitly
makes
that
more
clear.
No,
I
don't
think
it
should
be
an
explicit
argument
if
pranav
wants
to
always
specify
the
event
name
as
a
string
to
make
sure
it's
obvious
that
changing
it
is
breaking.
I
think
we
can
do
event
name
equals.
A
I
mean
my
problem
with
that
is
like
if
so
yeah,
that's
what
I
kind
of
saying
like.
If
you
want
people
to
force
it
in
you
know,
if
the
only
thing
they
do
is
they
say
name
off
and
then
the
name
of
the
method
that
then
it's
not
really
clear
that
that's
better
because
then
they
just
basically
have
the
same
problem.
Now,
it's
just
with
more
syntax
right.
They
still.
N
On
the
pr
on
the
pr
they
said
previously,
when
we
were
using
just
logger.define
method,
somebody
first
tried
doing
name
of,
and
then
they
changed
it
to
hard-coded
strings
right
before
I
even
came
along
right,
and
so
it
was
already
this
well-defined
thing
inside
asp.net
that
when
you
make
logger
messages,
you
use
a
hard-coded
string.
You
don't
use
name
of
you,
don't
use
the
name
of
you
know
the
method,
name
etc.
A
N
J
Okay
and
frankly,
this
is
a
like
library.
Developers
shouldn't
be
changing
event
names
if
they
don't
have
to
because
like
why?
Are
you
moving
cheese?
I
agree
that
it's
not
as
bad
as
like
binary
breaking
changes
and
runtime
code,
typically
because
less
people
tend
to
rely
on
like
exact
event.
Names
event.
Id
would
arguably
be
better
right
if
you're
going
to
like
filter
on
a
specific
message,
type
in
your
listener
or
whatever
or
whatever,
looking
at
the
logs
output,
but
anyway
yeah.
J
A
So
then
I
I
guess
my
question
becomes:
if
we,
if
so,
basically,
what
you're
saying
is,
it
should
be
optional,
because
some
people
hear
some
people
don't
care
and
then
for
the
ones
that
care
it
doesn't
really
matter,
whether
it's
a
constructor
parameter
or
an
optional
property.
You
can
initialize
or
not
right
but
like
it
seems
like
almost
for
buffing
a
spinet.
F
M
J
A
They're
coming
back,
they
must
really
want
it
yeah.
That
was
basically
my
takeaway.
It's
like
okay.
They
really
want
this,
but
okay.
So
then,
basically,
what
I'm
hearing
is.
You
would
reject
this,
but
we
shouldn't
close
this
one,
because
we
can't
right
because
that's
also
tracking
the
other
thing.
So
I
guess.
B
N
J
F
A
N
A
N
A
J
N
The
other
I
don't
the
other
part
that
is
weird
is
like
event.
Id
goes
first
and
then
you
do
log
level
and
message
and
then
event
name
is
last
or
you
know
not
necessarily
last,
but
after
a
vlog
level
and
and
message
because,
like
event,
id
and
event
name
are
kind
of
together
in
a
tuple
right
of
called
event.
Id.
J
N
J
J
A
A
It
is
orthogonal
right,
but
like
I
mean,
maybe
I'm
reading
too
much
into
it
like,
I
think
the
way
I
read
pronunciation
is
like
by
making
it
a
constructor
people
think
about
it,
and
I
guess
my
argument
would
be
well,
that's
probably
not
enough
anyways.
So
if
you
really
care
about
not
messing
this
up,
you
would
have
an
analyzer
and
then
it
wouldn't
matter
whether
you
had
a
constructor
or
not.
If
the
argument
is
purely
from
an
aesthetic
standpoint,
then
yes,
it's
orthogonal.
G
G
A
A
N
A
Yeah,
basically,
you
use
analyzer
author.
You
never
have
to
look
at
it
or
config
the
infrastructure
does
it
for
you.
You
just
raise
it
with
the
default
diagnostic
that
you
have,
which
might
be
hidden
or
you
know
info
or
something
right
and
then,
rather
than
when
it
reports,
it
included
the
editor
config
configuration
to
set
it
to
whatever
it
was
meant
to
be,
which
includes
off
or
a
higher
diagnostic
level.
A
C
A
J
Yep,
the
the
analyzer
asp.net
once
isn't
exactly
that,
though,
and
it's
not
something
I'm
sure
we
could
write
right.
What
we
want
is
to
treat
these
private
like
logger
message.
Names
is
like
public
api
that
we're
not
allowed
to
change
right
and
whether
or
not
we
use
the
event
name
attribute
or
not
like
or
event
name
parameter
or
not
like
we're,
relying
on
code
reviewers
being
like.
Oh,
this
already
had
a
value,
don't
change.
It.
A
Yeah
I
mean
that
I
was
about
to
type
this
in
I
mean,
like
I
said
literal
but
yeah.
I
had
the
same
thought
like
you
would
have
to
special
case
name
off
probably,
but
I
think
the
larger
point
that
stefan
was
making
is
also
true
is
like
you
can't
change
the
signature.
You
can't
change
any
of
the
arguments
that
you
pass
in,
because
well
that's
telemetry,
you're
sending
back
so
yeah.
You
can't
easily
do
that
in
a
analyzer
unless
you
rebuild
what
we
do
with
the
platform
compact
one.
J
A
A
Might
know
you,
I
would
just
mark
the
types
that
are
browsable,
never
or
something,
because
you
don't
want
the
noise
and
intellisense
right.
But
if
you
strongly
feel
these
are
effectively
public
apis
because
you
can't
touch
them
well,
then
model
naming
as
privates
basically
make
sure
that
none
of
our
default
tooling
will
be
able
to
help
you
so
and
if
you
just
invert
that
and
say
screw
they're
public
api,
so
you
don't
get
to
add
or
remove
parameters
from
that
or
we
name
them
or
whatever
right.
J
J
But
you're
right,
basically,
you
want
like
the
public
api
like
shipped
unshipped
kind
of
stuff,
for
this,
so
you're
making
a
conscious
decision.
It's
not
even
that
we
would
never
change
them
like
sometimes
you
do
like.
Sometimes
messages
get
deleted
or
change,
but
we
want
to
be
thoughtful
about
it.
I
mean.