►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
So
good
morning,
good
evening,
good
afternoon,
depending
on
where
you
are,
we
will
start
today
with
looking
at
some
of
the
stuff,
for
I
believe
this
is
also
open.
Telemetry
related
tarik
right.
B
B
Yes,
so
to
give
a
quick
background,
what
we
are
trying
to
do
here
is
we
already
exposed
the
classes
called
activity.
Source
which
is
has
a
method
is
called
the
start
activity,
as
you
see,
is
a
signature
in
front
of
you.
B
So
start
activity
is
just
the
way
that
you
can
create
and
start
a
new
activity
object,
and
this
method
takes
some
parameters,
like
you
know,
activity
kind,
activity,
contacts
and
so
on,
and
if
there
is
any
listener
listening
to
the
activity
creation
events
they
will,
they
will
get
called
back,
I
mean
they
will
be
notified
and
when
it
gets
notified
it
will.
We
will
send
all
this
parameters
that
pass
to
start
the
activity
method
to
the
listener.
B
B
This
tract
is
called
activity
creation
options,
and
this
struct
actually
is
just
revving.
The
parameters
that
we
passed
to
start
activity
and
the
listener
is
free
to
to
look
at
this
all
these
parameters
and,
at
the
end,
decide
if
we
really
need
to
create
the
activity,
object
or
just
don't
create
it.
I
mean
so
notify
aspect
telling,
like
you
know,
yeah,
I'm
interested
to
create
the
activity
or
I
don't
I'm
not
interested
so
and
according
to
decision
of
the
listener,
we
create
the
activity
or
we
don't
create
it.
B
Recently,
we
run
into
a
new
scenarios
open
telemetry,
that
the
listener
watches
in
the
intermediary
is
assembler
is
actually
not
only
want
to
get
the
parameters
that
pass
to
start
activity
to
decide
about
the
activity,
but
also
need
to
add
extra
stuff
to
the
activity.
So,
like
extra
tags
for
to
the
activity
and
in
current
design
I
mean
there
is
no
way
that
they
can
communicate
extra
data
or
extra
stuff
that
we
can
can
pass
it
to
us.
So
when
we
create
activity,
we
add
this
data
to
the
activity
object.
B
A
B
B
Yeah,
so
the
first
part
of
the
proposal
here
is
this:
is
activity
creation
option,
so
it
used
to
be
read
only
so
we
are
changing
that
to
be
not
read
only
and
we
adding
the
first
property
here
is,
is
called
assembling
tags,
which
is.
This
is
a
property
that
it
has
just
getter.
So
we
are
internally
about
like
if
somebody
calls
this
this
property.
B
A
My
only
question
is
when
you
remove
the
read-only
specifier
from
the
type,
what
does
it
actually
mean
for
c-sharp?
It
wasn't
there
the
idea
that
if
you
do
that
you
it
avoids
defensive,
struct
copies,
but
now,
when
you
remove
that
it
will
impact
other
things
as
well,
where
the
compiler
now
may
actually
perform
defensive,
struct,
copies.
B
A
Yeah,
I
was
also
curious
for
like,
when
you
invoke
instance,
methods
for
example,
like
that
the
compiler
doesn't
know
that
the
instance
method
doesn't
mutate,
the
struct
right,
so
it
isn't
there
often
a
defensive
copy
being
made.
So
even
if
you
pass
the
struct
itself
as
soon
as
you
invoke
any
sort
of
methods
on
the
thing
I
mean,
if
it's
coming
literally.
A
A
A
E
So
the
the
language
itself
doesn't
consider
it
a
breaking
change.
Last
time
I
talked
to
jared,
it
is
a
behavior.
It
is
a
potential
behavioral
change.
However,
in
that,
if
you
have
an
assembly
that
was
compiled
against
a
version,
a
ref
assembly
that
had
the
read-only
specifier
and
then
you
you
change,
you
remove
the
read-only
specifier,
and
then
you
re-run,
you
can
potentially
see
mutations
where
you
wouldn't
have
previously.
A
To
preview
change
gotcha,
so
we
haven't
yeah,
I
mean
that
was
my
other
question,
because
you
suggested
to
remove
some
things
from
the
type
as
well,
but
yeah
I
mean,
I
guess
from
my
point
of
view
like,
even
if
you
haven't
shipped
the
type
it's
just
a
question
of
like
okay.
We
previously
we
had
it,
we
only
know
we
don't
have
it.
A
I
don't
yeah,
regardless
of
the
breaking
change,
I'm
just
curious
what
that
actually
means
in
terms
of
per
for
the
other
existing
properties
and
methods
on
it,
I
mean
the
reason
you're
doing.
It
is
basically
because
you
want
something
text
to
be
lazy
right.
B
A
B
E
A
I
mean
in
general,
we
don't
want
mutable
structs
right
so,
like
the
the
thing
is
in
principle,
all
strikes
should
be
read
only
because
mutable
structs
are
generally
speaking,
a
bug
farm.
If
things
are
immediate,
things
are
mutated
for
lazy
initialization,
as
tanner
said,
that
is
by
and
large
unobservable
to
the.
A
If
you
do
it
correctly
for
the
consumer,
so
it
shouldn't
matter
that
you
mutate
the
struct,
in
which
case
you
probably
get
away
with
lying
with
the
you
know,
unsafe
methods
that
we
have,
but
if
you
suggest
to
add
other
things
that
are
actually
mutable,
I
would
generally
not
be
super
keen
on
doing
that,
because
that
usually
creates
problems.
We
have
done
it
in
the
past
for
certain
things
like
video
task
for
a
certain
availa
task
value,
tuple
right
where
it
was
just
cheaper
to
do
fields,
in
which
case
you
just
it's
hard
to.
A
E
Which
is,
if
you're,
only
doing
lazy
initialization,
that's
likely
better
anyways,
just
from
the
perspective
of
if
someone
does
pass
it
via
in
and
then
call
the
getter
they're
going
to
get
a
hidden
copy
because
they
think,
because
it
thinks
it's
truck's,
mutable
and
because
you're
doing
normal
initialization,
which
means
that
the
get
method
won't
be
marked
read-only
itself,
because
there
are
also
partially
immutable
structs.
In
which
case
you
can
mark
individual
methods
as
read-only.
A
I
mean,
I
would
say
I
would
probably
leave
the
read-only
modifier
on
it
and
just
lie.
If
the
only
reason
is
you
do
it
for
this
initialization
and
then,
if
you're
growing
that
set,
then
I
think,
if
there's
more
things,
we
can
talk
about
whether
that's
a
good
idea
and
if
we
believe
then
we
just
can
later
on
remove
the
read-only
modifier.
Still
like
I
mean.
B
E
So
if
you
do
that,
you
have
to
use
unsafe
code
or
the
system
runtime
compiler
services,
unsafe
class,
to
write
the
backing
field
without
the
c-sharp
compiler,
seeing
as
an
assignment,
it
is
completely
valid
to
do
so.
Provided
you're
doing
it
within
a
the
standard.
Lazy
initialization
pattern
in
that,
if
it's
not,
if
it's
null
effectively
or
undefined,
you
set
the
value
because
then
it's
functionally
read-only
that
is
no
observer,
will
ever
see
the
uninitialized
value.
B
Okay,
so
now,
do
you
see
any
concern
to
have
the
structure
read.
D
E
E
G
I
had
an
additional
question
about
this
program.
Are
we
sure
that
tags
is
the
only
thing
that
we
would
want
to
add
to
activity
like?
Are
we
gonna
put
more
activity
members
here
in
the
future,
it's
possible
to
add
more?
Yes,
okay,
so
did
we
consider
a
callback
that
would
say
hey
if
you
want
to
modify
newly
created
activity
here?
G
It
is
instead
of
copying
these
members
to
activity
creation
options,
so
sampler
would
be
called
twice
wants
to
know
if
it
wants
the
activity
and
the
second
time
for
it
to
populate
the
activity
with
the
things
it
wants
to
put
there,
because
I
I
don't
want
to
end
up
in
the
place
where
we
have
two
things
that
are
basically
activity
and
one
of
them
is
structs
and
like
this.
B
G
B
G
G
D
G
D
G
A
And
non-builders
always
have
this
weird
thing
where
they
duplicate
each
other
right,
which
is
unfortunate.
But
if
you
get
away
with
a
callback
because
it's
rare
to
modify
it,
it's
probably
less
complexity
right
because,
basically
every
basically
at
that
point
anything
that
you
could
change
an
activity
is
not
a
fair
game.
D
Yeah,
I
well,
I
mean
while
we're
while
we're
discussing
alternatives.
I
mean
the
other,
the
other
thing
that
it's
a
little
a
little
sleazy
but
effectively
if
you
stored
whatever
you
wanted
to
store
it
in
a
thread
local
you.
You
know
that
the
next
start,
callback
from
this
listener
is
gonna,
be
the
activity
that
was
just
created.
D
So
that's
a
that's
a
sleazy
way.
You
could
achieve
the
same
thing
without
even
storing
a
delegate.
I
mean
the
first
thing
that
comes
to
mind
when
I
think
of
the
delegate
approach
is
now.
D
Of
course,
you
do
need
some
sort
of
setter
on
this
creation
options
or
you
need
to
change
the
signature
of
the
change,
the
signature
of
the
sample
method
to
return
the
delegate
and
then
the
enumeration
that
it's
returning
right
now
needs
to
be
somewhere
else,
or
maybe
you
have
a
structure
where
you're
returning
a
delegate
and
a
enumeration,
it's
it
would
fiddle.
With
this
thing
a
bit.
G
G
Let's
get
back
to
a
use
case
that
open
telemetry
has:
what
are
we
solving
like
by
adding
this
a
bit?
What
are
we,
what
are
we
trying
to
support.
F
Scenario,
yeah.
I
think
it
would
be
mostly
useful
for
attaching
the
sampling
weightage
to
the
individual
item.
If
the
sampler
wants
to.
F
So
only
the
sampler
knows
what
what
is
its
current
percentage
of
things
being
stumbled
in,
so
it
has
to
attach
that
to
the
activity
itself,
so
that
at
some
other
place
we
know
this
activity
is
not
just
one.
It's
somewhat
representing
more
than
that.
So
this
is
just
a
use
case.
G
Okay,
thank
you.
Does
the
spec
say
that
activity
is
able
sorry,
the
sampler
is
able
to
modify
more
things
than
just
tags.
F
No
just
text,
because
this
is
only
for
deciding
whether
the
activity
itself
should
be
created.
If,
if
one
wants
to
enrich
the
activity
further,
we
have
more
callbacks
like
unstarted
and
unended,
where
we
can
do
more
things.
But
this
is
like
very
specific.
This
decides
whether
the
activity
itself
should
be
created
or
not,
and
in
open
telemetry.
We
use
it
to
plug
in
our
sample
logic
and
like
there
is
a
specific
requirement
that
sampler
can
attach
things
to
the
tags
and
that
tags
should
be
part
of
the
activity
should
it
be
created.
G
G
The
other
option
is
returning
not
just
a
minimum
value
from
the
sampler,
but
like
a
structure
that
contains
innum
value
and
other
things,
but
yeah,
I
think
it
seems
like
having
a
second
callback,
doesn't
actually
solve
the
problem
at
hand.
G
B
D
D
Sure
I
I
mean,
certainly
it
has
some
cost,
but
I
would
think
it's
a
pretty
small
one.
You
know
like
initialize
another
field
or
another
two
fields
to
null
before
passing,
because
I
mean
we're
passing
the
struct
by
reference
so
that
the
passion
be
any
more
expensive
and
if
none
of
the
code
actually
uses
those
fields,
then
there's
no
cost
incurred.
Having
them
sit
there
and
stay
null.
D
D
D
B
B
So
previously
we
have
also
exposed
a
property
on
the
activity
listener
itself.
It's
called
autogenerate
root
context,
stress
id,
I'm
not
sure.
If
you
remember
this
in
previous
reviews
and
this
property
was
intentionally,
I
mean
like
trying
to
to
have
the
listener
to
a
way
to
tell
us
to
auto
generate
this
id.
B
D
B
D
G
G
D
G
D
Yeah,
so
the
parent
context
is
still
it's
still
default.
I
mean
it's
a
struct,
but
the
parent
there
is
no
parent,
so
the
parent
context
is
default.
This
is
just
saying
this
is
the
proposed
trace
id
for
the
new
activity
you're
creating
which
has
no
parent.
Should
we.
G
B
D
G
D
D
B
What
seems
like
me
too?
Okay,
so
let's
go
so
the
rest
of
of
the
changes
here
is
just
renaming
some
methods
and
renewing
some
stuff.
I
mean
because,
like
the
naming
also,
we
got
a
feedback
from
the
open
telemetry
community
about
the
naming
and
it's
kind
of
like
trying
to
use
the
right
terms
now
more
than
what
we
had,
because
what
we
had
is
it's
a
little
bit
confusing
for
them.
B
So
basically,
if
you
look,
if
you
look
at
at
this,
so
if
you
look
at
the
delegate
who's
returning
activity
data
request,
so
we
renamed
this
enum
activity.
Data
request
to
called
activity
sampling
results
instead
and
we
have
renamed
the
name
of
the
delegate
itself
from
get
request
data
to
sample
activity.
B
D
B
Okay,
yeah,
so
I
think
that's
all
we
we
have.
I
mean
if
there
is
any
more
feedback
about
that.
B
A
D
A
D
A
B
A
A
B
Yes,
I
think
so
with
yeah
you
removed
yeah.
This
looks
good
too.
C
All
right,
so
our
current
headers
collections
for
http
client
they
perform
validation
when
you
enumerate
them.
C
Basically
that
means
that
if
we
get
a
response
back
from
a
server-
and
it
has
a
header
in
it-
that
is
a
standard
rfc
defined
header,
but
it
is
unparsable
for
whatever
reason
we
essentially
hide
it
from
the
user.
Just
pretend
it
isn't
there,
but
our
reverse
proxy
needs
to
be
able
to
forward
headers,
as
is
without
getting
any
sort
of
hiding.
C
I
A
I
Worth
calling
out
that
an
alternative
that
we
considered
is
simply
making
the
existing
enumerator
return,
the
the
header
values
that
we
considered
invalid,
but
that
we
had
some
pushback
from
security
folks
that
that
would
be
certainly
be
a
breaking
change
and
that
we
would
change
the
handling
of
those
kinds
of
properties.
I
It's,
I
think
it's
more
in
line
with
what
users
expect,
in
the
sense
that
you
know
like
I've.
I've
seen
several
issues
filed
where
users
were
very
cons,
confused
by
the
fact
that
when
you
enumerate
the
headers,
you
don't
actually
get
all
the
headers.
You
only
get
the
headers
that
we
decided
were
valid,
but
the
security
folks
were
concerned
about
the
impact
of
changing
this
and
the
security
impact
of
changing
this.
A
C
Yeah
exactly-
and
I
think
the
original
design
was
probably
for
consistency.
We
have
a
number
of
strongly
typed
properties
and
it
would
be
strange
if
the
strongly
typed
one
was
null
because
it
could
not
be
parsed,
and
yet
there
was
a
string
value
in
this
collection,
I'm
assuming
that
was
the
original
intent.
C
C
Yeah,
I
mean-
and
it
looks
like
there's
an
api
missing
of
this-
the
header
string
values,
that
is,
that
needs
to
be
an
innumerable
of
string.
C
That
is
a
good
question.
I
I
would
guess
that
it
was
simply
to
make
it
so
the
implementation
was
slightly
simpler.
I
I
probably
wouldn't
wouldn't
want
that
here.
It's
kind
of
weird
looking.
A
I
mean:
is
this
something
where
we
highly
care
about
perth?
I
mean
we
probably
don't
want
it
like
if
it's
super
inefficient
right
but,
like
I
mean
basically
naively
what
I
would
think
is
instead
of
doing
a
property,
you
would
have
a
method
that
says
get
non-validated
headers
and
it
returns
an
idiomable
of
key
value.
Pair
of
string
commas,
header
string,
values.
C
Yeah,
so
perf
is
not
the
primary
concern,
but
it
is
a
concern
here.
We've
had
feedback
from
grpc
and
yarp
that
enumerating
headers
is
a
little
allocatey,
and
this
is
one
way
for
us
to
just
slightly
reduce
the
allocations.
A
Basically,
my
understanding
is
what
corey
just
said
is
that
when
you
enumerate
headers
today,
because
it
goes
to
the
whole
header
collection
stuff,
it's
it's
very
allocated
right.
But
if
that
is
the
reason,
then
I
would
not
push
people
instead
of
doing
this
towards
the
non-validated
property,
because
now
they
will
see
more
properties
than
what
they
have
seen
in
the
other
one
right.
So
then
I
would
have
two
properties.
One
is
basically
validated
headers,
which
returns
non-validated,
enumerator
or
probably
also
within
the
numerator.
A
C
Yeah
yeah,
sorry,
if
like
if
they
give
the
wrong
impression
here.
This
is
not
something
that
we
would
say:
hey
you
want
perf,
go
use
this
right.
It's
it's
more,
that
the
people
who
need
this
also
need
perf.
C
A
A
I
So
we
should
have
a
struct
non-valid
enumerable
that
implements
I
interval
of
key
value
pair
of
string,
comma
header
values
and
its
get
enumerator
returns,
not
the
struct
non-valid
numerator,
non-validated
enumerator
and
yes
in
terms
of
allocation.
If
you
do
4h
over
that,
you
will
not
be
allocating
anyway.
A
So
it's
fine
yeah
yeah,
probably
what
I
would
do
is,
I
would
probably
have
the
the
numerable
would
be
a
nested
type
of
http
headers
and
then
I
would
have
the
numerator
just
be
a
nested
type,
another
non-validated
one
and
just
call
it
the
numerator
right.
Similarly,
what
we
do
with
list
of
t
right
list
of
t
just
says
one
top
level
type
enumerate
or
right
and
that's
the
pattern
we
usually
have
and
and
so
basically
you
have
two
nested
types
rather
than
yeah.
A
A
Okay,
what
is
what
does
the
headers
return
today?
Doesn't
also
have
some
sort
of
representation
for
the
comma
separated
headers.
I
I
I
see,
which
is
why
the
so
the
the
idea
here
is
that
the
header
string
values
it's
very
common.
Most
headers
have
a
single
value
right
right.
Some
have
multiple,
but
the
by
far
the
common
case
is
single
string
value,
and
so
the
header
string
value
is
struct,
which
is
not
defined
here,
and
I
wish
we
should.
A
A
Yeah
they
have,
I
mean
I
I
think
they
have
some
type
that
is,
I
believe,
is
struck
over
the
values
themselves.
I
don't
think
they
generally
represent
everything,
as
I
knew
rule
of
string,
comma
string,
sort
of
animal
of
string
for
the
for
the
for
the
header
values.
They
have
a
type
already
for
this,
but.
I
We
are
speculating
a
little
bit
that
that
the
perf
benefit
of.
I
A
Yeah
I
mean
it
totally
makes
a
lot
of
sense.
I
mean
it's
a
common
pattern.
We
have
seen
in
other
places
where
people
have
the
specialized
collection
for
just
one
item
right,
because
it's
super
common,
so
I
wouldn't
be
shocked
if
that's
actually
true
and
it
yeah
it
to
me
it's
kind
of
just
sad
to
like,
if
you
have
this
duplication,
all
over
the
place
where
we
have
this,
this
concept
encoded
multiple
times
in
different
layers
of
the
stack
right.
A
That
seems
generally
unfortunate,
but
so
we
should
just
make
sure
we
don't
already
have
something
like
that
that
we
could
just
repurpose
for
this,
but
yeah
there
might
be
some
issues
with
just
either
either
it's
in
the
wrong
name
space
or
it's
in
an
assembly
that
is
too
high
level.
I
mean
we
could
probably
solve
that
by
just
type
forwarding
that
guy
down
well.
C
I
I
mean
I
don't
think
this.
The
struct
itself
is
going
to
do
that.
The
structure
itself
is
basically
just
a
placeholder
for
either
a
string
or
an
enumerable
right.
The
interval
that
it
holds
may
is
in
fact
going
to
call
back
into
the
hp
headers
class
a
bunch
of
stuff
to
actually
do
the
enumeration,
but
I
don't
think
I
don't
think
the
struct
itself
is
is
novel
in
any.
I
C
So
the
original
proposal-
or
maybe
there
was
a
variant
of
it-
was
also
instead
of
just
calling
it
a
non-validated
property.
It
would
be
something
like
a
method
get
as
non-validated
or
something
like
that.
C
C
So
say
you
get
a
date
header
from
the
server
and
we
can't
parse
it
as
a
date.
Currently
we
just
throw
the
header
away
and
pretend
it
never
came
to
us.
This
would
show
the
original
header
that
had
a
nonsensical
value.
B
I
I
Then
there
are
three
types
that
are
derived
from
this
hp
request:
headers,
hp
response,
headers
and
hp
content
headers,
which
are
used
on
both
request
and
response,
but
just
to
focus
specifically
on
hp
response
headers
for
a
second,
we
get
an
hp
response
back
from
the
server.
It
has
a
bunch
of
headers.
The
hp
response.
Headers
class
itself
has
a
bunch
of
strongly
typed
fields
on
it
like
server
date,
content
type
via,
and
these
are
all
headers
that
are
defined
as
part
of
the
hdb
spec.
I
And
what
we
do
is
we
try
to
parse
all
of
those
and
give
you
a
strongly
typed
friendly
representation
of
this.
So,
instead
of
giving
you
the
you
know,
canonical
utc
string
for
date,
we
parse
the
date
and
give
you
back
a
friendly
date,
time
value
when
you,
when
you
access
the
date
property
on
hp
response
headers
so
but
there's
also
a
way
instead
of
going
through
those.
I
I
And
we
don't
give
you
any
value
for
that,
as
if
the
header
wasn't
even
present,
if
you
access
those
strongly
type
properties
but
there's
also
a
basically
another
set
of
apis
or
a
another
way
to
access
the
headers
that
is
untyped,
which
is
you
can
basically
enumerate,
there's
also
like
a
tri-git
value
function.
I
But
let's
ignore
that
for
a
second,
you
can
also
enumerate
hp,
headers,
hp,
headers
and
therefore
hp,
request
or
and
response
headers
derives
from
I
innumerable
of
key
value
pair
of
string
comma
I
enumerable
string
and
therefore
you
can
simply
enumerate
that
thing
and
get
all
the
raw
text
values
of
the
headers.
You
will
see
you
know,
here's
the
content
type
and
here's
the
raw
string
for
the
content
type
value.
You
will
see
here's
the
server
and
if
there
are
and
again
hp,
allows
headers
to
have
multiple
values.
I
So
if
there's
a
header
that
has
multiple
values,
we
will
give
you
an
enumerable
that
has
multiple
values
in
it
and
you'll
have
to
go
consume
that,
but
what
we
don't
do
today
is
even
when
you
access
these
properties
when
you
access
the
headers
in
an
untyped
way,
and
we
return
them
to
you
as
just
a
bunch
of
raw
strings.
Even
then,
we
do
not
return
to
you,
the
headers
that
failed
our
validation
when
we
tried
to
parse
them
to
expose
them
as
strongly
tied
as
strongly
typed
properties.
I
This
is
arguably
a
bug.
Well,
no,
that's
overstating
it.
I
think
this
is
a
flaw
in
the
design,
which
is
to
say
that
if
you
are
asking
for
all
the
header
values
in
a
raw
way,
you
probably
want
all
the
the
header
values
in
a
raw
way,
but
we
don't
actually
give
you
that
we
give
you
all
the
header
values
in
a
you
know
all
the
raw
header
values,
except
the
ones
that
we
decided
were
invalid,
because
we
couldn't
parse
them
into
a
strongly
typed
version
of
the
value.
B
I
B
I
Something
like
this,
it
is
all
based
on
the
definition
of
of
what
are
acceptable
values
for
these
headers
in
the
rfc
right,
so
the
rfc
says
every
server.
Every
response
should
include
a
date
header.
The
date
should
be
formatted
in
this
particular
thing.
Utc
time
in
this
format,
blah
blah
blah
right
and
the
vast
majority
of
servers
actually
do
that
for
historical
or
other
stupid
reasons,
because
http
lets
people
do
anything,
you
want
and
people
do
anything
under
the
sun.
I
B
Yes,
but
I'm
just
questioning
about
like
is
this
clear
for
users
I
mean,
while
they
say
why
they
see
like
in
non-validated
or
something
they
will
understand,
that.
I
I
That
say,
I'm
trying
to
enumerate
my
headers
and
I'm
not
getting
one,
even
though
I
do
a
wire
shark
trace-
and
I
see
it's
on
the
wire
and
we
have
to
tell
them
well
your
server's
sending
something
slightly
off
slightly
invalid
right
and
it
you
the
server
may
be
in
some
cases
the
server
is
just
kind
of
slightly
out
of
whack.
In
other
cases,
the
server
is
doing
something
completely
wacky,
but
the
client
the
server
have
already
agreed
to
it,
and
so
it
doesn't
bother
them
and
they're
just
trying
to
get
the
header.
I
From
a
user
point
of
view,
I
think
this
is
incredibly
confusing,
but
it
is
what
it
is
again.
My
preference
would
be
simply
to
say
the
existing
behavior,
where
it's
fine,
that
when
you
access
it
through
strongly
typed
properties
that
we
reject
like
proper
values
that
we
can't
parse,
because
honestly
there's
nothing
else,
we
can
do,
and
it
also
makes
sense
like
you
know,
if
you
give
us
a
value
that
we're
expecting
to
be
a
date
or
that
we're
expecting
to
be
a
content
type.
I
I
But
when
you
access
the
headers
in
a
for
lack
of
a
better
term
weekly
typed
way
when
you
access
them
like
say,
give
me
all
the
headers
and
give
me
all
their
values.
The
fact
that
we
do
not
return
invalid
values
to
me
is
just
a
it's
a
design
flaw
and
if
we
were
doing
this
from
scratch,
I
don't
think
we'd
have
this
non-validated
property
at
all.
I
think
we
would
literally
just
make
the
the
weekly
typed
enumeration
give
you
back
all
the
values.
B
Okay,
so
the
security
folks
are
not
okay,
even
if
we,
if
we
provide
this,
was
like
conflict
switch
or
something
like
this
sorry,
I
didn't.
I
didn't
catch
that
I
mean
like
like
you're
saying
that
today,
while
they
requested
the
list-
and
you
know
the
headers-
we
just
drop
the
invalid
or
non-validated
ones,
while
you're
saying
that
this
is
kind
of
like
not
good
with
design,
I
mean,
but
but
we
this
is
the
way
that
it
works
today
and
and
the
proposal
to
return.
I
mean
to
fix
that.
I
I
think
they'd
probably
be
fine
with
that.
I
think
the
security
concern
is
that
people
who
are
using
the
api
today
and
and
are
not
seeing
non-validated
headers
would
start
seeing
validated
headers
if
we
change
the
behavior
of
that.
If
we
have
it
under
some
sort
of
configuration
option,
I
think
they'd
be
from
a
security
point
of
view.
They'd
be
fine
with
that.
I
don't
think
we
know.
A
I
have
to
say
I'm
skeptical
that
I
would
accept
that
because
it's
the
same
thing
with
things
like
you
know:
gc
dot,
initialize,
an
initial
sorry
create
uninitialized
array
right
where
we
said
we
don't
want
it
to
be
a
boolean
that
you
pass
into
allocate
array,
because
if
you
look
at
the
call
side,
it's
not
obvious
from
the
call
side
that
you
will
get
an
uninitialized
array
right,
because
you
just
call
create
array
and
you're
passing.
A
You
know
true
and
now
that
that
is
security
implications
when
you
pass
and
false-
and
I
think
that
will
be
similar
here
right.
So
if
you,
if
you
have
a
compete,
switch
usually
the
way
we
think
about
about
compat
switches.
Is
you
don't
want
break
people
that
have
updated
or
that
you
know
where
the
app
was
roll
forward
right?
But
then
you
usually
have
a
design
that
says.
If
you
target
the
latest
version
of
the
platform,
then
you
opted
into
the
new
behavior
right.
A
A
We'll
go
ahead
and
turn
yeah,
I
mean
like
it's
just
I
think.
Even
if
we
had
a
compat
switch,
I
think
they
would
still
say
like
look.
If
I
just
review
the
code,
I
want
to
know
what's
happening
there
right
and
unless
the
api
changes
and
somehow
you
state
that
it's
you
get
access
to
non-validated
headers,
a
global
compat
switch
is
not
good
enough.
I
Yeah
I
agree
when
I
was
thinking
more
in
terms
of
like
maybe
you
know
you
could
pass
a
flag
and
when
you
create
the
hp
client,
you
could
pass
a
flag.
That
says
show
me
all
the
headers
or
something
like
that
right.
So
less
global
thing
and
something
more
that
you
opt
into
explicitly
encode.
A
Yeah,
I
think,
if
you
do
it
in
code,
it
might
be
more
viable.
The
problem
there
is
in
asp.net
you
like
the
like
the
obvious
cases
where
you
would
get
to
control
the
which
is
http
client.
Usually
the
code
or
the
the
person
doesn't
write
the
code
that
does
the
newing
up
right
because
you
inject
it
with
the
eye
or
something
right
and
then
there's
always
this
ambient
thing
that
they
provide
for
you
and
there's
factories,
and
you
may
not
be
able
to
do
that.
A
So
I
think
it
is
probably
the
easiest
way
to
say:
let's
have
a
localized
api
on
headers
itself,
because
that's
always
reachable
you
don't
have
to
do
crazy
gymnastics
to
get
them
and
once
you're
standing
on
them.
It
will
be
obvious
that,
well,
if
you
go
through
that
code
path,
you
get
unvalidated
headers.
I
mean
that
seems
it's
unfortunate.
A
A
Yes,
I
guess
that
would
be
my
next
question.
Sorry,
I
think
we've
talked
about
this
header
thing
multiple
times.
One
of
the
things
that
crystal
always
wanted
us
to
do
somehow
was
instead
of
doing
any
sort
of
string
allocations.
You
just
get
access
into
the
headers
directly
right
and
basically
you
get
the
individual
values
and
and
and
keys
as
spans,
but
that
would
be
a
major
undertaking
to
do
that
right
and
in
a
usable
fashion.
So
do.
A
That
what
you're,
adding
now
with
the
header
string,
values
and
the
the
struct
based
enumerator,
is
good
enough.
Or
do
you
think
that
eventually
we
will
find
ourselves
doing
something
like
what
crystal
suggested
and
then
we
have
effectively
three
ways
to
get
access
to
the
headers
right.
We
have
the
strongly
typed
thing.
We
have
the
you
know
or
four.
I
guess
then,
the
the
weakly
typed
one
and
then
we
have
the
weekly
type
non-validated
one,
and
then
we
have
the
you
know
the
span
based
one.
C
I
I
The
the
thing
I
don't
have
a
good
answer
for
is
whether
that
actually
matters
in
practice
or
not.
We
just
don't
have
enough
data
about
yarp
and
the
yarp
scenarios.
It's.
It
seems
like
a
like
an
easy
win
in
the
sense
of
like
we
know
that
most
headers
are
single
valued,
and
so
why
don't?
We
give
people
an
easy
way
to
get
back
a
single,
valued
header
without
allocating
an
enumerable,
but
well.
C
G
I
C
C
Our
exact
fix
here
will
move
the
needle.
You
know.
F
C
A
A
It
would
be
good
to
validate
the
feature
before
we
ship
it,
though,
but
I
mean,
if
somebody
would
tell
me
you
know
it
would
be
nice
to
have
non-allocating
behavior,
and
that
means
special
casing
the
one
value
case
that
seems
totally
reasonable
to
me
and
honestly,
like
even
ignoring
that
case,
just
from
an
api
usability
standpoint,
I
think
header
string
values
is
helpful,
because
if
you
look
at
the
code
already,
you
have
nested
generics
through
the
roof
right
and
if
you
have,
if
you
know,
expand
header
string
values
into
enable
of
string
everywhere
like
now,
you
have
like
three
levels
tested
generics
right,
so
I
think
just
having
having
a
type
in
the
middle
that
is
implementing
inevitable
of
string
already
improves
the
api,
and
that
also
gives
us
a
perf
benefit
then
great,
but
I
suspect
you
will
find
gains.
A
I
C
I
We
have
collections
for
headers
on
request
on
response.
We
actually
allocate
two
because
there's
also
one
for
the
content
on
either
of
those.
If
we,
if,
if
that
overhead
is
significant
enough,
that
we
want
to
try
and
get
rid
of
it.
Well
then
we're
probably
talking
about
an
api.
That's
not
http!.
A
A
H
A
A
And
I
renamed
it
to
non-validated
headers,
because
it
seemed
makes
more
sense.
I
think
the
type
generally
doesn't
make
a
lot
of
difference
for
people,
because
you
will
never
really
use
it
for
anything.
You
will
just
immediately
for
each
overhead,
so
I
think,
having
an
estee
type
makes
sense.
In
my
opinion,.
A
But
that
is
kind
of
also
a
question
for
you:
do
you
ever
envision
adding
more
members
non-validated
headers,
because
if
you
do
then
or
in
general,
like
do
you
expect
people
to
pass
these
guys
around
like
do
you
expect
people
to
write
method,
signatures
that
take
non-validated
headers,
for
example,
because
at
that
point
it
really
shouldn't
be
a
nested
type?
It
should
be
a
top
level
type.
Like
header
string
values.
C
But
well,
we
we
do
have
other
methods
to
basically
use
it
like
a
dictionary.
So
you
can
do
like
get
header
of
string
that
we
might
add
to
this
at
some
later
point
if
someone
would
pass
it
around
rather
than
just
doing,
non-validated
dot
get
header
that
I
don't
know.
A
A
How
about
this
then
I
make
it
top
level
type.
I
call
it
http
headers
non-validated,
so
it
groups
somewhat
nicely
with
the
existing
one
and
then
we
just
have
it
like
that.
Then,
if
you
want
to
add
more
stuff
to
it,
and
people
want
to
write
method
signatures
that
take
them,
it's
doable
and
not
a
complete
wacko
scenario.
C
Yeah,
I
think
it's
fine.
I
would
make
all
of
these
structs
read
only.
A
C
Including
the
the
nested
enumerators
right.
A
C
A
C
Possibly
I
don't
know
if
we've
gone
deep
enough
into
implementing
these
to
know,
if
that's
how
we
would
want
to
implement
them
yet.
A
C
A
I
mean
for
things
that
are
generic
data
holders.
I
would
generally
suggest
make
sure
you
can
construct
them,
because
if
you
want
to
write
tests,
for
example,
it's
just
to
pay
in
the
ass,
if
you
can't
construct
those
things
because
then
you
have
to
basically
provide
your
own
abstraction.
That
does
the
same
thing
that
this
guy
does
and
then
well.
The
prop
optimization
goes
out
the
window,
because
now
I
have
to
replay.
C
I
guess
yeah
yeah,
I
don't
know
if
we
know
enough
about
what
the
constructors
would
look
like
right
now
to
ask
for
an
api
for
them
like
what
you
had
there
is
seems
reasonable
if
that's
how
the
implementation
shook
out,
but
I
just
don't
know:
if
that's
how
it
will.
Let
me
just
instead.
I
C
H
C
C
All
right
for
this
one,
we
did
the
initial
api
review.
Stephen
came
back
basically
saying
he
disagreed
with
some
fundamental
parts
of
it.
So
we're
coming
back
to
kind
of
talk
about
those,
as
well
as
a
few
things
that
we
noticed
just
while
implementing
it.
C
C
Yeah,
so
we
initially
wanted
derived
exception
types.
Like
connection
reset
exception,
stephen,
I
think
I
will
try
to
distill
his
argument
against
that,
for
one
type
you
know
just
type
explosion
is,
is
a
worry
here
like
we
have
quite
a
lot
of
socket
errors
and.
C
C
But
stephen
is
worried
about
us
just
adding
more
and
more
and
more
also
he's
concerned
that
we
would
not
be
able
to
sufficiently
or
generically
distill
socket
errors
in
a
way
that
would
prevent
a
user
from
still
needing
to
use
an
exception
filter
to
kind
of
test
for
multiple
of
these
exceptions
that
they
would
want
to
handle
identically.
C
C
Generic
jeremy
kind
of
came
back
and
filled
us
in
with
the
the
recommendation
that
I
I
guess
came
from
christoph
originally
of
you
know
you
should
create
derived
exception
types,
but
stephen
thinks
that
we
should
kind
of
embrace
exception
filters
for
this,
and
we
should
be
okay
with
that
that
perhaps
the
prior
guidance
was
developed
before
we
had
exception
filters
in
the
language.
A
A
Not
so
much
for
the
handler
itself,
because
once
the
handler
is
reached,
it's
the
same
as
the
normal
catch
handler,
it's
more
for
the
expression
you
put
in
the
filter
right,
because
that
runs
basically
before
the
exception
is
called
logically,
and
so
you
have
some
limitations
of
what
you
can
do,
but
it's
probably
not
a
big
deal
because
for
the
most
part
it
will
be
something
like
well
check
for
this
value.
Right
and
inspecting
you
know,
is
the
exception
of
a
certain
type
or
something
like
that
right.
A
C
Scenario
so
I
mean
the
the
api
as
approved,
did
include
this
error
code
right.
C
With
that,
api
would
already
have
the
option
of
you
know
having
a
an
exception
filter
right.
C
A
If
you
have
these
specialized
types,
can
I
actually
write
code
sufficiently
with
them
right,
because
one
thing
that
I
do
notice
myself
all
the
time
is
that
I
find
I
catch
four
or
five
different
exception
types,
but
the
handler
is
basically
the
same
for
all
of
them
and
there's
not
really
a
convenient
way
of
doing
that
in
c
sharp,
unless
you
write
a
filter,
unless
you
say
catch
exception
and
then
the
filter
is,
is
this
type?
Is
that
type
or
is
that
type
right?
A
So
basically,
his
argument,
I
think,
is:
if
you
push
people
that
direction,
then
why
do
you
care?
What
the
actual
check
is
that
they
have
to
write
right,
because
if
you
compare
this
type
or
you
just
you
know
basically
do
a
switch
on
the
on
the
error
code.
It's
virtually
identical
at
that
point
right,
and
I
think
that
that
I
do
buy
a
little
bit,
because
I
guess
many
people
who
write
networking
code
when
something
doesn't
work.
A
This
just
like
sorry,
I
can't
do
this
right,
and
so
the
error
handling
code
is
probably
uniform
for
a
lot
of
stuff
right
and
then
it's
great
when
you
can
actually
get
these
individual
errors
out
of
it.
But
then,
if
if
one
of
the
common
scenarios
is
just
do
everything
the
same,
and
then
you
write
a
filter
to
do
that,
then
you
actually
make
it
harder
for
people
to
do
that
right,
rather
than
just
catching
one
exception
right.
I
I
Something
went
wrong
right,
the
network
exploded,
and
now
you
can't
talk
to
your
server
anymore
right.
You
don't
really
care
what
the
specific
error
was,
but
there
are
certain
cases
where
you
may,
in
fact
want
to
inspect
the
error
code,
not
just
for
logging
purposes
or
diagnostic
purposes,
but
to
actually
take
action
in
the
in
in
your
code
itself
right,
but
that's
not
the
common
case.
C
Yeah,
I
think
I
think
that
yeah
the
way
we
distilled
the
errors-
I
I
do
believe
we
would
see
users
finding
benefit
from
just
catching
a
concrete
exception,
while
still
leaving
it
open
to
them
if
they
want
to
use
an
exception
filter.
C
But
I
don't
really
feel
strongly
that
we
need
the
the
exceptions
like
I
have
down
below.
I
have
a
comparison
of
the
the
old
usage
and
the
new
usage
and
anyone
writing
sockets
code
today
is
already
familiar
with
using
exception
filters,
because
that's
just
how
you
use
socket
exception,
so
it's
not
really
going
to
be
a
shock
to
anyone
that
they
have
to
use
them
here,
using
a
derived
exception
type.
I
guess
would
just
be
slightly
more
idiomatic
to
how
most
of
the
other
bcl
types
work.
A
Yeah,
I
mean
one
thing
that
is
interesting
in
that
it's
I
mean
I
looked
at
this
code
for
like
for
five
minutes
to
figure
out,
what's
actually
different,
but
like
it's
order
right,
but
I
guess
that's
already
the
case
anyway,
because
they
can
always
dispatch
top
to
bottom
and
the
first
handler
that
wins
is
executed
right.
C
Yeah,
so
I
think
the
networking
team
is
fine,
not
doing
the
derived
exceptions.
We
really
just
wanted
to
bring
it
to
this
team,
to
you
know,
make
sure
that
we
were
okay
with
sort
of
relying
a
little
heavier
on
the
exception
filters
than
most
of
what
the
bcl
does
today.
C
C
C
Yeah
but
at
the
same
time,
jeremy
commented
on
the
issue,
saying
hey
if
you
want
to.
C
If
you
want
to
argue
against
the
drive
types,
that's
fine,
but
we
should
probably
talk
about
it
and
get
again
an
api
review
to
kind
of
make
sure
the
whole
picture
still
fits
rather
than
us
just
choosing
to
not
implemented
a
couple
of
the
apis
that
were
approved.
Yeah,
I
mean,
like
that's.
A
I
mean
I've,
I
think
I've
said
this
in
fxcc
multiple
times,
like
I'm
kind
of
back
and
forth
on
the
error
codes
as
well,
like
I
think
by
and
large
like
for
some
areas.
It
makes
sense
right.
Networking
or
io
often
has
like
this
very
long
tail
of
error
cases
right
and
I
think
it's
reasonable
to
use
to
use
error
codes
there,
because
it
doesn't
explode
as
badly
and
then
the
only
downside
really
is.
Is
that
you
know
it's
not.
I
mean
we
think
of
exception.
Handlers,
sorry
of
exception.
Folders.
A
Is
this
thing
that
basically
everybody
can
use
and
everybody
knows
how
to
use,
but
it's
for
most
people.
It's
still
a
relatively
recent
feature
right
and
there
might
be
some
downside
to
that.
But
at
the
same
time
those
kind
of
people
are
probably
also
better
served
with
just
effectively
the
catch
all
handler
anyway,
because
it's
like
well
networking
didn't
work
exception
to
string
to
the
log
right
and
then
you
move
on
with
live
right.
So
in
that
sense
I
don't
actually
think
it's
bad.
A
H
C
So
I
I
think
it's
fine.
I
think
there
are
cases
where
people
would
could
realistically
catch
the
drive
type
and
have
slightly
cleaner
code
for
it.
But
I
don't
see
it
as
a
huge
improvement
to
to
code
readability
and
it
would
let
us
reduce
the
number
of
types
that
we.
C
C
Yeah,
so
the
next
bullet
point
stephen
called
out
that
all
of
our
existing
exception
constructors
have
the
message
parameter.
First,
so
in
the
new
proposal
we
just
moved
the
message.
First,
we
also
added
a
second
constructor
without
a
message
so
that
users
can
get
the
default
message
for
an
error
code.
I
But
in
cases
where
you
want
to
provide
a
custom
message,
we
provide
another
overload
with
the
string
parameter
first,
which
is
the
common
pattern
for
exception,
constructors,
the
string
first
etc,
and
so
that
it
it
follows
the
common
pattern,
but
also
gives
you
an
easy
way
to
do
it.
We
think
the
common
usage
of
this
is.
A
Yeah
I
mean
I
can
see
both
arguments.
I
mean
they
both
have
pros
and
cons.
I
mean
to
me
the
string
first.
Is
I
don't
care
that
much
so
long?
The
other
thing
you
put
in
front
of
it
isn't
also
a
string
right
because
that's
really
what
people
up
like
the
argument
about
one
of
the
argument:
exceptions
where
the
param
name
and
the
message
got
swapped
right
and
it's
like
everybody,
gets
it
wrong
all
the
time,
because
well
muscle
memory
right
and
code
happens
to
compile
right.
A
But
in
this
case,
if
you
call
the
method
incorrectly
like
you
will
immediately
tell
because
it's
like,
oh
yeah,
sorry.
The
first
argument
is
the
error
code,
not
the
message.
So
in
that
sense
I
don't
think
it's
a
biggie.
I
don't
think.
A
Right
worthwhile
well
the
problem
with
that.
This
is
why
it's
hard
right,
because
we
have
basically
multiple
conflicting
guidances
right.
One
of
them
is
don't
swap
argument
positions
right.
It's
one
guidance
which
you
do
here
right,
because
if
you
go
from
one
to
the
other,
no
error
code
moves
by
one
spot
right.
So
that's
that's.
We
already
said
we
don't
want
to
do
that
either
and
then
the
other
one
is
yeah.
You
know
be
consistent
across
types
right.
So
yeah
pick
your
poison
right,
they're,
both
for
pros
and
cons.
A
A
C
Yeah,
I
don't
know
if
steven
felt
strongly
about
it
or
not.
I
I
certainly
would
prefer
one
constructor.
I
would
prefer
to
go
against
the
convention,
but
yeah
I
wouldn't
mind.
If
we
had
the
two
weird
constructors,
it
wouldn't
be
the
first
time
in
our
networking
apis
that
we
have
that.
A
C
The
the
other
major
change
that
we
have
is
we
had
defined
these
to
have
address
in
use
and
invalid
address
and
during
review.
I
realized
that
none
of
the
apis
throwing
this
have
anything
called
address
on
them.
We
use
endpoint
so
just
a
suggestion
that
we
rename
these
to
endpoint
in
use
and
invalid.
C
A
A
C
I
Yeah,
the
socket
enum
values
actually
start
with
address,
which
is
interesting.
Their
address
family
not
supported
an
address
not
available,
which
are
slightly
different
things,
and
I
don't
think
we
I'm
not
sure
I
don't
know
if
we
want
endpoint,
not
supported
or
point.
A
Yeah
I
mean
that's
my
other
questions
like
it's.
The
only
one
where
you
have
two
two
underlying
causes
mapped
to
the
same
value
like
do
you
think,
that's
confusing.
Maybe
do
you
ever
see
cases
where
people
would
differentiate
them
or
would
you
then
just
say
tough
luck?
You
have
to
check
an
exception
for
a
socket
exception.
Then
you
ask
the
socket
exceptions:
error,
property.
If
you
want
to
know,
I.
C
Yeah,
I
feel
like
this
is
probably
actually
kind
of
rare
error
code.
I
actually
wouldn't
mind
just
getting
rid
of
this
network
error
unless
jeff,
you
think
it's
more
common.
I
No,
I
I
think
it's
I
think
it's
fairly
uncommon,
too
I'd
be
happy
to
just
kill
it.
I
It's
gonna,
be
it's
gonna,
be
like
in
weird
situations
where
you
know,
like
the
you
run,
you're
trying
to
connect
to
an
ipv6
host
but
you're
running
on
a
on
a
box
that
doesn't
have
ipv6,
which
is
extremely
uncommon
and
is,
is
you
know
if
you've
gotten
that
far
and
you're
trying
to
run
it
then
you've
you've,
probably
not
done
your
job?
Well,
you
know
what
I
mean.
So
these
are.
These
are
errors
that
indicate
something
you
badly.
I
And
and
I'm
not
sure
it's
worth
making
them
a
first
class
thing.
A
A
C
What's
the
difference
between
connection
board
and
operation
aborted
connection
aborted
essentially
means
that
some
tcp
issue
happened
like
resending
lost
packets
failed
for
some
reason
and
operation.
Aborted
means
the
user
canceled
the
operation
somehow
either
by
closing
the
socket
or
asking
for
a
individual
op
to
be
cancelled.
I
Yeah
connection
aborted
means
that
the
tcp
stack
decided
something
went
wrong
and
decided
to
kill
the
connection.
Operation
reported
means
the
user
did
something
that
caused
the
operation,
the
connection
to
be
killed
in
in
typical
use.
We
actually
we
often
map.
We
often
will
swallow
operation
aborted
and
convert
it
to
a
operation
cancelled
exception
right.
That
was
awesome
because
that's
the
most
common
case
in
which
we
get
that
sort
of
thing
right,
but
there
are
other
cases
where,
where
we
don't
map
it
to
something
else,
gotcha.
A
I
mean
like
it's
nuanced
right,
I
mean
that's.
Why
having
a
chat
is,
I
think
good.
So
is
there
anything
else
we
should
be
looking
at?
A
J
E
Yeah
that
one
should
be
simple:
the
simplest
is
probably
to
consider
expanding
one
and
expose
the
new
call
convention.
One.
A
E
E
A
little
easier
yeah,
so
so
this
is
basically
we
have
vector
of
t
today
in
the
runtime
itself.
We
are
actually,
if
defining
to
simulate
vector
of
init
and
inuint
in
various
places.
This
is
just
proposing.
We
expand
the
apis
to
officially
support
them
so,
and
this
is
the
exact
set
of
apis,
we
would
need
to
add.
J
E
Names
I
called
that
out
just
below
as
a
potential
consideration.
So
what
we've
done
historically
and
in
the
guidelines
is
that,
rather
than
using
a
language
keyword,
we
explicitly
use
the
the
name
of
the
type
as
exists
in
system,
so
we
use
in
32,
rather
than
in
we
use
in
64
rather
than
long
technically.
The
type
is
in
pointer,
which
is
why
I
used
it
here,
even
though
the
language
keyword
is
in
it.
E
However,
given
that
some
people
have
strong
opinions
of
in
input
or
specifically
being
for
handles
and
pointers
rather
than
inund,
which
is
for
native
integers,
I
think
it
might
be
acceptable
to
allow
and
special
case
the
rule
for
as
vector
capital
in
capital.
I
lower
case
in
t,
but
I
didn't
have
a
strong
preference
on
that.
A
I
mean
that
is
something
we
should
just
basically
decide
what
the
what
the?
What
do
we
call
this?
The
the
long
name
for
the
keyboard
is
basically
right
and
I
think
n
int
works
for
me
with
capital
n
and
I
and
then
same
with
n-u-n-t
right,
similar
to
how
m-32
and
u-n-32
look
like
just
prefix
with
n.
A
Without
the
bitness
yeah
I
mean,
I
guess
there
is
a
difference
in
behavior
right,
because
if
you
call
like
basically
mark
these
members,
as
the
return
type
really
is
vector,
nin
not
vector
in
pdr
right,
because
if
you
type
it
as
variance
your
shot,
you
still
get
then
back
right.
E
Due
to
how
the
runtime
works
and
how
the
language
works,
there
will
be
an
identity
conversion
between
the
two.
They
are
actually
the
same
underlying
type,
and
so
there
isn't
actually
a
big
difference
from
the
perspective
of
these
apis.
Oh.
A
H
E
A
A
J
I'm
I'm
glad
tanner
that
my
stupid
tricks
and
ask
utility
are
the
things
that
that
spawned
this
conversation.
E
J
One
of
the
things
that
we
were
actually
looking
at
internally
for
for
for
a
vector
of
new
intuism,
you
have
an
object
array
and
you
want
to
know
if
any
of
them
are
null
well,
you
can
unsafely
reinterpret,
cast
it
as
a
vector
of
nuance
because
well,
if
it
doesn't
matter
if
the
gc
doesn't
track
the
references,
because
non-null
is
going
to
become
non-null
and
null
will
become
null
so
whatever
so.
A
A
So
I'm
still
looking
at
the
vector
one
right,
so
my
question:
is
you
only
identified
like
six
methods
right
realistically
six
method
groups
where
we
would
add
this
on
the
non-generic
vector
type?
Are
these
really
all
the
ones
or
the
ones
you
excluded.
E
Those
are
the
existing
generic
functions
that
would
be
expanded
to
support
the
new
operations,
there's
potential
for
other
operations,
like
addition
and
stuff,
but
those
were
explicitly
left
out
because
they
aren't
currently
needed
and
they
re
they.
They
aren't
currently
used
anywhere
in
the
run
time,
and
some
of
them
would
automatically
light
up
with.
Oh
sorry,
sorry,
these
are
the
these
are
the
non-generic
versions.
The
generic
the
the
existing
generic
functions
would
automatically
be
expanded.
E
These
are
the
cases
where
the
type
is
explicitly
called
out
somewhere.
So
the
the
existing
vector
vector
of
t
operator
plus,
for
example,
would
naturally
have
to
be
expanded
to
support
this
as
well
as
well,
but.
E
A
E
However,
due
to
the
way
function,
pointers
are
encoded.
You
cannot
use
attributes
on
function,
pointers
the
proposal
to
handle
that
is
to
expose
a
new
calling
convention
type
which
matches
the
general
layout
and
convention
of
the
other
calling
convention
types
and
what
the
c
sharp
compiler
will
support
for
the
function
pointer,
syntax
so
that
you
can
explicitly,
for
example,
do
delegate
star
open,
brack,
open
square
bracket
standard
call,
comma,
suppress,
gc
transition,
close
square
bracket,
which
will
specify
that
the
calling
convention
is
actually
standard
call
and
that
the
runtime
should
suppress
the
gc
transition.
E
A
A
Yeah
I
mean
this
makes
sense.
I
mean
this
is
kind
of.
As
you
said,
it
follows
the
existing
thing.
Where
did
we
put
the
suppressed
gc
transition
thing?
Is
there
oh
there's
a
calling
convention
struck?
Probably
somewhere
right?
E
So
this
isn't
an
actual
calling
convention
per
se
and
there
wouldn't-
and
it
wouldn't
be
a
as
far
as
I'm
aware,
but
I
could
double
check
with
yon
and
aaron.
We
wouldn't
also
be
updating
the
bit
flags
with
this
bit.
E
Instead,
the
way
it
works
is
that
the
as
far
as
the
bit
flags
work,
it
will
be
marked
with
the
new
extensibility
bit,
which
I
think
is
just
called
unmanaged
and
then,
if
the
unmanaged
bit
is
set,
you
have
to
look
for
the
corresponding
mod
opt
that
contains
these
types
so
call
con,
suppress
gc
transition
to
fully
interpret
it.
A
E
It's
prefixed
with
call
cons,
because
the
language
needs
to
know
which,
which
things
are
valid,
to
use
as
function
pointer,
modifiers.
E
So
it
it
does
that
by
looking
in
system
runtime
compiler
services
for
this
for
the
core
lib
assembly,
which
is
the
assembly
that
contains
object
and
has
no
dependencies,
and
it
looks
for
anything
prefixed
with
call
conf.
And
then
it
strips
that
call
con
and
allows
everything.
After
the
call
comp
has
the
actual
usage
in
the
language.
A
J
H
A
E
Well,
so
this
isn't
for
dot
net
five.
This
is
net
six.
A
E
Yeah,
there's
no
there's
no
language
support
required.
The
language
doesn't
do
anything
other
than
just
look
for
these
types.
There
is
jit
work
required
to
recognize
this
particular
mod
opt
and
that's
why
it's
not
for
dot
net
five.
A
E
So
certain
platforms
have
hardware
acceleration
for
cyclic
redundancy
checks.
We
are
proposing
exposing
under
bit
operations
a
set
of
helper
methods
that
will
call
the
underlying
platform
algorithm
where,
when
available
and
which
will
use
a
fixed.
What's
the
word
fixed,
it's
not
seed.
E
A
fixed
value
when
doing
the
algorithm,
rather
than
allowing
an
arbitrary
one
to
be
provided.
A
So
what
is
the
I
mean?
I
think
we
talked
about
crc
before
in
the
context
of
like
bit.
Operations
is
the
type
if
you
would
expose
things
that
would
always
work
right
and
they
would
in
turn
be
implemented
using
hardware
intrinsics,
where
applicable,
and
then
maybe
even
have
an
il
fallback.
If
none
of
the
intrinsic
supply
right,
this
one
probably
doesn't
have
a
fallback,
because
it's
so
basically
everybody
has
it
already.
E
No,
it
would
still
provide
a
fallback
because
hardware,
that's
like
all
hardware,
that's
10
years
old
should
have
it
but
hardware.
That's
like
14
or
14
years
old
might
not.
A
So
then
yeah
that
makes
sense
and
as.
E
So
these
functions
are
built.
These
functions
are
iterative,
so
you
would
end
up
doing
you
basically
pass
the
output
in
as
the
crc
value
of
the
next
call.
E
E
R
or
c
polynomial
there's
also
one
that
arm
uses,
which
is
zero,
four
c
one
one
d
db7,
which
it
provides
as
a
separate
instruction.
E
There
was
a
question
on
if
we
should
provide
a
variant
that
accepts
a
polynomial
and
which
the
jet
could
then
constant
fold
if
that
polynomial
matched
one
of
the
hardware
accelerated
ones,
and
my
initial
thinking
was
that
would
be
out
of
scope
and
we
could
look
at
providing
that
as
a
separate
api
in
the
future,
if
needed,.
A
E
A
E
Is
for
some
scenarios,
for
example,
zlib
uses
a
different
default
polynomial
than
is
hardware
accelerated.
E
So
in
some
scenarios
you
may
want
to
provide
a
polynomial,
that's
different
from
the
hardware
accelerated
version,
so
you
can
match
those
algorithms,
but
I
think
it
would
be
fine
to
expose
these
ones
document
that
the
polynomial
is
this
and
then
later
look
at
exposing
versions
that
take
in
polynomial
as
a
third
value.
Yeah.
H
A
A
I
think
I'm
fine
thanks,
like
yeah,
I
mean.
A
That
we
are
using,
I
suppose
the
ones
you're
using
are
somewhat
standardized
right.
It's
not
just
happenstance,
but
what's
happened
to
be
accelerated
right.
E
Right
the
hardware
explicitly
documents
the
polynomial
as
that.
A
H
A
J
Yes,
it's
it's
the
entire
week.
J
Well,
it
depends
on
which,
which
talks
he
wanted
to
watch
it's
the
the
conference
is
a
series
of
talks,
and
people
often
just
go
to
the
ones
that
interest
them
and
do
other
things
that
that's
actually
one
of
the
problems
with
it
being
a
virtual
conference
issuer.
Most
of
the
time
the
conference
is
meant,
for
you
know
networking,
rather
than
just
going
to
the
talks
so
yeah.
It
is
what
it
is.