►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
All
right
friends,
we
are
live
again.
Hopefully
this
time
I
finished,
or
I
fixed
my
streaming
issue
by
disabling
the
backup
software,
so
we'll
see
how
that
goes
today.
Right
now,
it
looks
like
everything
is
green
and
we
are
full
blasting
youtube
with
high
resolution
and
stuff
so
we'll
see
so
today,
what
we
do
is
we're
going
to
look
at
our
upcoming
generic
map,
feature
which
you
can
actually
find
on.
Designsoft.Net,
like
it's
like
in
the
middle
of
the
screen
here,
adding
rough
draft
for
the
minimum
bible
product.
A
I
already
opened
it
because
it
takes
forever
to
load
and
then
I
think
tana
will
walk
us
through
this.
B
Right
so
we
reviewed
this
previously
and
there
was
some
feedback
and
some
open
questions
and
largely
I'd
like
to
try
and
close
on
some
of
those
open
questions.
First,
as
I
believe
I've
got,
I've
done
enough
research
to
put
forth
a
proposal
for
which
way
we
should
go
overall,
there's
not
been
many
changes
to
the
to
the
interfaces
other
than
normalizing
on
the
names
we
agreed
on,
such
as
I
operator
name
operator.
So
I
addition
operators
and
minor
bits
like
that.
B
One
of
the
main
pieces
of
feedback
was
whether
or
not
we
should
have
both
iparsible
and
ispan
parsable
matching
I
formattable
and
I
span
formatible
or
if
we
should
just
have
I
parsible,
and
it
should
include
both
the
span
and
non-span
apis.
B
However,
I
parsible
in
itself
is
much
more
generally
usable
than
than
just
for
generic
math
or
just
for
parsing
spans,
and
so,
if
we
combine
them,
we're
going
to
be
requiring
all
users
to
implement
an
additional
overload
to
support
span
parsing
when
in
practice
that's
potentially
not
necessary
or
undo
overhead
on
their
part.
A
A
B
There
there
is
still
cost,
but
david
wrighton
ended
up
getting
a
typeloader
fix
and
we
no
longer
see
any
regression
or
it's
within
the
realm
of
noise,
with
the
number
of
interfaces
we're
exposing
and
so
the
number
of
interfaces
we're
exposing
shouldn't
be
a
concern
with
regards
to
these
two.
A
Yeah,
so
if
that's
the
case,
then
I
think
the
split
is
fine.
I
mean
if,
if
we
have
limitations
on
how
many
interfaces
we
can
have,
then
I
think
this
is
probably
one
way
I
could
live
with
collapsing
that
because
it
doesn't
really
impact
expressiveness,
it's
just,
as
you
said
it
just
might
mean
that
somebody
has
to
do
a
bit
more
work,
but
that
does
not
seem
super
terrible
compared
to
oh,
I
can't
express
that
my
type
doesn't
support
certain
kinds
of
mathematical
operations.
Right.
That
seems
more.
B
Yeah
and
and
in
particular
outside
of
generic
math,
I
expect
that
I
parsible
is
going
to
be
one
of
our
most
used
interfaces.
I
imagine
that
it
will
likely
be
implemented
or
recommended
to
be
implemented
by
any
type
that
implements
parsing,
which
is
many
types
that
support
formatting
as
well,
and
so
I
expect
it
will
be
more
generally
used,
whereas
generic
math
may
be
limited
to
library,
authors
or
libraries
doing
math
related
work
and
not
just
general
exposing
types
with.
B
To
look
at
the
other
open
question
is
actually
I
hadn't
ported
it
over
to
this
design
dock.
Yet
so
here's
the
link.
B
This
is,
namely
an
open
question
around
the
the
creation
apis.
B
There
you
go
all
right,
so
one
of
the
issues
with
dealing
with
generic
types
is
you
don't
know
what
type
you're
coming
from,
or
even
what
type
you're
going
to
most
of
the
time,
because
it's
generic,
and
so
you
need
to
be
able
to
do
things
like
take
a
literal
to
create
a
to
create
a
type
or
you
need
to
be
able
to
take
another
type
and
convert
it
to
the
type
that
you
want.
B
Ideally,
we'd
be
able
to
use
actual
like
implicit
or
explicit
casts
here,
but
because
you
can't
actually
make
implicit
or
explicit
casts
generic
themselves,
you
run
into
a
problem
with
being
able
to
expose
one
api.
B
In
fact,
you
end
up
having
to
expose
in
apis,
and
so
the
only
way
to
express
that
is
really
I
convertible
from
t,
and
that
ends
up
with
a
an
issue
of
I'm
exposing
too
many
interfaces
now,
because
even
to
support
the
10
fundamental
types,
that's
10
additional
interfaces,
and
so
what
you
really
want
is
to
build
is
the
ability
to
create
from
an
arbitrary
type,
and
so,
as
with
the
original
pr
or
with
the
original
proposal,
we
still
have
create
that
takes
it
to
other,
but
stephen
tobe
was
heavily
pushing
for
there
there's
a
particular
problem
here,
which
is
you
are
creating
from,
and
you
also
need
the
ability
to
convert
to,
and
so
you
would
so.
B
For
example,
if
you
have
big
integer,
you
want
to
be
able
to
create
that
from
other
types,
but
you
also
be
want
to
be
able
to
from
it
convert
to
other
types,
because
that's
going
to
be
more
efficient,
because
that's
the
only
way
you're
going
to
get
access
to
the
underlying
array.
B
B
The
proposal
for
this
is
is
basically
we
turn
the
we
we
take
the
we.
We
form
a
pattern
for
creation
on
these
apis,
where
we
effectively
have
create
and
try,
create
and
then
try,
convert
from
and
try
convert
to
and
much
like
with
the
dispose
pattern
where
there
is
a
recommended
way
to
do
it,
and
do
it
correctly.
B
There
will
be
a
recommended
way
to
implement
this,
create
pattern,
and
do
it
correctly
so
that
you
can,
with
generic
math,
do
convert
from
and
convert
to
without
ending
up
in
infinite,
recursion
or
other
problems,
and
so
in
particular
create
and
try.
Creator
are
functionally
the
same,
create
just
forwards
to
try,
create
and
throws.
B
If
the
creation
fails,
whereas
try
create,
will
it
will
actually
do
the
checks
for
what
the
type
is
and
return
false
if
the
type
is
unsupported
and
so
functionally
try
create,
is
I'm
going
to
try
to
create
from
on
t
self
and
if
that
fails,
I
will
try
to
convert
to
on
t
other,
and
so
this
ends
up
with
a
pattern
where
you
don't
have
any
kind
of
potential
recursion
between
the
two
and
where
users
still
have
the
option
to
to
build
on
the
fundamentals
efficiently.
B
B
Yeah,
it's
likely
that
we
will
get
it
for
seven
and
hopefully
because
we've
we've
set
forth
the
requirement
that
we're
going
to
need
dems
by
at
least
the
next
time.
We
want
to
add
to
any
of
these
interfaces,
and
so
hopefully
we
do
get
it
in
v1.
That
way,
we
can
just
make
a
number
of
these
implementations
simpler,
and
so
that
would
that
would
be
ideal,
but
the
pattern's
also
simple
enough
that
an
analyzer
could
do
it.
Much
like
it
does
with
dispose
and
and
simplify,
simplify.
A
A
B
Well,
you
don't
access
them
through
the
interfaces
is
the
thing
in
the
actual
generic
code.
You
would
do
tself.create,
which
is
likely
simpler
than
any
other
pattern.
You
could
come
up
with
because
any
generic
helper
type
you're
going
to
have
some
generic
helper
type
of
type
of
t
self
dot
create,
and
so
ideally
this
is
just
dims
and
we
make
it
dim
that
way.
You
can
just
do
t
self,
creating
you
don't
have
to
implement
those,
so
you
only
have
to
do
the
convert
from
and
convert
to.
B
Yeah
so
so
in
particular,
for
I
number
t
other
is
constrained
to
be
another.
I
number.
E
The
the
one
thing
that
I'll
say
looking
at
this
right
now
that
concerns
me
a
little
bit
is
that
there
may
be
types
for
patterns
like
this,
where
I
don't.
I
feel
that
like
create
just
by
itself,
may
be
too
simple,
but
I
guess,
if
it's
down
to
the
specific
type,
they
can
aliase
it
away,
because
you
can,
you
can
explicitly
implement
static
interface,
members
right.
E
B
Yeah
there's
going
to
be
a
separate
discussion
here.
We
can
either
have
it
today.
If
we
have
time-
or
we
can
do
it
as
part
of
the.net
7
review
of
where
we're
going
to
have
to
decide
what
apis
are
going
to
be
public
and
therefore
accessible,
whether
you're,
using
a
generic
or
not
and
which
ones
are
going
to
be
only
accessible
through
a
generic
context.
A
B
So
the
common
pattern.
Well,
I
actually
had
an
example
here.
A
That
is
you
make
the
mistake
that
I
always
make,
which
is
you
assume
that
it
would
actually
parse
with
your
typing,
but
it
doesn't
do
that.
D
G
A
Just
add
the
there's
this
a
button
here
or
you
can
actually
paste
the
text
as.
B
Given
just
I
number
I
floating
point,
you
could
conceptually
have
an
additional
interface,
I
convertible
too,
but
then
you
have
the
problem
of
you
have
to
have
that
interface
for
every
type
you
were
convertible
to
or
from,
and
that
just
explodes,
at
least
by
10,
and
if
not
by
more
just
to
support
the
primitive
types
and
so
create
solves
that
problem
by
having
a
single
api
that
is
itself
generic
to
cover
the
types
and
so
fundamentally,
you
do
t
result
dot
create
and
you
pass
in.
B
A
B
A
Yeah,
I
guess
so
you
could
have
an
I
numerable
of
in
ins
and
then
you
said,
t
result
is
double
right.
Right,
yeah.
B
E
B
We
likely
can,
we
could
likely
have
some
like
I
creatable
interface
or
something
similar.
I
had
not
come
up
with
a
good
name
for
it.
A
A
It's
similar
to
like
how
parsable
is
a
separate
thing
right,
not
tied
to
any
number
either,
and
it
might
be
easier
to
explain
if
we
say
yeah.
This
is
a
you
know
a
conversion.
I
mean.
I
guess
it
would
be
weird
if
the
methods
are
called
create
on
the
type
called
eye
convertible,
but
it
doesn't
really
matter,
but
just
we
can
pick
up
some
name
and
then
make
sure
that
it
makes.
A
C
C
A
B
B
Do
I
have
to
consider
failure,
cases
etc?
I
want
the
consumers
to
have
it
simple
and
then
implementers,
because
I
don't
think
there's
a
better
way,
we'll
have
to
follow
a
pattern
to
avoid
things
like
recursion,
where
you've
got
t
self
trying
to
create
a
from
a
t
other
and
then
t
other
trying
to
convert
to
a
t
self,
and
it
just
ends
up
in
an
infinite
loop
or
something.
A
It's
surprisingly
simple
to
get
there
yeah,
so
that
makes
sense.
B
No,
the
the
the
question
was:
does
this
pattern
make
sense
yeah
and
it
sounds
like?
Yes,
it
does,
but
we
want
to
extract
the
convert
from
and
convert
to
to
a
I
convertible
of
t
self.
A
Yeah,
that
would
probably
be
basically
following.
I
parsable
right.
D
D
B
The
natural
pattern
for
implementing
these
for
a
naive
user
might
be
to
try
and
handle
all
cases
in
create,
and
so,
if
you're
trying
to
handle
all
cases
in
just
create,
then
naturally
you
would
do
something
like
if
t
self
dot
try
create
from
the
other
else,
t
other
dot.
Try
convert
to
exactly
like
this
pattern
has
here
and
try
create.
B
However,
if
those
are
the
only
apis,
then
you're
effectively
referring
convert
your
you're
and
convert
from
to
convert
to
in
the
fallback
case,
and
vice
versa,
and
and
you
end
up
with
trivial
cases
where
you
can
end
up
with
infinite
recursion,
because
you're
trying
to
handle
all
cases
via
one
api
split
explicitly
splitting
at
splitting.
It
out
ensures
that
users
have
a
direct
pattern.
B
E
E
E
Like
you
have
a
use
for
it
number,
which
is
your
the
create,
that's
gonna,
go
and
ask
both
directions.
I
don't
know
that
at
the
convertible
level,
we
we
need.
D
A
A
So
basically,
if
we,
I
guess
my
question
is
assuming
that
we
expect
that
we
are
the
primary
implementers
and
we
want
to
effectively
get
more
feedback
on
people
writing
algorithms,
rather
than
implementing
those
interfaces,
then
I
would
probably
just
say:
yeah:
we
define
them
and
then,
if
we
can
move
them
to
a
dim
in
seven,
that's
fine,
because
we
can
make
breaking
changes
here,
but
it
seems
desirable
that
if
you
want
to
test
how
nice
somebody
can
write
an
algorithm,
you
want
to
deny
some
methods
rather
than
forcing
people
to
go
through
the
crazy
pattern.
E
E
E
G
A
That
makes
sense,
then,
what's
the
next
area.
B
The
next
area
is
also
related
to
create,
and
it's
a
point
where
I
think
steven
and
I
disagree
on-
which
is
the
better
approach
here.
B
So
in
particular
I
have
four
I
number
I
have
dot
create
as
doing
an
exact
conversion
and
failing
that
is
throwing
if
the
conversion
is
not
possible.
F
A
B
Yeah
so
let's
say
that
you're,
let's
say
that
you're
doing
average
and
your
t
result
is
an
int
or
yeah.
Let's
say
it's
an
int
and
your
t
self
is
an
int
as
well
when,
when
you're
doing
these
or
actually
sums
the
better
one
to
look
at
here,
but
it
it
doesn't
make
too
much
difference.
A
E
Or
well
it'd
be
int
dot
sum,
and
then
I
think
the
generics
will
get
inferred.
B
A
E
B
And
this
is
slightly
off,
but
the
general
point
is:
you
are
trying
to
create
the
t
result
type
from
the
t
self
type.
If
the
t,
let's
say
that
the
t
result
type
is
actually
or
let's
say,
the
result,
type
is
byte.
Actually,
okay,
if
one
of
the
inputs
is
256,
should
the
default
behavior
of
create
b2,
throw
or
not
throw
due
to
overflow.
B
B
And
so
steven's
point,
and
please
correct
me
if
I'm
wrong
steven
is
that
we
should
try
and
match
the
default
behavior
for
non-literals
and
effectively
allow
the
conversion
and
truncate
by
default.
B
And
my
view
is
that
because
you
don't
know
the
input
type
and
you
don't
know
the
target
type
and
therefore
you
don't
know
whether
it
could
overflow
or
not
the
good
default
behavior
is
to
overflow
and
throw
an
overflow
exception
if
the
conversion
would
fail.
If
that
is
if
it,
if
it
is
a
non-exact
conversion,
and
if
you
want
to
have
the
truncating
behavior,
you
should
be
explicit.
B
G
I
think
you
you
got
my
just
to
summarize
my
opinion.
It's
that
the
language
by
default
doesn't
have
checked
the
only
place
it
does
is
as
a
special
case,
if
you're
using
constant
values
that
the
compiler
can
check
at
compile
time
right.
G
B
This
is
a
new
concept
around
generics,
where
you
fundamentally
don't
know
either
type
and
so
having
the
having
overflow
by
default.
Here
is
goodness,
and
users
can
just
be
explicit
of
I
want
truncating
behavior
or
I
want
saturating
behavior
if
they
are
aware
and
want
to
support
input
types
like
going
from
an
int
input
to
a
byte
output.
They
should
be
very
explicit
and
handle
that
case
and
that
will
be
easily
caught
by
overflowing
by
default.
A
So
for
operators
there's
this
discussion,
whether
we
can
have
checked
and
unchecked
with
the
naming
convention
right,
where
the
where
the
compiler
can
choose
the
appropriate
one
based
on
checked
and
unchecked
context.
Right
right
should
have.
You
ever
talked
about
doing
something
similar
for
the
create
methods.
B
I
don't
I
have
not,
and
I
think
that
would
be
much
more
complicated,
because
the
operators
are
special
names,
their
names
that
you're
not
likely
to
encounter
otherwise
and
they're
done
using
specific
operators
that
is
built
in
language,
recognized
syntax.
B
You
can't
really
do
that
with
these
methods,
because
they
are,
they
have
concrete
names
and
so
without
making
it
a
like
an
unspeakable
name
and
having
a
compiler
and
ide
do
magic
to
expose
it
as
something
else.
I
don't
think
that's
going
to
be
feasible
and
jared's
already
not
a
fan
of
exposing
checked
operators,
so
I
already
have
to
argue
for
those
anyways.
A
D
A
B
Right
and
we
could,
if
there
was
if
conversion
operators
were
allowed
to
be
generic,
but
I
think
there's
problems
there
and
it
requires
more
discussion
with
the
alexei
jared
and
mads.
B
B
And
so
you
you
functionally
need
to
be
able
to
declare
operator
explicit
t,
other
t
other
and
then
passing
in
t
self
result
and
then
the
inverse
for
convert
two
I
see
or
convert
from
and
there's
no
way
to
do
that
today.
A
I
mean
yeah,
I
guess
this
is
kind
of
why
I
said
like
we
should
look
at
what
the
default
behavior
you
know
is.
If
we
move
to
checked
or
not
like
it
seems
to
me
like
yeah,
we
want
to
be
somewhat
consistent
with
what
what
our
expectations
are.
If
you
don't
specify
something
whether
it
be
overflow
by
default
or
we
throw
by
default-
and
I
honestly
don't
have
super
strong
opinions,
because
they
both
have
different
pros
and
cons
right.
E
B
I
I
view
the
create
methods
more
like
constructors
than
as
operators
and,
like
jeremy
said,
if
this
were
a
constructor
and
you're
passing
in
a
too
large
value.
The
default
behavior
that
I
would
expect
is
to
throw
because
it's
argument
out
of
range
and
then
you
explicitly
do
a
different
conversion.
If
you
want
to
say
this
is
safe,
such
as
using
the
alternative,
truncating
api.
That
explicitly
says,
I'm
going
to
truncate
this
value
if
it
is
too
big.
B
G
I'm
not
saying
unchecked,
I'm
saying
with
the
the
operators
that
exist
today
are
are
unchecked
like
cast.
Operators
are
unchecked,
so
unless
you
opt
in
in
the
language
so
saying
status
quo,
if
you
have
the
ability
to
just
have
a
explicit
cast
operator
here,
it
would
be
unchecked
and
you'd
be
fine
with
that.
A
So
I
guess
what
I'm
hearing
is
that
you
read
a
casting
operator
as
a
kind
of
like
a
developer
provided
override.
If
you
will,
where
you
basically
say,
I
opt
into
this
hard
cast
behavior
and
if
that
means
I
get
truncation
that
seems
fine
versus.
If
I
see
a
regular
method
call,
I
I
assume
that
if
things
go
south,
I
get
an
exception
rather
than
just
some
weird
value
back.
B
G
Well,
but
there
are
three
behaviors
there's
allow
overflow,
underflow
and
rap,
or
whatever
the
equivalent
is
there's
truncate
and
there's
or
or
there's
a
throw
and
there's.
What
do
you
call
it?
Clamping
or
saturating.
F
G
G
The
non,
if
you
don't
throw
there's
two
behaviors,
do
you
do
you
allow
truncating
or
wrapping,
or
do
you
constrain
it
to
the
min
and
max
for
that
type
and
then
for
throwing
is
if
you
go
up
or
you
know,
go
overflow
or
under
flow
with
rows.
G
G
B
Right,
I
think
explicitly
saturating
is
the
wrong
default,
and
then
I
think
I
think
truncating
is
the
wrong
default,
because
this
is
a
this
is
different
from
the
other
scenarios
in
which
truncating
is
normal
and
there's
and
it's
it's
a
method,
not
a
conversion
operator.
Now.
I'd
like
I
said,
I'd,
be
fine
with
conversion
operators,
but
only
assuming
that
the
language
got
the
required
features
to
to
allow
them.
G
B
I'd
be
fine
with
that
as
well.
It's
just,
I
think,
a
few
extra
characters
for
what
I
think
a
good
default
is.
A
E
G
No,
it's
I'm
wrong.
It
throws
it
throws
like
convert,
convert
dot,
two
byte
taking
an
int,
throws
if
it's
larger
than
byte
max
value,
yeah.
E
A
E
D
E
Do
it
if
I
convertible
t
cell
phone
number,
we'll
call
create
truncating
or
sorry
create,
I
guess
it
would
just
be
create
and
that's
the
throwy
one
and
then
we
would
add
on
number,
create
truncating
or
convert
truncating
and-
and
I
guess
saturating.
If
anybody
wants
that.
B
E
Yeah
and
those
are
on
all
of
these
tri-converts
false
means-
I
don't
know
what
the
type
is
and
then
the
exact
or
the
one-on-one
convertible
will
throw
for
out
of
range
and
the
one
for
the
other
ones
have
their
behavior
defined.
So
they
shouldn't
ever
throw.
E
Now,
when
you
say
convert
exact,
you
used
a
word
that
you
don't
often
use,
which
is
exact,
so
does
create
exact,
always
fail
if
a
double
goes
to
a
float.
E
B
F
B
Like
exact
actually
has
terminology
in
ieee
floating
point
spec,
and
so
it's
not
a
great
word,
and
I
triple
e
actually
has
the
ability
to
do
things
like
throw
exceptions
if
you're
doing
a
non,
a
a
non,
precise
operation
or
conversion,
but
I
also
can't
think
of
another
name.
That
accurately
represents
like
I'm
going
to
this
is
this:
is
the
one
that
overflows,
maybe
it's
just
create
overflowing,
create,
throw
overflow
or
something
I
don't
know.
A
I
mean,
if
the
I
mean,
if
the
x
yeah,
if
the
expectation
is,
we
just
designate
that
if
the,
if
the
value
is
outside
the
range
of
the
underlying
type,
then
we
throw
an
exception.
Then
I
think
checked
is
probably
the
right
terminology
or
the
close
enough
one
and
then
for
double
versus
flow.
It's
like
well.
D
E
B
Yeah
and
that's
actually
a
thing
where
I
think
the
long
to
double
conversion
should
have
thrown
for
overflow,
or
at
very
least
it
should
have
been
explicit
and
not
implicit.
A
A
E
Okay
but
yeah,
I
was
because
you're
the
one
who
cares
the
most
about
floating
point
operations.
Tanner
when
you
said
exact,
I
definitely
spock
eyebrow.
B
I
just
don't
have
a
better
word,
but
unchecked
seems
reasonable.
B
And
to
answer
jeremy's
question
of
what's
the
use
case
for
saturating
it's
a
decently
common
operation
that
we
do
ourselves
in
many
of
our
low-level
algorithms,
specifically
when
we
want
to
clamp,
and
so
there
are
many
cases
where
you
do
want
to
say.
If
I
have
a
value,
that's
too
large
or
too
small,
I
want
it
to
become
min
value
or
max
value.
A
A
A
B
It
sounds
like
create
check,
create
saturating
and
create
truncating
steven
also
suggest
create
clamp
clamping
instead
of
saturating.
B
E
E
E
A
B
G
A
A
Well,
I
mean
to
me
that
kind
of
yeah,
on
the
one
hand,
side
I
agree
with
the
reasoning.
On
the
other
hand,
though,
like
stephen's
concern
was,
I
don't
want
a
world
where
people
don't
have
to
specify,
and
then
we
just
choose
a
vader
that
doesn't
map
to
c
sharp
right,
in
which
case
it
seems
like
we
don't
want
a
world
where
you
can
actually
choose
between,
create
truncated,
clamp,
checked
and
just
create.
It
seems
like
we
want
people
to
always
say
like
which
of
the
three.
Do
you
want.
E
A
E
A
Could
do
that
or
we
could
just
say
screw
it.
Those
are
concepts
that
might
exist
for
any
type
right
I
mean
if
you
have
a
vector
type,
while
individual
components,
you
know
it
still
made
sense
to
talk
about
truncation
versus
clamping
versus
checking
right,
it
doesn't
have
to
be
a
primitive
type
right
or
even,
if
you
have
a
customer,
let's
say
right
and
you
have
individual
fields
where
those
might
still
apply
right.
So
so.
A
B
So
the
issue
I
have
with
that
is
that
that
restricts
convertible
to
only
being
used
from
number
like
types.
It
would
not
be
usable
from
something
like
date
time
where
arguably,
some
of
the
concepts
do
map
as
well.
Why.
A
E
B
A
A
I
think
the
I
think
I
would
say
if,
if
you're,
if
basically
your
conversion
involves
numbers
well,
then
the
methods
tell
you
what
to
do.
If
yours
doesn't
involve
any
numbers,
and
then
you
know
you
just
you
basically
say
they
all
behave
the
same
right.
So
it's
just
contextually,
I
guess
clear
which
behavior
you
get.
Okay,.
A
You
look
at
convertible
in
general,
it's
super
rare
to
do
it
outside
of.
I
guess
something
that
is
numeric
to
begin
with
right,
because
that's
usually
where
the
conversions
are
happening,
it's
either.
You
know
things
two
strings
or
from
strings.
I
mean
that's,
you
know
very
common.
You
know
parsing
kind
of
situation,
but
then
the
other
side
is
just
yeah
I've.
I
have
some
box
number.
I
have
no
idea
whether
it's
a
short
or
a
byte,
but
I
just
want
to
get
it.
A
You
know
along
out
of
it
right
and
then
that's
why
convertible
helps
you
over
regular
casting,
because
if
I
hard
cast
a
bite
too
long
well
that
falls
at
one
time.
So
I
guess
I'm
sorry
a
boxed
byte
right.
If
I
tried
to
cast
this
too
long,
this
will
fail
at
one
time.
So
there's
a
that's.
Why
I'm
not
super
concerned
with
saying
we
force
this
concert
on
everybody
because
I
feel
like
in
practice.
It
will
probably
apply.
B
E
I
also
wonder
if
we're
actually,
even
if
the
I
convertible
of
t
self
makes
sense,
because
I
don't
think
that
we'll
say,
or
you
end
up
in
the
same
problem,
that
we
have
right
now
with
high
convertible
of
it's
not
really
extensible,
I
mean
it
sort
of
is,
but
the
if
the
t
other
is
also
has
to
conform
to
the
I
convertible
of
t
cells.
Well,
in
that
case,
high
convertible
of
the
other,
then.
E
It
feels
like
you
end
up
with
I.
I
want
this
new
type
to
exist,
but
or
there's
a
type
that
I
don't
control
that
it
makes
sense
for
me
to
convert
to,
but
now
I
can't
because
it
doesn't
conform
to
the
interface,
and
so
you
end
up
sort
of
exactly
where
I
convertible
is
of
the
like.
Why?
Why
does
this
feel
fused.
A
E
B
A
B
E
B
And
then,
since
steven's,
here
now
and
since
he
wasn't
able
to
voice
his
side
earlier,
we
might
just
want
to
quickly
re-go
over
the
iparsable
versus
I-span
parsable
discussion
for
context.
B
The
decision
was
to
keep
the
split
one,
because
we
don't
have
the
concern
on
the
number
of
interfaces
causing
a
startup
regression
now,
but
also
the
reason
that
I
argued
for
keeping
the
split
is
that
span
is
still
very
much
in
an
esoteric
and
largely
limited
to
library
usage
feature:
it's
not
widespread
outside
of
performance,
oriented
scenarios
and
there's
many
types
across
the
ecosystem
that
don't
implement
span
today,
whereas
iparsable
is
a
generally
more
usable
feature,
it's
potentially
going
to
be
the
most
used
interface
out
of
all
of
the
ones
we're
exposing
just
because
it's
the
counterpart
2
I
formattable,
and
it
basically
means
I
can
generically
create
myself
from
a
string
and
so
therefore
serialize
d,
serialize,
etc.
B
G
With
it
is
the
kind
of
the
counterpart
to
what
you
just
said,
and
that
is
we
won't
be
requiring
people
to
implement
it.
We
make
it
easy
for
them
not
to
which
then
means
yeah.
There
are
many
many
fewer
producers
of
types
especially
implementing
generic
interfaces.
Then
there
are
consumers
of
those
types.
So
we
really
want
the
folks
that
are
producing
those
types
to
provide
the
functionality
that
we
actually
want
people
to
consume,
and
we
actually
want
people
to
use
to
be
able
to
at
least
if
they
want
to
use
the
span
based
ones.
G
B
I
think,
because
of
the
res,
the
way
the
rest
of
the
ecosystem
is
set
up
and
because
we
would
functionally
already
need
an
analyzer
to
push
them
in
the
right
direction
for
things
like
I
formattable,
I
think
the
same
performance
analyzer,
if
you
will
should
recom,
should
look
for
things
like
oh
you're
implementing
I
formattable,
but
not.
I
span
formatible
you're
implementing
I
parsible,
but
not.
I
span
parcel
or
yeah.
G
B
G
That
perspective,
I
worry
that
we're
just
every
time
we
have.
One
of
these
cross-cutting
features
we're
going
to
continue
to
proliferate
sort
of
the
bifurcation,
and
you
know
two
interfaces.
Instead
of
one,
it
seems
like
a
an
unsustainable,
maybe
too
strong
word,
but
an
unfortunate
path
to
continue
going
down
and
at
some
point
we
should
bite
the
bullet
and
say
that
this
thing
is
central.
G
Now,
maybe
it's
not
now,
maybe
because
we
had,
we
already
had
I
formattable
and
therefore
we
had
to
add
I-span
formattable,
and
this
is
the
counterpart.
Maybe
we
say
all
right
well
in
this
case,
we're
doing
it
for
consistency
like
again
I
you
know,
I
don't
feel
super
strongly
about
it.
It
just
seems
like
on
just
one
more
piece
of
unnecessary
complexity:
yeah.
B
And
I
don't
feel
super
strongly
either.
I
just
I
had
the
leaning
towards
matching
what
we're
already
doing
for
the
other
types
and
then
allowing
easier
onboarding
for
for
users
specifically,
because
I
think
iparsable
is
going
to
be
more
broadly
used
than
most
of
the
other
ones.
G
It's
it's
possible.
I
would.
I
would
really
hope
that
anyone
who's
implementing
one
of
these
brand
new
generic
interfaces
for
parsing,
where
span
is
like
front
and
center
for
how
we
want
people
doing
parsing,
moving
forward,
that
they
would
use
spans
and
therefore
that
they
would
implement
the
interface
and
now
we're
actually
making
it
more
complex,
because
now
they
have
to
you
know,
figure
out
which
of
the
interfaces
to
implement
and
realize
that
one
inherits
the
other
and
choose
that
one
and
still
implement
both
methods.
G
We
want
to
stick
with
the
decision.
That's
fine.
E
For
what
it's
worth,
I
think
steve
has
convinced
me
well
we're
calling
it
experimental
if
we
collapse
them
now,
we
can
expand
it
for
rtm,
it's
harder
to
go
the
other
way.
B
B
B
B
E
E
This
method
exists
and
you
can't
change
it,
but
but
we
can
live
because
the
problem
will
be
that
I'll
say
that
it
should
throw
for
an
old
string
and
the
steve
will
say,
but
that's
like
three
extra
lines
of
I'll
just
let
the
conversion
that
accepts
nolan
calls
it
the
empty
string,
work
and
then
I'll
turn
off
my
microphone
and
go
in
the
other
room
and
grumble
and
then
come
back
and
just
move
on,
because
that's
how
that
normally
goes.
A
E
I
so
steve,
I
think,
has
convinced
me
that
if
at
some
point
we
want
to
say
that
span
is
a
thing
and
not
a
niche
thing.
We
have
to
start
doing
that
and
that
the
people
that
are
going
to
be
implementing
these
interfaces.
My
cameras
field
of
views
back
here,
the
people
that
are
going
to
be
implementing
these
interfaces
probably
already
understand
what
span
is
so.
Why
are
we
making
it
be?
E
Don't
say
that
you
conform
to.
I
parsible
say
that
you
conform
to
ispan
parcel
and
then
just
write,
all
four
methods
or
whatever
that
are
required.
So
let's
just
get
rid
of
the
span
variant.
B
And
my
own
expectation
is
that
this
one
isn't
just
going
to
be
used
by
power
users.
I
think
generic
math
in
general
might
be
used
by
framework
authors
and
users
who
are
looking
for
performance
and
reducing
code
complexity,
but
I
think
iparsable
is
one
that
is
going
to
probably
become
a
fairly
standard
if
I'm
implementing
a
type
that
supports
parsing,
I
implement
this
interface.
A
B
We
basically
said
that
we're
going
to
use
dims
and
we're
going
to
tell
users
we're
going
to
use
dim,
so
don't
do
things
that
will
cause
diamond
problems
because
otherwise
we
have
to
expose.
I
number
two.
I
number
three,
I
number
four
as
we
decide
to
add
new
methods
and
that's
going
to
be
unmaintainable,
so
users
are
going
to
get
dims
and
if
they
create
a
diamond
problem,
that's
on
them.
B
Interface
c
sharp
at
least
won't.
Let
you
do
it.
The
the.
I
think
the
real
problem
is
that
if
you
happen
to
write
a
scenario,
compile
and
compile
and
c
sharp
says
it's
fine,
but
then
you
go
and
make
a
breaking
change
in
one
of
the
base
interfaces.
B
You
can
create
a
diamond
at
runtime
that
runtime
catches,
but
these
are
all
in
corelib
and
we're
going
to
be
very
explicit
about
we're
going
to
use
dims
in
the
future.
So
yeah
be
mindful.
A
A
So
that's
why
the
suggestion
in
chat
you
know
path.
String,
can
dim
forward
to
pass
span
using
a
dim,
wouldn't
not
workable
right
now,
but
it
might
be
later
yeah
right,
I
mean
I
will
generally
say
like
I
I'm
conflicted.
I
understand
what
stephen
is
saying.
At
the
same
time,
I
I
do
like
the
inverse
of
the
I
f
formattable
and
I
span
formattable,
and
I
also
kind
of
think
that
the
I
possible
of
t
might
be
more
useful
for
most
people
who
don't
care
about
the
performance
and
the
problem.
A
I
don't
know
that
seems
not
necessarily
related
to
that.
So
that's
why
I
don't
know
I
mean
we
can
go
either
way.
I
guess
and
then
see
what
actually
works.
That's
the
whole
point
of
experimental
features,
but
I'd
be
just
careful
with
lumping
them
all
together
and
saying
yeah.
You
have
to
basically
bite
the
bullet
and
deal
with
spam.
A
A
All
right
so
then
I
kind
of
lost
track
of
what
so
the
conclusion
is.
For
now
we
keep
the
split
or
we're
saying
we
undo
the
split
and
then,
if
you
want
to
split,
we
split
later,
like
that's
the
thing,
I'm
not
sure
like
there
was
some
discussion
on
what
is
easier
for
us
to
do
or
less
risky.
B
A
B
My
own
experience
in
the
c-sharp
discord
and
the
non-low-level
channels
has
been
that
span
is
a
very
esoteric
concept
to
other
developers
and
I
do
not
want
to
increase
the
hurdle
or
burden
for
users
to
have
to
implement
iparsible
they
they
shouldn't
have
to
know
about
spans,
to
implement
it
and
honestly,
they
don't
and
outside
a
very
outside
of
a
scenario
where
you're
like
taking
a
giant
string
and
parsing
a
subsection
of
it.
A
B
I
think
that
was
all
of
the
core
items
that
we
needed
to
resolve
things
on,
and
so
what's
left
is
basically
the
open
questions
of
for
net
seven.
B
A
B
Yeah-
and
we
I
didn't
expect
to
get
to
this-
we
actually
went-
went
faster
through
the
other
topics
than
I
expected.
I
expected
us
to
stay
and
discuss
a
number
of
them
for
longer.
A
B
It's
actually
not
too
bad.
So
if
you
just
go
to
the
numeric
interfaces,
tag
which
is
going
to
be
below
this,
then
I
number
is
the
is
the
core
one.
So
we
explicitly
said
we're
going
to
we're
going
to
want
the
the
create-
or
I
guess
now
as
we're,
calling
them
the
convert
from
and
convert
to
to
be
explicit.
A
E
A
A
E
B
E
B
B
The
language
would
have
to
understand
that
the
generic
there
is
actually
t
self
in
a
way.
That
means
this
is
the
constraint
token
and
as
the
language
is
configured
today,
it
t
self
is
just
another
generic
argument,
and
this
is
a
pattern
that
fits
the
bill,
but
there's
no
actual
special
understanding
of
it.
A
B
A
Truncated
right,
so
that's
why
I
would
just
say
like
if
the
thing
literally
never
makes
sense,
I
think
it's
fine
to
say:
don't
you
know,
let's
not
expose
it.
If
there
are
cases
where
well,
you
know
it
might
be
useful,
but
most
of
the
time
it's
noise
and
I
think
saying:
oh,
if
it's
only
a
cast,
it's
fine,
but
if
it
requires
another
method,
then
maybe
that's
too
much
of
a
speed
bump
and
then
we
say
it's
cool.
We
just
expose
it.
E
A
E
A
A
A
A
If
you
want
to
still
keep
the
the
primitive
types
super
clean,
which
is
what
they
are
today,
but
they
have
like
you
know
less
than
20
members,
then
I
think
yeah.
We
should
not
expose
the
created
ones,
but
once
you
buy
indentator
well
there
might
be
50
or
60
members
now,
but
that
point
is
like
well:
if
it's
50
or
60
members,
then.
A
Well,
I
mean,
I
assume
that
you
know
all
the
ones
here,
like
abs
clamp
max
min.
I
mean
that
was
more
than
what
tenor,
I
think
proposed
for
algorithms
right.
B
So
you're
thinking
about
floating
point
which
exposes
the
rest
of
the
math
methods.
These
are
the
math
methods
that
happen
to
abs,
clamp
and
stuff,
or
the
ones
that
happen
to
apply
to
all
numbers.
B
Right
so
so
int
implements,
I
number
specifically
it
implements.
I
signed
binary
integer.
B
D
B
Right,
but
so
so
there's
a
there's,
a
split
between
all
numbers,
integer
numbers
and
floating
point
numbers
and
there's
an
interface
for
integers,
floating
points
and
numbers.
These
are
the
ones
that
are
just
all
numbers,
so
absolute
values,
which
is
a
no
op
for
unsigned
types
right,
clamping
which
applies
to
anything
that
is
comparable,
which
technically
applies
to
anything
that
is
comparable
and
has
that
is
comparable.
B
We
could
put
it
on
eye
comparison
operators,
but
without
dims.
I
don't
think
we
had
wanted
to
move
it
down
yet
right
and
then
the
same
for
max
and
min
and
then
sign
likewise
for
unsigned
types.
It
can
only
return
zero
or
one,
but
for
un
for
sign
types
it
can
also
return
negative
one
to
represent.
I'm
unsigned.
B
Right
for
for
like
in
32,
it
will
be
a
small
number
of
methods
yeah.
I
I
expect
that
we
don't
want
to
expose
one
and
zero
explicitly.
I
or
implicitly
I
expect
we
want
them
to
be
explicit,
yeah
and
the
same
with
negative
one
on
I
signed.
B
Number
yeah,
parse
and
tripars
are
already
public
methods,
so
those
ones
would
be
implicit
yeah
and
so
for
for,
like
in
32,
it
comes
down
to
create
which
it
sounds
like
we
want
it
explicit,
except
for
maybe
saturating,
and
then
abs,
clamp,
div,
rem,
max
and
min
would
and
sign
would
be
public.
B
A
Yeah
I
just
chat
with
kristoff,
apparently
in
d1
that
tried
to
like
make
these
things.
Look
very
lightweight,
but,
like
I
mean
it
does
I
mean
for
statics.
It
doesn't
really
matter,
but
you
clearly
don't
blow
the
instance,
so
it
doesn't
really
matter
but,
like
the
yeah,
I
think
at
this
point
I
think
we
can
accept
the
fact
that
there's
more
useful
stuff
on
those
types.
B
And
then
float
will
actually
get
much
bigger
because
it's
basically
all
of
math,
so
we're
gonna
get
e
pi
tau.
We
already
have
negative
zero
or
no,
we
don't
have.
We've
got
positive,
infinity
and
negative
infinity.
B
We
use,
but
don't
expose
negative
zero
and
that
one
probably
should
be
exposed.
B
It's
a
zero
that
is
negative
and
it
is
I'm
going
to
make
a
lot
of
people
mad
by
saying
that
it's
good,
it
basically
exists
because
floating
point
is
non-exact,
and
so
let's
say
that
you
have
two
you've
got
a
negative
value
and
a
positive
value
and
their
exact
result
is
near
zero
near
zero
and
negative.
But
it's
not
actually
zero,
but
that
value
is
not
representable
by
a
floating
point
due
to
precision
limitations.
I
guess.
B
Negative
zero
allows
you
to
represent
that
this
is
a
value
that
is,
for
the
purposes
of
floating
of
binary
of
computer
binary
floating
point
zero,
but
it
was
rounded
from
a
negative
result,
and
so
therefore,
in
further
operations
it
can
impact
the
the
overall
result
and,
for
example,
you
can
get
negative
infinity
instead
of
positive
infinity.
If
you
pass
it
into
certain
transcendental
functions,.
A
A
F
B
Yeah,
and
so
that
that
shows
all
the
functions
that
we
expose
today,
all
the
functions
that
we
have
approved,
but
not
yet
implemented.
Just
because
haven't
had
time
since
I
got
pulled
off
on
to
do
generic
math
this
release
and
then
the
other
concepts
that
ieee
talks
about
that
we've
not
exposed
yet
or
not,
and
and
or
not
reviewed.
A
B
B
B
What
is
the,
what
is
the
I
guess,
plan
here
for
moving
forward
we're
going
to,
of
course
come
up
with
new
apis?
We
want
to
expose
they'll,
go
on
to
float
and
double
they'll,
get
added
to
eye
floating
point
as
dims.
B
For
those
when
it
comes
to
math
and
math
f,
are
we
going
to
continue
mirroring
those
where
possible
for
float
and
double
specifically?
Are
we
going
to
explicitly
not
mirror
them
and
never
mark
the
types
as
as
obsolete,
or
are
we
going
to
explicitly
like
market
obsolete
and
have
an
analyzer
suggesting
people
move.
B
E
E
Because,
at
least
for
the
things
that
I've
been
wanting
to
put
obsolete
on
in
crypto
it's
I
wish
that
I
could
put
the
obsolete
on
it
in
that
standard
of
you.
Shouldn't
have
even
been
calling
this
in.net
framework.
The
the
trouble
that
I
have
here
is
with
things
like
math.
If
we
obsolete
all
of
the
members,
you'll
get
obsoletion
warnings
if
you
split
compile
between
net
standard
and
a
net
core,
that
has
them,
and
you
want
to
just
write
the
code
and
not
have
to
split
it.
E
E
E
A
I
mean
in
a
sense,
there's
also
nothing
wrong
with
those
methods
right.
It
just
means
that
you
know
it's
just
not
the
place
to
look
for
them
moving
forward,
but
right
they
keep
working
the
same
way.
They
do
that
you
don't
get
better
performance.
It's
just
you
know,
there's
no
reason
why
you
should
switch
it's
almost
more
like
a
code
style
thing
at
this
point.
Do
you
want
to
see
map
dot
bloody
when
you
see
in
doppler
right
or
float
doppler.
B
E
Right
so
I
know
it's
a
little
theoretical,
because
we
don't
have
the
things
yet
but
to
right
for
clamp.
You
said
we
don't
want
to
move
clamp
down
yet
I'm
guessing
that.
What
we
would
really
want
to
do
is
if
we
added
clamp
as
a
dim
on
I
comparable.
E
B
E
B
E
B
A
A
A
A
Then
I
would
say,
let's
just
post,
that
into
the
I
guess
this
is
more
like
for
me
following
up,
but
let's
post
this
as
the
summary
then,
which
I
guess
would
go
where
would
they
go?
A
E
E
E
E
B
E
B
B
E
B
B
Okay,
so
so
this
one
and
the
reason
I
think
it's
so
simple-
is
it's
just
another
one
of
the?
Let's
make
sure
we
have
in
in
innuent
as
first-class
citizens
in
bit
operations
and
then,
in
extension,
for
generic
math
as
we're
going
to
be
exposing
some
of
these
operations
on
the
primitive
types
we
have
corresponding
for
int
and
long
or
you
went
and
you
long,
but
we
don't
have
them
for
in
and
inuit.
G
A
B
A
Ordinary
api
review
and
then
yeah
give
the
preview
bits
a
try
if
you
haven't
yet
not
necessarily
related
to
this
but
related
to
everything
else.
We
have
shipped
in.6
so
far,
so
alright,
everyone.