►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
We
won't
finish
it
all
today
because
it
includes
a
very
long
thing,
but
we're
going
to
try
it
with
some
short
things
or
emo
at
least,
is
going
to
watch
a
clock
and
tell
us
when
we've
exceeded
the
amount
of
time
we're
willing
to
spend
on
these
short
things.
B
Okay,
I
can
speak
to
this
one.
So
when
we're
building
up
like
the
service
collection
is
the
thing
that
holds
all
the
dependency
injection
service
descriptors.
B
When
we're
building
this
up,
we
have
to
loop
over
each
one.
We
have
to
loop
over
the
collection
each
time,
we're
adding
and
building
things,
because
we
have
to
make
sure
that
it
hasn't
already
been
added
to
the
collection,
and
so
it
basically
becomes
like
a
big
old
n
squared
operation,
and
so
some
of
these
apis
is
to
optimize
it.
So
we
can
just
because
the
the
internal
collection
we
don't
have
to
loop
over
it
each
time
internally.
B
So
if
we
had
an
api
for
triad,
service,
descriptor
or
triad
enumerable
or
try
replace
the
collection
can
optimize
this
and
not
have
to
make
one
the
virtual
calls
to
the
to
the
interface
and
then
two
have
to
loop
over
the
the
whole
collection.
Each
time
we're
adding
things
all
right,
and
so
a
thing
that
isn't
shown
on
here
is
that
service
collection
implements.
I
service
collection,
because
everything
in
extensions
has
an
interface,
yeah
and
so
part
of
this
proposal,
and
then
service
collection
is
not
in
the
abstractions
package.
B
B
Is
this?
I
service
collection,
a
service
collection
and,
if
so,
it'll
call
directly
into
these
optimized
methods,
if
not
it'll
just
keep
doing
what
it's
doing
today.
C
D
A
A
C
There's
one
more
thing:
since
there
it
is
an
interface.
There
is
an
implementation.
There
are
a
couple
implementations,
not
as
many
as
it
isn't
widespread
widely
spread
implemented.
But
if
you
scroll
to
the
bottom
you'll
see,
there
are
a
couple
of
third-party.
C
Well
there's
one
third-party
container
that
actually
implements
the
interface
on
their
container
builder,
so
ben
suggested
we
do
a
dim
for
net
core
3
and
up
instead
of
doing
a
instead
of
putting
on
the
concrete
type
we
can
put
it
on
both
but
yeah.
This.
E
So
what
is
the
interface
changes?
Because
you
only
had
a
an
actual
type
of
members
right.
C
G
C
C
A
A
F
I
mean
I
have
to
admit
that
I
kind
of
feel
like
eric,
like.
I
don't
think
it
buys
us
that
much.
I
would
probably
go
down
the
other
path
that
would
just
introduce
them
as
virtual
in
the
service
collection.
If
we
really
wanted
to
implement
their
party
or
if
you
want
to
support
third
party,
is
doing
something
and
then
I
would
just
say
if
you
want
the
better
proof,
you
have
to
change
the
base
type
you're
using.
B
Yeah
I
mean
the
other
option
is
just
introduce
an
abstract
based
class
in
between
right,
like
introduce
a
service
collection
base.
I
don't
I'm
sure
we
don't
like
the
base
suffix
but
introduce
the
surface
collection
base.
Our
service
collection
derives
from
that
that
has
the
triad,
tri-innumerable,
tribe,
replace,
etc.
C
C
Back,
I
prefer
the
concrete
type
the
interface
thing
is
is
interesting.
It
has
a
few
warts
triad
actually
doesn't
return
a
bool
on
the
extension
method.
I'm
actually
not
sure
it
would
just
bind
the
new
one.
I'm
actually
not
sure
what
would
happen
if
you
have
an
interface
definition
that
has
a
different
signature
to
the
one.
C
D
C
So
so
imagine
how
to
try
that
max
the
signature
of
my
interface
method,
but
had
a
different
return
type
like
what
does
that
even
do
in
the
compiler?
Would
it
be.
F
F
F
A
F
E
F
C
F
Yeah
yeah
I
mean
I
I
mean
yeah,
it
depends
on
what
you
guys
think,
like
my
personal
opinion
is,
I
would
just
do
them
on
the
service
collection
for
now
like.
I
would
not
touch
the
interface
at
all
and
if
somebody
is
asking
for
that,
they
would
say
well,
why
can't
you
extend
the
other
one
and
then
we
can
have
the
conversation
of
making
it
virtual.
Maybe.
B
C
C
A
F
F
A
F
I
mean
you
could
do
what
what
ben
is
suggesting
right,
which
is
you
just
now
have
a
a
net
core
f31
output
that
has
the
dim
and
the
nsn2
doesn't
have
it
right,
but
like
at
that
point,
if
most
consumers
are
not
standard
two,
then
right
so
that's
the
I
mean
it
would
only
buy
people
something
that
actually
are
on
network
31
or
higher,
which
I
don't
know
like.
If
you
have
a
third-party
implementation
chances
are
it's
a
library
and
chances
are
targets
that
standard
too.
So
how.
G
Are
you
affecting
startup
performance
in
core
or
not
standard
apps,
like
full
framework,
apps
core?
We
needed
core,
we
don't
care
about
full
framework
that
much
so.
If
so,
the
fact
that
you
just
said
we
don't
care
about
full
framework.
That
much
makes
me
think
that
it
would
actually
be
okay
to
have
full
framework.
Have
the
older,
slower,
behavior
and
just
say
you
know
what
core
gets.
The
new
hotness
end
of
story.
C
F
F
I
mean
yeah,
I
mean
it
kind
of
depends
on.
I
mean
at
that
point.
I
think
you're
talking
about
slightly
different
feature,
though
right
right
now,
you're
just
talking
about
optimization,
I
think
what
you're
asking
for
is:
how
can
we
make
it
so
that
people
can
derive
from
some
abstract
base
types
to
have
their
own
container
and
different
behavior.
B
F
C
A
If
you
were
adding
right
now,
the
service
collection
base,
which
is
probably
the
best
name
for
something
to
add
after
the
fact
that
then
that
would
go
in
abstractions
and
you
would
leave
service
collection
where
it
is
so
it
actually
does
affect
whether
or
not
you
need
you
feel
like.
You
need
to
move
a
type
right
now.
B
D
C
B
F
F
I
mean
it
depends
on
what
scenario
you're
trying
to
solve
right.
I
think
that
I
mean
you
might
be
right
that
people
only
ship
one
of
them,
but
they
can
see
they
seem
to
be
like
different
problem
spaces
right.
One
of
them
is
really
about
optimizing
lookups
and
the
other
one
is
really
about
making
it
more
flexible
for
potential
different
implementation
of
the
service
collection
right,
and
so
they
they.
You
know,
they're,
not
the
same
solution
of
problem
space
rights
right.
A
A
C
A
Okay,
okay
and
you
can
go
so
far
as
to
make
them
sealed
overrides
if
you
want,
since
they're,
currently
non-virtual
methods
on
an
unsealed
class.
B
B
F
Pushback
I
mean
I
would
generally
say
like
I.
I
don't
see
anything
wrong
with
that.
It's
just
that
unless
you
really
design
for
extensibility
and
customization,
I'm
not
convinced
that
just
adding
a
base
type
of
some
virtuals
will
solve
the
problem,
because
it's
very
rarely
the
case
that
you
can
just
make
things
virtual
and
then
say:
yeah
people
can
derive
from
it
and
overwrite
it,
because
it's
really
hard
it
depends
on
how
these
methods
work
and
what.
F
B
B
F
F
Right,
I
mean,
I
think
the
problem
in
practice
is
so,
let's
say
you
add
a
new
abstract
type
right,
so
you
have
one
one
shot
to
add
abstracts
to
it.
Next
time
you
want
to
add
a
method
you
can
only
edit
as
a
virtual
right
and
so
that
so
in
that
sense,
the
proof
is
in
the
pudding
in
the
sense
that
the
next
time
you
want
to
add
something
to
it.
Can
we
actually
express
them
as
virtual?
It's
not
as
abstract
right.
F
A
A
I
think
the
the
statement
here
is
you're,
saying
adding
the
abstract
class
now
helps
solve
the
problem
for
the
next
time,
but
unless
we
actually
have
an
idea
of
what
the
next
time
thing
might
be,
we
wouldn't
be
able
to
express
it
like
if
it's
the
array
versus
span
problem
right,
you're
like
oh,
we
have
a
collection,
it
works
on
arrays
and
enumerables
and
we're
great,
and
then
we
added
this
new
thing
called
span.
It's
like
well,
we
can
in
some
cases
we
can
make
up
how
this
would
have
worked.
A
A
Yeah,
and
for
this
particular
thing,
if
you
did
it,
you
could
do
it
without
moving
service
collection,
because
your
your
is
test
to
call
the
the
boolean
triad
instead
of
the
void
triad
would
be
from
the
layer
same
layer
that
the
interface
is
already
in.
C
A
Of
a
a
direct
call.
B
B
H
C
A
Yeah
I
mean
the
the
most
significant
thing
it
breaks
is
run
time.
You
call
get
type
full
name
that
will
give
a
different
answer
now
and
that
may,
depending
on
how
you're
doing
type
matching
that
may
break
things,
the
runtime
thing
will
look
it
up,
but
we
do
have
to
for,
for
the
rest
of
time,
carry
the
type
forward
and
the
old
assembly
so.
A
A
But
if
he,
cracked,
the
library
in
two
and
this
became
the
new
library
depended
on
this
one,
that's
moving
it
out,
which
will
break
assembly.
F
A
A
I
think
the
new
type
got
yanked
eric
said
he
didn't
care
to
add
the
new
base
class.
Once
david
wants
to
move
the
assembly
anyway,.
A
All
right,
emo,
technically
we're
already
past
the
time
for
the
the
two
issues.
I
assume
we're
just
gonna
steal
time
from
tanner.
I
Yeah,
I
think
we
probably
should
like
that
we
should
approve
the
the
notes
one
because
that's
hopefully
just
we
all
know
it
and
say
yes,
okay,
so
that
should.
F
To
yeah
I
mean
just
to
give
some
context,
so
basically
somebody
wrote
a
vb
sample
where
they're
for
each
over
a
bunch
of
stuff
and
they
named
the
loop
variable,
node
and
apparently
vb
has
this
funky
behavior,
where,
if
you
use
type
inference
there,
where
you
don't
explicitly
declared
it
that
will
declared
unless
the
compiler
is
able
to
resolve
it
against
something
else.
And
so
apparently,
because
we
have
a
node
namespace,
the
local
loop
variable
node
is
no
longer
declared.
F
Instead,
it
just
binds
to
the
namespace
which
of
course
compiles,
and
so
that's
some
weirdness
in
vb
and
normally.
I
would
not
feel
super
obligated
to
honor
that.
But
the
problem
is
it's
a
lot
of
vb
code,
of
course
that
uses
the
term
node.
So
it's
a
lot
of
code
that
we
broke
with
that
and
then
secondly,
like
we
just
generally
don't
name
namespace
names
with
singular
names
if
they
likely
result
clash
with
class
names,
because
that's
almost
always
a
problem,
so
we
should
have
just
named
it.
Something
else
I
mean
notes
is
fine.
A
I
F
A
A
A
It's
the
new
new
new
language,
feature
c
sharp
10.
F
H
Okay,
so
c
sharp
is
going
to
be
adding
static,
abstracts
and
interfaces
in
a
future
version
of
net.
This
will
not
be
net
six,
but
we
are
planning
on
previewing
it
in
dot
net.
Six.
H
The
one
of
the
main
uses
for
this
on
the
library
side
is
that
it
will
enable
you
to
write
generic
math.
Finally,
so
you'll
be
able
to
do
things
like
t,
plus
t
or
you've
never
been
able
to
do
that
before.
H
A
That
work,
okay,
good,
it's
a
link
from
chat
yeah,
it's
gonna
say
that
would
require
that
I
figure
out
a
way
to
share
the
chat
that
is
conducive
to
being
on
the
internet.
Okay,.
H
Likewise,
let's
say
that
you
wanted
to
start
calculating
standard
deviation
you
today,
you
might
be
able
to
do
something
like
innumerable
average,
innumerable
sum,
but
that's
not
so
trivial
to,
and
that
allows
you
to
implement
it
over
a
specific
type
like
in.
But
if
you
want
to
support
all
types,
that's
not
really
possible
today,
without
doing
all
those
type
of
checks
and
then
you're
limited
to
the
concrete
types
you
actually
supported
with
the
interfaces
here,
we'll
be
able
to
now
define
a
git
standard
deviation
over
t.
H
Where
t
is
I
number
and
scroll
down
a
little
bit
more
and
so
now
you
can
actually
implement
a
method.
Similarly,
to
this,
where
you
effectively
take
your
t,
you
convert
it
to
double
and
compute
the
sum,
and
so
now
it's
generically
supporting
any
t.
That's
a
number
and
not
just
a
specific
subset
of
t.
A
H
So
complex
is
not
a
number
type
complex
and
we'll
get
to
this
a
little
bit
later,
but
number
is
more
a
a
scalar
number,
rather
than
a
any
number.
Once
you
start
getting
into
composed
types
like
complex,
which
is
actually
two
parts
that
represent
a
number,
you
can't
represent
them
via
the
same
interface
and
so
complex
would
have
to
be
a
separate.
A
Okay,
because
you
know
complex
numbers
are
addable,
subtractable,
multipliable
and
dividable.
They
just
don't
average
to
a
double
all
right,
and
you
know
if
you
make
it
feels
like.
If
you
made
you
know,
big
decimal,
that,
like
double,
would
be
a
loss
of
precision
that
you.
H
A
H
And
so
a
lot
of
the
design
here
has
been
influenced
by
swift,
which
is
the
probably
the
closest
object,
oriented
language.
That's
exposed
similar
things
they
don't
use
traits,
they
use
protocols
which
are
effectively
interfaces,
at
least
for
the
purposes
of
this
discussion,
and
so
they
are
a
a
kind
of
close
parity
to
what
c
sharp
somewhat
needs
to
do.
H
There's
also
influence
from
rust
and
haskell
and
other
languages,
but
they
more,
they
more
often
use
traits
and
duct
typing,
and
so,
while
there
is
some
influence
from
them,
they
don't
necessarily
translate
well
to
what
we're
able
to
do
here
with
static
abstracts
and
interfaces.
H
But
it
is
still
a
concern
and
it's
something
that
we're
going
to
that
may
impact
exactly
what
we
expose
when
we
do
ship
this.
What
I've
proposed
here
is
what
I
believe
to
be
the
actual
minimal
and
correct
product,
which
is
all
the
interfaces
that
allow
you
to
be
extensible
for
other
libraries
to
define
their
own.
H
And
so
then
we
get
into
the
actual
interfaces
here
and
the
first
one
doesn't
necessarily
apply
to
numbers
itself.
But
it's
it's
effectively
the
the
sibling
to
I
formattable.
It's
I
parsible.
It
takes
a
t
and
it
just
exposes
parse
and
tripars,
which
return
t
self
and
take
string.
H
H
No
that
so
they
accept
the
cycle.
The
cycle
will
also
be
specially
recognized
in
newer
compilers
to
allow
operators
where
the
type
is
not.
I
parsable,
but
t
self.
Instead,.
A
H
H
H
And
for
iparcible
in
particular,
these
do
explicitly
do
not
expose
the
variants
that
take
number
style,
because
the
number
styles
doesn't
apply
to
all
parcel
types.
It
only
applies
to
number
of
particle
types.
H
H
Yes,
this
is
actual
proposal
and
a
lot
of
these
are
still
rough
draft,
so
input
on
names
and
things
where
appropriate
is
appreciated,
but
there
is
a
lot
to
get
through.
So
we
should
keep
that
in
mind.
While
we
try
to
go
through
it
after
the
one
thing
that
stephen
brought
up
is
we
might
given
that
this
is
a
first
time
thing
we
might
just
be
able
to
expose
ispan,
parsible
and
say
everyone
must
expose
span
variants,
so
we
could
cut
one
interface
out
that
way.
H
These
ones
could
just
be
named.
I
equatable,
given
that
it
takes
two
generic
types
and
then
it
wouldn't
conflict
with
the
existing.
I
equatable
we
can't
and
we
do
wanted
to
expose
both
t
self
and
the
other,
because
there
are
types
like
complex,
where
t
other
isn't
the
same
as
t
self,
it
might
be,
for
example,
the
scalar
type
that's
represented
under
the
covers,
which
is
done
for
efficiency
purposes,
because
you
may
not
want
to
allocate
such
as
in
complex.
H
Principles,
we
likewise
have
I
comparable
operators.
It
could
likewise
just
be
called,
I
comparable
t
self
to
other
and
it
wouldn't
conflict.
H
H
H
Yeah,
I
I
used
lhs,
rhs
and
left
and
right
a
bit
interchangeably
between
here.
I
I
assume
that
they'll
all
be
left
and
right
in
in
practice,
because
that's
our
actual
names.
G
Does
this
imply
that,
if,
if
I
wanted
to
have
t
other
on
the
left
and
to
yourself
on
the
right,
I'd
actually
get
a
compiler
error.
H
H
It
adds
a
lot
of
complexity,
it
is
not
always
guaranteed,
and
so
the
recommendation
is
just
yeah,
always
put
your
tea
other
type.
On
the
I
mean
right
hand,
side,
yeah,.
A
That's
what
we
said
for
all
of
these
math
like
operators
is
don't
do
this
just
use
a
let
a
implicit
conversion
or
something
be
what
what
ends
up
making
this
function.
But
if
it's
actually
important
for
things
like
complex
to
occasionally
do
this
in
a
way
that
needs
to
be
expressible
with
generic,
then.
H
It's
also
important
for
like
matrix
when
you
get
into
like
multiplication
because
matrix
times,
scalar
is
a
valid
operation,
and
that
is.
A
A
H
Don't
need
anything
that
ends
up
being
just
I
comparable,
and
I
equatable
that
takes
one
and
you
just
call
the
equals
and
compare
two
methods.
H
There
are
types
like
complex
which
explicitly
have
both
I
equatable
complex,
complex
and
I
equatable
complex
double
because
it's
an
optimization
and
a
fairly
critical
one
in
more
complex
numeric
code
being
able
to
cut
out
the
imaginary
part
or
when
you're
doing,
for
example,
scalars
vectors
and
tensors
being
able
to
cut
out
many
dimensions
in
the
comparison.
A
A
Fair
enough,
I
think
that
having
I
equatable
of
with
erity
one
and
I
equatable
with
arity
two
being
for
different
concepts,
feels
weird
so
yeah.
That's
why
my
suggestion.
G
G
H
Personally,
I
think
I
equatable
operators
read
significantly
better
than
I
operator
equatable,
particularly
as
you
look
across
all
operators
and
there
there
are
types
like,
for
example,
I
remainder
which
there
isn't
an
able
name
available
for
it.
I.
H
H
Then
we
get
to
I
additive
identity.
In
particular,
I
was.
I
was
flip-flopping
on
whether
we
needed
the
concept
of
I
additive
identity
here,
because
it
it
adds
another
interface,
and
I
was
figuring
that
it
would
be
good
to
just
expose
the
the
identity
opera,
the
identity
concept
on
I
number
itself,
but
once
you
start
looking
at
vectors
and
other
types,
including
things
like
date,
time
and
time
span,
which
have
logical
identities
for
their
operations,
it
ended
up
making
the
most
sense
for
extensibility
and
correctness.
H
Because
not
every
so
so,
if
you
put
it
on
iadible
itself,
you'd
have
to
consider
whether
t
self
t
result
is
correct
and
whether
or
not
t
result
is
the
correct.
H
So,
for
example,
it
would
end
if
you
exposed
it
on.
I
addable.
The
only
logical
thing
here
is
actually
returning
t
other,
but
that's
not
always
correct.
There
are
places
where
you
might
support
multiplication
where
t
other
isn't
an
ident
doesn't
have
a
correct
identity,
but.
H
G
A
E
F
H
Because
this
is
a
static,
abstract
and
static,
abstracts
must
be
able
to
be
constrained,
and
so
fundamentally
you
have
to
have
a
t
cell
that
it's
constrained
onto.
H
H
F
A
H
Once
you
once
you
start
looking
at
all.net
code,
everything
that
can
expose
operators
etc,
it
makes
sense
to
have
them
logically
separate
concepts,
and
that's
the
real
reason
why
every
operator
here,
what
most
operators
here
are
really
their
own
thing,
because
you
have
many
types:
where
plus
exists,
but
subtraction
doesn't
you
might
have
cases
where
multiplication
is
valid,
but
division
is
not
where
division
is
valid,
but
remainder
is
not
yeah.
This
is
new.
H
H
They
are
being
they're
going
to
be
taken
to
ldm
by
mads
alexei,
and
so
it's
very
likely
they
will
come
in
checked
in
particular,
is
considered
a
core
concept
which
is
currently
being
tracked
as
if
we
don't
have
this
in
d1,
we
will
effectively
never
be
able
to
add
it
in
the
future
and
it
will
likely
significantly
hurt
what
we
do
ship.
H
So
in
particular,
one
of
the
proposals
is
for
checked
operators,
and
so
this
would
define
a
new
operator
op
edition,
checked
and
if
you
are
in
a
check
context,
either
via
the
compiler
switch
check,
plus
or
via
an
explicit,
you
know,
checked
context
in
c
sharp.
This
version
of
the
operator
would
be
preferred.
H
Some
types
like
big
integer
would
define
this
as
doing
the
exact
same
thing
as
the
unchecked
operator,
but
other
types
like
in
32
or
our
own
int,
128
type,
which
we
might
expose
in
the
future
in
which
we
would
be
able
to
expose.
Now
that
this
concept
exists,
they
would
have
different
behavior
one
overflowing
one,
not.
A
H
And
it
would
at
least
for
operators
here
the
default.
If
you
put
it
here,
then
the
default
context
of
the
method
body
would
become
checked.
H
And
then
I
incrementable
and
decrementable
likewise
there's
a
comment
here
explaining
this
doesn't
inherit
edible
because
t
other
isn't
necessarily
well
defined,
regardless
of
framework
design
guidelines.
There
are
languages
which
use
things
like
plus
plus
to
represent,
for
example,
moving
to
the
next
element
in
in
enumeration
c
plus
plus,
is
one
of
them,
for
example,
and
so
incremental
is
its
own
concept.
That
is
simply
t
self
operator
t
self.
H
G
Do
we
need
different
methods
for
prefix
and
postfix,
or
is
that
out
of
scope.
H
That
is
considered
out
of
scope.
Okay,.
A
G
H
Yes
c
c,
plus
plus
does,
but
I
l,
but
I
l
doesn't
actually
define
it
and
the
way
c
sharp
does
it
handles
it.
Is
it
just
varies?
The
il
admits
to
do
the
pre
versus
post
fix.
H
H
G
Should
we
consider
maybe
exposing
divrem
as
a
first
class
citizen
here.
H
So
divrem
is
a
concept
that
I've
considered
elsewhere.
Min
max
is
another
one
that
was
suggested,
for
example,
min
and
max
could
just
go
on.
I
comparable
theoretically.
H
H
A
H
So
so
dims
are
going
to
be
required
for
effectively
v2
of
whatever
we
ship.
It
is
still
be
to
to
be
determined
if
they
will
be
in
v1
they're
required
for
v2.
That
way,
we
can
actually
ship
changes
to.
I
number,
for
example,
without
having
to
ship
an
I
number
two
or
an
I
number
three,
but
whether
or
not
they'll
be
in
v1
is
still
effectively
to
be
determined.
H
H
Yeah
and
the
the
the
only
real
benefit
here
is
there's
some
methods
which
we
could
simplify
the
implementation
of
if
dims
are
in
v1.
A
The
men
you
know
doing
you
know
the
max
of
two
and
men
of
two
on
I
comparable.
It's
like
well
I'll,
just
call
the
existing
operator.
You
told
me
to
define,
but
if
you
can
do
better
than
that
for
some
reason
then
overwrite.
H
G
G
A
G
G
H
There
are
other
core
concepts
here,
such
as
eye
floating
point
that
allow
you
to
do
an
appropriate
check
and
do
the
right
thing
for
those
types.
So
there
are
correct
things
we
can
do
here,
but
I,
some
of
those
are,
I
think,
out
of
scope
for
the
discussion
here.
H
Yep,
okay,
true
eye
negatable,
is
the
next
one.
There's
a
question
of
whether
the
unary
plus
operator
should
be
its
own
or
if
we
should
even
expose
unary
plus
at
all,
unary
plus
is
for
all
for
most
purposes
always
going
to
be
return.
Self
return
just
return
the
identity,
it's
very
good
for
helping
with
maintainability
of
your
own
code,
because
you're
able
to
align
columns
with
plus
versus
minus
and
more
more
easily
see
that
this.
This
literal
is
intended
to
be
positive.
H
I
didn't
have
a
strong
preference
here.
I
just
put
it
on
I
negatable,
because
that's
where
the
parity
exists-
and
I
was
also
wasn't
able
to
come
up
with
a
good
name
here,.
F
F
H
H
H
G
H
G
F
I
would
actually
be
in
favor
of
having
a
unified
convention
that
basically
has
the
name
operator
somewhere
in
it
because,
as
you
said
earlier,
like
the
bull
names
become
weird
and
it
seems
like
right
now
we
have
this
weird
spit,
but
some
are
and
some
aren't.
I
would
just
pick
you
know,
a
convention
that
we
can
sustain
for
all
of
them.
H
Yeah-
and
I
I
think
the
most,
in
my
opinion,
the
simplest
thing
that
follows
that
that
also
reads
well
is,
I
think
I
edition
operators
I
right
basically
using
the
ekma
name
or
common
subset
name
and
then
operators
at
the
end
yeah.
F
F
Yeah
yeah,
it
seems
like
a
desirable
thing
for
for
an
antenna
like
did
you
base
so
bit
wise,
like
they
are
not
required
by
the
compiler
to
be
co-implemented
right.
H
Yes,
yes,
but
just
like
with
just
like,
with
less
than
versus
less
than
or
equals,
I've
not
been
able
to
think
of
any
scenario
where
you
only
want
one,
and
so
I
strongly
believe
at
least
for
bitwise,
that
and
or
and
exor
should
be
together.
I'm
not
necessarily
convinced
on
the
compliment
operator
that
one
maybe
should
be.
I
you
know,
complement
operators
or
something.
E
F
E
H
F
H
Yeah,
that's
what
what's
a
mistake
once
we
have
a
functioning
runtime
prototype
I'll,
be
doing
community
outreach
to
help
validate
that
these
are
correct
and
work
for
first
for
for
any
third
party
for
any
interested
third
parties.
There's
some
key
ones
that
we're
looking
at
and
so
we'll
be
doing
that
to
help
bet
that
this
is
correct,
and
so
this
represents
what
I
believe
to
be
currently
correct.
But
that
of
course
may
change
between
when
we
actually
ship
b1.
H
Will
implicitly
do
it
as
x,
equals
x,
plus
y,
and
it
will
double
evaluate
x,
okay,.
A
H
Yep
and
c
sharp
will
not
respect
them
so
for
most
and
f
sharp
doesn't
allow
them
either
so
for
most
purposes
outside
of
like
c
plus
plus
cli.
You
won't
encounter
them.
You
won't
be
able
to
define
them,
and
it's
not
something
that
I
think
needs
to
be
pushed
through
c
sharp
ldm
to
allow,
unlike
people,
to
check
operators.
G
I
guess
one
one
piece
of
feedback
I
have
here
on
the
bitwise
operators,
too,
is
like
I'm,
I'm
really
struggling
to
find
a
scenario
where
t
self
and
the
other
would
be
different.
Given
that
we're
talking
about
binary
operators,
meaning
you
need
to
self
and
the
other
to
have
equivalent
bit
wise
representation.
H
So
there
are
cases
where
those
are
those
exist
for
vector.
I
think
it
was
a
mistake,
exposing
them-
and
I
wasn't
here
when
we
you
know
I
wasn't
even
at
microsoft
when
we
actually
reviewed
those
so.
H
Yeah,
okay,
that
it
actually
happens
for
float
in
it,
but
for
for
all
of
these,
regardless
of
framework
design
guideline
I
I
went
with
what
does
c
sharp
allow
here
and
if
it
allows
t
self
to
other
and
t
results
differ,
then
the
interface
will
allow
it
to
support
other
languages
to
support
types
that
may
differ
and
to
avoid
the
scenario
of
we
ship
t
self
t
result
or
you
know,
t
self,
just
t
self,
and
then
in
v2
we
go.
Oh
no.
G
G
H
Yeah,
okay,
then
we
get
to
I
shiftable.
Now,
notably,
this
has
two
c
language
relaxations
or
changes.
One.
It's
going
to
lift
the
restriction
that
the
right-hand
side
must
be
int.
It
is
now
allowed
to
be
t
other
in
practice.
This
will
end
up
being
the
same
as
t
cell
and
it
will
still
follow
the
same
restriction.
So
you
know
long
shifted
by
long
is
well
defined,
provided
that
long
is
within
0
to
63
and
c
sharp
will
for
long
right,
shifted
by
long
still
mask
it
as
appropriate.
H
But
it's
convenient
for
cases
where
you're
doing
things
like
trailing
zero
count
or
leading
zero
count.
Where
the
result
is
t
self
and
you
don't
want
to
have
to
cast
int.
A
I
was
gonna,
say
or.
H
G
Sure,
okay,
so
two
follow-up
questions
then
first
do
we
need
an
explicit
sign
shift
operator
and
second,
do
we
need
an
explicit
barrel
shift
operator.
H
Yeah
both
of
those
are
out
of
scope
so
for
sine
shift.
We
just
like
with
the
check
versus
unchecked.
We
believe
that
the
current
right
shift
will
it
types
is
already
a
signed
right
shift
and
for
unsigned
types
it
doesn't
matter
and
no
one.
No
language
actually
defines
a
a
signed
right
shift
operator
anyways,
and
so
we
think
that
just
right
shift
and
in
an
explicit
unsigned
right
shift
will
be
sufficient
here.
A
Well,
but
if
this,
so,
if
I
shift
operators
is
defining
this
and
we
say
that
it
should
represent
the
unsigned
right
shift
like
this
means
we're
going
to
have
to
define
this
on
int
and
then
we're
just
going
to
go
against
convention.
And
it's
going
to
be
the
signed
right
shift.
H
H
H
Right
and
today
in
c
sharp,
if
you,
if
you,
if
you
have
an
int
and
you
want
to
do
unsigned
right
shift,
you
end
up
having
to
convert
to
uint,
do
the
shift
and
then
convert
back
and
that's
possible
when
you,
when
you
know
the
type
definitively,
because
you
know
the
corresponding
unsigned
type.
But
when
you
get
something
like
big
integer
or
an
arbitrary
t,
you
don't
know
if
there
even
is
a
corresponding
unsigned
type
to
convert
to
and
so
short
of,
exposing
a
you
know,
unsigned
right
shift
named
method.
H
This
is
the
proposal
to
cover
that
scenario,
and
it
will
also
simplify
existing
code
using
primitives.
That's
not
even
using
statics
and
interfaces,
because
you'll
no.
F
H
G
H
We
then
get
to
min
max
value.
This
isn't
necessarily
the
best
best
name,
but
it's
the
name
that
describes
what
it
represents,
which
is
that
the
type
has
a
minimum
and
maximum
value.
It
is
a.
It
is
not
a
concept
on,
like
I
number,
because
things
like
big
integer
do
not
have
a
min
and
max
value,
but
also
things
like
date.
Time
do
have
a
mid
and
max
min
and
max
value
and
are
not
themselves
numbers.
Oh.
A
A
H
A
I
mean
if
you
had
unsigned
big
integer,
that
you
were
willing
to.
Let
it
go
until
the
gc
ran
out
of
memory.
Then
it
would
have
a
zero
min
value
and
wouldn't
have
a
concept
of
a
maximum
value.
A
Yes,
it
does,
it
seems
a
little
odd
but
yeah.
A
H
A
Yeah,
so
we
now
have
the
min
max
value
and
the
additive
identity,
I
think,
which
are
the
two
things
that
are
not
operators.
H
And
I
multiplicative
identity.
A
Right
so
then
the
so
we
came
up
with
an
I
purpose.
Operators
for
the
operators,
like.
A
Yes
right
so
is
this:
you
know
yeah,
so
it
really
it's
it's.
What
do
we
think
we
want
to
call
these
things?
Do
we
have
a
like
I
thingy
value
holder
is
the
thing
that
popped
into
my
head
first,
but
I
don't
really
like
it,
but
it's
a
start
of
a
discussion.
H
Yeah
and
I
didn't
really
have
good
names
for
them,
so
I
kind
of
just
went
with:
what's
the
property
they're
exposing
and
say
it's,
I
that.
H
Right
and
for
something
like
min
max
value,
it
will
have
to
be
explicitly
implemented
because
constance
with
the
same
names
today.
F
Yeah,
I
care
less
about
that,
it's
more
like!
If
you,
if
you
look
at
the
definition
of
in
32
right,
you
should
make
sure
that
when
somebody
who's
starting
to
learn
c
sharp
looks
at
those
names,
their
eyes
are
not
rolling
to
the
back
of
their
heads.
So
the
names
at
least
somewhat
make
sense
to
people
right,
and
they
know
oh
yeah,
that
just
makes
it
plausible
and
minusable
and
whatever
right
so
like.
We
should
pick
names
that
are
somewhat
reasonable
and.
H
C
K
F
A
H
G
Were
there
we
didn't
go
over
conversion
operators
I
take
are
those
like
somewhere
else
in
the
proposal.
H
So
conversions
are
this
concept
that
are
briefly
touched
on
below,
but
they
are
very
hard
to
define
here
because
they
are
very
kind
of
exponential,
particularly
with
primitive
types.
G
Yeah
because
I
I
know
that
the
the
canonical
way
to
do
this
is
to
just
implement
I
convertible
and
then
well
now
you
have
you
know
two
whatever
apis,
but
that's
like
you
said
it
is
a
lot
of
work
and
it
doesn't
allow
for
more
power
scenarios
like
I
want
an
unsigned
version
of
whatever
integer
type.
I
happen
to
be
using
yeah
stuff
like
that
and
at
that
point
we're
getting
into
something
akin
to
like
c
plus
plus
type
traits,
which
I
think
you
already
said
was
out
of
scope,
but
right.
H
Yeah
and,
and
that
that's
some
of
the
concept
that
I've
got
annotations
on
further
down,
so
the
the
group
we've
just
finished
is
effectively
the
core
interfaces
they're
the
interfaces
that
allow
everyone
else
to
build
upon
them.
The
expectation
is
that
most
users,
probably
won't
actually
use
them
unless
they're
defining
their
own
types.
H
Sorry,
unless
they're
defining
their
own
interface
types
that
build
on
top
of
them,
and
so
once
we
start
looking
at,
like,
I
number
we'll
start
seeing
things
like
here's,
how
you
create
a
number
from
other
numbers
and
conversions
and
things
like
that,
and
it
may
be
that
we
do
want
something
like
I
convertible
or
I
convertible
2,
and
I
convertible
from,
but
I've
not
exactly
finished
the
prep
work
on
those
in
investigatory
work.
H
K
H
There
was
some
discussion
that
I
had
on
discord
and
there's.
There's
suggestions
like
I
fixed
range
value
and
variants
like
that,
and
I
think
min
max
value
is
the
it's
not
the
best
name,
but
it's
short
descriptive
and
covers
what's
exposed.
A
Okay,
I
mean
like
this
is
just
the
where
it
is
a
new
kind
of
interface.
Our
our
existing
instance
interfaces.
We
like
the
bubbles,
we
said
for
the
operators,
we
want
them
to
end
in
operators
and
then
this
one
is
I'm
exposing
a
static
property,
and
so
is
it
that
we
think
that
it's
I,
what
are
you
doing
value
is
the
the
formula
we
want
so
because
additive
identity
was
just
called
additive,
identity
right.
A
G
Regarding
the
user,
experience
so
say
we're
the
the
current
plan
is
to
ship
these
in
six
in
a
preview
state
correct,
but
we
still
need.
We
still
need
types
like
in
32
to
sub
to
implement
these
interfaces.
Correct
is
the
idea
that,
if
I
have
not
opted
in
to
preview
language
and
runtime
features
like
I
don't
even
see
these
interfaces,
they
don't
show
up
in
intellisense
and
so
on.
H
Yeah
and
we're
going
to
have
to
do
some
special
work
with
once
we
get
further
down
to
like
I
floating
point
single
will
likely
expose
a
new,
a
cause
method,
in
which
case
due
to
existing,
due
to
the
difference
between
what's
exposed
through
the
interface
and
what
is
already
exposed
on
the
type.
We
will
have
to
explicitly
also
annotate
those
methods
as
preview,
because
they
won't
go
through
the
interface
yeah.
F
Okay
but
but
but
to
answer
your
question
I
mean
like
the
general
idea
with
preview
features,
is
that
you
know
types
or
members
might
be
marked
with
preview,
but
there
is
no
plan
to
restrict
intellisense.
Basically
is
you
are
always
able
to
see
their
preview
features
and
then,
when
you
start
using
them,
then
you
might
get
a
warning
because
you
haven't
opted
into
them,
but
there's
no
attempt
to
hide
them
because
well
we
want
people
to
discover
them
and
play.
G
With
them
right,
I
I
see
I,
I
guess.
The
thing
that
was
making
me
nervous
here
is
that
we're
talking
about
changing
like
fundamental
exchange
types
in
the
run
time.
Yes,
for
for
the
overwhelming
majority
of
people
who
will
not
have
enabled
preview
features
and
won't
care
about
them,.
F
F
Then
it
doesn't
matter
and
but
some
other
things
will
be,
you
know
visible
right
like
we
will
have
in
dot
min
right
or
in
dot
next
right,
and
so
there's
some
some
new
things
that
will
show
up,
but
I
mean
I
don't
know
like
that.
That
to
me
is
kind
of
also
the
kind
of
thing
you
want
a
usability
test
right
so
like.
If,
if
we
you
know
end
up,
you
know
adding,
I
don't
know
20
more
members
to
2032,
let's
say
well
during
the
preview
time.
G
F
I
think
at
the
very
beginning,
when
they
did
the
framework,
I
think,
there's
a
part
in
the
book
where
they
tried
to
minimize
members
on
in,
because
people
felt
the
more
members
they
are
the
more
heavyweight
you
know
the
primitive
fields,
but
like
it,
you
know
we
have
structs
in
it.
People
know
how
structs
work
and
whether
the
thing
has
a
hundred
or
fifty
makes
no
difference
right.
H
A
G
F
Well,
I
mean,
I
think,
honestly,
that's
the
wrong
way
to
do
it,
because
I
think
the
way
to
think
about
this
eventually
the
feature
will
be
stable
right,
and
so
that
means,
if
we
design
the
feature
we
have
to
design
it
with
the
assumption
that
everybody
is
opted
into
that
right,
because
eventually
everybody
will
be
opted
into
that.
So
we
need
to
design
for
that.
Okay,
it's
not
for
the
six
to
12
months,
where
five
people
in
the
world
care
about
the
future.
F
Right,
no,
I
think
that's
yes,
like
my
point
is
just
that
eventually,
like
in
dot
net
seven,
let's
say
when
the
feature
is
stable.
Everybody
is
opted
into
t
sharp
understands
this
thing
now
right,
and
so
people
will
still
be
in
this
bucket
that
you,
as
you
said,
the
vast
majority
of
people
doesn't
care
about
operators
right.
F
H
Yeah
and
and
in
many
cases
users
won't
particularly
for
the
core
operators.
We
just
looked
at
users
will
never
see
them,
they
and
min
value
and
max
value
already
exist.
Additive
identity
will
be
new,
but
it
will
probably
be
explicit.
That's
not
something
you
really
care
about
outside
of
the
interface
itself.
Now
one
and
zero
will
probably
have
to
consider.
H
Is
this
worth
publicly
exposing,
or
should
it
be
explicit
likewise
for
operations
like
absolute
clamp,
div
ram
and
things
like
that,
we'll
have
to
decide,
should
these
be
explicit
or
are
they
worth
exposing
and
users
will
likely
end
up
using
those
those
things
and
they
are
likely
useful
even
for
users
who
aren't
doing
generic
math
and
and
whether
they're,
public
and
implicit
or
private
and
explicit
will
likely
come
down
to
how
usable
do
we
want
it
to
by
by
other
users
by
non-generic
users.
A
Yeah,
but
I'm
hoping
emo
with
all
experimental
features
which
this
may
be
the
only
one,
but
that
you're
you're
chatting
with
the
intellisense
people
and
if
something
has
the
whatever
attribute
we
end
up
putting
on
this,
is
part
of
an
experimental
feature
that
counts
as
eb.
Never
if
you
haven't
topped
it
into
experiments
and
and
is
full
if
it,
because
I
thought
the
whole
point
is
we
want
to.
We
think
that
we
may
end
up
changing
the
signatures
on
those
methods.
So
you
don't
want
to
depend
on
them
like
no.
F
But
that's
the
the
whole
point
of
the
feature
is
to
make
it
discoverable
right.
Okay,
so,
like
I
mean
it's
all,
it's
all
fine
to
see
things
that
might
change
right.
What
like
what
really
matters
is,
once
you
start
calling
them
and
then
our
analyzer
will
tell
you
like
sorry.
You
know
you're
not
opted
into
the
preview
right,
fair
enough.
F
Saying
to
me,
there's
no
point
in
I
mean
jan
asked
the
same
question,
but
I
mean
to
me
the
the
whole
point
of
preview
features
to
ship
them
in
rtm
products
is
to
increase
usage
right,
and
so,
if
you
don't
advertise,
you
don't
increase
your
usage
right.
So
you
want
you
want
to
advertise,
you
want
it
in
people's
faces
like
it's
a
regular
api,
okay
and
when
they
start
using
it.
That's
when
our
enforcement
will
kick
in
and
say
sorry,
you
need
to
opt
into
this
right.
Okay,.
F
H
So
for
this,
so
they
like,
like
I've,
said
a
couple
times.
The
previous
was
the
the
effectively
core
interfaces
used
to
build
everything
else.
Here's
from
here
on
is
the
actual.
H
What
I've
called
the
numeric
interfaces,
the
interfaces
that
most
users,
who
are
doing
constraints
on
generic
types
will
likely
interact
with
and
the
first
of
which
is,
I
number
and,
like
I
mentioned,
when
jeremy
asked
about
complex
at
the
beginning,
this
is
more
like
a
a
singular
number,
and
so
something
like
a
complex
which
is
realistically
two
numbers
put
together
to
represent
the
conceptual
whole
number
two
two
parts,
rather
those
would
not
be
covered
by
this
interface,
and
so
we
may
want
a
better
number,
a
better
name.
A
H
I
ring
that
that
number
is
explanatory
enough
and
it's
simple
enough
to
explain
to
users.
This
doesn't
come
cover
things
like
complex,
which
are
represented
by
two
parts,
and
you
want
something
else
to
represent
that.
Instead.
H
H
Right,
yeah
and
in
particular
scalar
is
not
a
name
that
most
users
end
up
encountering
yeah
and
so
I'd
rather
differentiate
between.
I
number
and
I
something
else
for
things
like
complex.
A
Yeah
I
just
like
it,
it
fails.
My
in
like
I
I'm
it's
not
strong
pushback,
but
my
it
fails.
My
english
test
of
I
complex
number
I
complex
or
complex
number
is
a
number
like.
That
is
an
english
sentence.
That
makes
sense
so
it
feels
like
the
code
tree
should
say
that's
true,
but
we
would
be
saying.
Complex
number
is
not
a
number
right,
it's
not
not
a
number,
it's
just
not
a
number.
It's
not
an!
I
number
right
and.
F
K
A
K
That's
fine!
It's
just.
H
H
H
That's
the
section
after
this
section,
which
is
the
implementers,
and
so
this
one's
not
directly
implemented
by
anyone
by
anyone.
It's
actually
the
interfaces
below
this
that
are
that
are
implemented
by
the
other
types,
but
almost
all
of
the
primitive
types
short
of
date,
time
time
span
and
guide
do
implement.
I
number.
H
In
particular
it
doesn't.
It
can't
implement
I
number,
because
it
has
two
parts,
and
so
there's
there's
not
a
good
way
to
represent
it
as
there's,
not
necessarily
a
good
way
to
represent
it
as
a
number
given.
It's
got
both
a
real
and
imaginary
part,
and
given
that
not
all
operations
we
put
on
number
are
valid
for
complex.
F
Yeah
I
mean
that's,
I
mean
that
to
me
is
kind
of
the
sticking
point
in
terms
of
interfaces
that
we
should
think
through
simple
factors.
Right
like
we,
I
think
that's
kind
of
the
little
step
for
most
abstractions
is
like
you
know,
is
it
too
broad
or
too
narrow,
as
in
like
you
know
how?
How
much
does
the
consuming
or
producing
code
suck?
G
H
For
for
for
vector
in
particular,
there
is
an
interface
that
I
pushed
up
this
morning
and
there's
an
open
question
of,
should
t-scaler
simply
be
restricted
to
where
t-scaler
is,
I
number
and
appropriate
other
interfaces,
or
should
it
be
its
own
interface?
That
itself
inherits
from
my
number
and
I'm
thinking
it
should
be
an
I
scalar
where
I
scaler
is
a
number,
but
that's
kind
of
still
open.
E
A
I
scalar
is
a
number
and
I'm
like
wait.
What
so,
hopefully
it
made
sense.
H
So
the
this
implements
basically
all
the
interfaces
we
just
defined
short
of
a
couple
that
are
further
down
like
this
doesn't
implement.
I
bitwise
operators,
because
not
all
numbers
are
bitwise
operatable.
That
really
only
makes
sense
for
binary
numbers
and
not,
for
example,
decimal
numbers.
F
H
Yeah,
so
so
t
other
is
some
other.
I
number
which
in
most
scenarios
is
probably
something
like
an
integer
literal
or
a
floating
point
literal
and
there's
there's
actually
four
concepts
exposed
here,
there's
create
from
t
other
which
will
throw
if,
if
t
self
is
not
representable.
H
Yes,
there's
create
exactly
which
will
return
a
nullable,
it's
effectively
the
try
create,
but
but
in
particular
it's
not
try
create
because
it
it
it
throws.
If
the
value
is
not
exact,
it
returns
null
if
the
value
is
not
exactly
representable.
H
H
Right
and
create
is
effectively
the
checked
cast,
which
is
the
default,
and
in
most
scenarios
that
should
hopefully
be
optimizable
away.
This
is
likely
one
of
the
places
where,
if
you're
implementing
a
type,
you
still
have
to
use
generic
the
generic
if
type
of
t
equals
type
of
view,
and
in
the
worst
case
you
might
get
an.
I
number
that
you
have
no
clue
how
to
handle,
in
which
case
you
might
have
to
throw
and
say
I
don't
support
creating
this
yeah.
C
E
H
A
Yeah,
but
it
feels
like
it's
work.
We
are
creating
this
as
a
generic
because
we
have
to,
but
it's
inherently
a
type
of
fall
like
there
may
be
some
mild
exceptions,
but
effectively
it's
a
it's
a
closed
generic
that
looks
open
for
any
particular.
H
Type,
yeah
and-
and
it's
it's
fairly
open
still
in
that
most
most
users
will
likely
be
something
like
a
binary,
integer
or
a
binary
floating
point,
and
so
you'll
be
able
to
do
the
right
thing
with
them.
But
there
may
also
be
something
like
someone
someone
to
find
their
own
type.
That's
a
number
and
you've
got
no
clue
how
to
convert
from
that
and
stephen
tobe
suggested.
H
Maybe
we
want
to
have
the
inverse
represented
as
well
like
cast
two
in
addition
to
effectively
this
create
from,
but
you
kind
of
run
into
the
same
issues
there
and
potentially
recursiveness
problems,
and
so
it
needs
a
little
bit
more
thought
and
scenarios
written
on
how
this
is
going
to
work
and
part
of
it
waiting.
K
F
But
it
is
kind
of
the
problem
of
like
you
know,
look
at
eye
convertible.
That
also
did
both
directions
and
very
often
you
need
the
other
direction
in
order
to
do
it
right
or
take
normal,
implicit,
conversions
or
explicit
conversions,
where
I
want
to
implement
something
that
operates
with
a
type
that
I
don't
own.
So
the
only
thing
I
can
do
is
I
can
define
operators
on
me.
That's
why
c
sharp
allows
them
to
be
defined
on
either
side
right,
but
like
right.
F
If
you
only
allow
one
side
that
basically
means
that
anybody
who
wants
to
extend,
I
number
basically
has
to
be
known
by
us
or
go
through
the
interfaces
that
really
define.
So
if
you
literally
create
your
own
out
of
thin
air,
then
it
will
probably
not
be
able
to
interoperate
at
all
with
us
right
right.
H
Thing
will
help,
and
it
may
be
that
we
end
up
having
I
convertible
from
which
takes
these,
and
I
convertible
2,
which
is
basically
the
inverse
of
b's.
A
Yeah-
and
I
wonder
like
does
this
really
belong
at
the
method
level,
or
should
this
be
at
the
type
level?
So
int
can
say
that
it's
that
it's
convertible
from
only
I
bitwise
others,
and
that
I
have
not
that
we've
seen
that
yet,
but
that,
if
there's
a
way
that
I
bitwise
other
supports
understanding
like
here's,
a
read-only
span
of
the
bit
pattern.
Go
then
it'd
be
like
fine.
A
If
you
can,
if
you
can
give
me
a
span
of
what
your
bit
patterns
are,
I
know
how
to
create
a
32-bit
truncated
version
of
that,
and
so
then
it's
that
way
we
don't
end
up
with
well,
I'm
of
any
number
well,
but
I
don't
understand
this
number.
So
no
and
it's
very
clearly
in
the
type
hierarchy
it
says
here
are
the
rules
for
when
this
will
work.
H
H
Right
we'd
end
up
having
like
we'd
end
up
having
one
for
fight
s
fight
short,
you
short
in
you
in.
A
A
Because,
looking
at
this,
like
the
a
couple,
things
are
weird
one:
it
feels
weird
that
this
is
on
number
and
that
maybe
it
should
be
carved
off
and
two.
It
feels
like
you
kind
of
always
need
to
have
the
same
t
other
support
across
the
four,
and
that
seems
like
it's
really
only
convention
like
it's
a
convention
driven
thing,
because
nothing
can
help
enforce
it
once
it's
four
independently
generic
methods.
H
Right
and-
and
that's
kind
of
this
is
how
swift
exposes
it
effectively
and
they
effectively
expose
it
on
number,
but
this
is
probably
the
the
thing
that
we're
going
to
end
up
having
to
do
the
most
work
on
in
most
iteration
on
after
I
get
a
prototype
that
allows
me
to
start,
you
know,
testing
the
actual
scenarios
and
not
just
writing
them
and
saying
this
should
probably
rotten.
A
But
yeah,
so
if
we
look
at,
you
know
complex
number,
as
I
think
that
is
a
number,
but
isn't
a
number
with
these
operations
also
make
sense
on
that,
in
which
case
does
this
need
to
be,
or
would
it
be
a
different,
a
lower
level
interface
than
number.
F
F
Things
look
sound
on
the
board,
but
then,
when
you
actually
take
arguments,
you
realize
that
certain
combinations
just
don't
make
sense
right,
and
it
might
be
the
same
here
right
where,
if
you
actually
as
jeremy
suggested,
if
you,
if
everybody
deals
with
my
number,
then
it's
fine.
But
if
you
know
say,
oh,
I
break
out
into
the
more
specific
interfaces
because
I
implement
you
know,
have
these
weird
types
that
aren't
numbers.
F
We
now
have
glaring
holes
where
right.
Well,
you
can't
get
into
that
generic
space,
because
you
don't
have
these
methods
right
and-
and
that's
I,
I
think,
that's
kind
of
the
problem
with
some
of
the
stuff.
I
think
steven
at
some
point
tried
to
implement,
like
averaging
over
link
with
some
proposed
language
syntax,
and
he
couldn't
get
it
to
a
point
where
it
would
actually
do
anything
useful
and
that's
kind
of
a
you
know
the
concern
right.
K
H
Probably
gonna
have
the
most
iterative
work,
because
this
is
effectively
how
you
how
you
convert
from
one
t
to
another
t
right
moving
past
those,
though
there's
some
open
questions
over
like
should
we
have,
is
signed
or
is
binary
or
is
fixed
with
or
the
base
or
radix
other
languages
expose
some
of
these
they
might
be
beneficial.
H
I've
not
done
a
lot
of
investigating
there.
Yet
you
also
get
into
the
the
named
value
one
and
zero,
which
are
effectively
aliases
for
multiplicative
and
additive
identity,
and
then
you
get
into
some
of
the
things
that
levi
asked
about
earlier,
like
absolute
value,
clamp,
div,
rem,
max
min
sign
sign
is
notably
exposed
here
on
number,
even
though
for
unsigned
values
it
will
only
ever
return
zero
or
one,
because
I
think
that's
more
convenient.
H
H
F
H
A
A
H
Or
it
might
be
v2
as
in
actual
v
actual
v2
yeah,
but
that's
something
that
we'll
have
to
work
with
the
c
sharp
language
team
on
to
make
sure
that
they
solve
the
the.
There
was
a
couple
open
questions
about
dimms
due
to
how
they're
implemented
and
exposed
and
how
you
can't
actually
defer
to
a
dim
implementation
today
like
if
you
want
to
override
a
dim,
you
can't
override
it
by
forwarding
to
the
actual
dim,
and
so
they
need
to.
They
need
to
fix
that.
For
this
scenario
for
dims
to
work.
H
Right
right
or
if
you
want
it
to
be
implicitly
implemented
rather
than
explicitly
because
by
default,
dimms
must
be
dims,
are
explicitly
implemented,
and
so
so
the
language
team
has
to
work
through
those
couple
remaining
issues
before
they
say
that
dims
are
ready
here.
F
So
but
but
you
are
saying
they
are
committed
to
make
it
work
in
general.
They
just
don't
know
the
timeline
because
like
if
we,
if
you
find
ourselves
in
the
future,
where
we
just
can't
support
dimms,
then
that
direction
seems
somewhat
scary,
because
it
means
we
have
support
for
like
four
core
math
methods
and
the
rest
is
now
at
best
generic
methods
with
a
switch
statement
or
something
right.
H
H
A
All
right,
so
I
have
some
commitments
today.
I
can
keep
the
stream
running
for
five
and
a
half
more
minutes
and
then
I
have
to
shut
it
down
so.
H
A
H
So
then,
you
because
most
of
these
next
interfaces
are
actually
fairly
empty.
I
signed
number
is
a
number
that
is
also
negatable,
like
I
mentioned
negation
might
need.
We
might
want
to
move
that
onto
I
number
itself
and
define
it
as
0
minus
value,
particularly
when
you
look
at
vector
and
stuff.
We
actually
defined
that
today,
already
I
signed
number
is
very
important.
So
that
way
you
can
differentiate
on
whether
the
value
you're
operating
with
is
signed
or
unsigned.
H
H
It
also
exposes
some
concepts
from
big
integer,
which
are
get
bit
length,
get
byte,
count
two
byte
array
and
try
right
bytes,
I'm
not
convinced
these
are
the
right
signatures,
they're
currently
copied
verbatim
for
beginners.
I
think
we
want
to
change
them
slightly.
Yeah,
adding.
H
That
was
my
bad,
so
I
I
think
we
want
to
fix
it,
but
we
do
want
some
concept
to
say
for
a
binary
number.
You
know
if
it's
signed
or
unsigned
and
you
can
get
the
raw
bit
representation,
and
this
is
what
allows
you
to
in
create
say.
If
t
other
is
a
binary
number,
then
I
can
always
get
you
know
the
bit
representation
and
understand
it.
H
Then
you've
got
I
binary
integer
below
that
which
exposes
the
shiftable
operators
on
top
of
it,
as
well
as
some
things
like
leading
zero
count.
Pop
count
pop
count
and
leading
zero
count
might
be
better
on
binary
number,
but
they're
really
focused
around
integral
values
and
then
rotate
left
and
right,
which
levi
asked
about
earlier.
G
H
H
In
empty
self,
so
what
is
not
a
binary
number?
Then
decimal
is
not
a
binary
number.
The
ieee
decimal
types
are
not
binary
numbers,
they
are
decimal
numbers
and
you
cannot
interpret
them
as
a
bitwise
value.
You
cannot
perform
bitwise
operations
like
or
and
and
on
them,.
H
H
H
The
next
key
concept
here
is
floating
point.
This
is
probably
the
method
that
has
that's
the
interface.
That's
the
biggest
in
particular.
Decimal
is
not
a
floating
point.
Decimal
is
a
microsoft
defined
type,
that's
actually
not
standardized.
H
Well,
it's
also,
basically,
a
fixed
point
right
right.
Yeah
n
is
what
I
say,
and
it
doesn't
support
most
concepts
like
infinities
or
nands,
or
you
know
cosine
or
any
of
the
operations.
It's
really
a
currency
type
and
it's
meant
for
use
in
currency
and
even
though
there's
like
29
significant
digits
that
you
can
have
on
the
left
or
right
side
of
the
decimal
point.
Realistically,
you
don't
want
that.
The
number
of
digits
to
go
over
like
10
or
the
perf
tanks,
terribly,
and
so
decimal
is
explicitly
not
a
floating
point.
A
A
H
H
I
floating
point
and
I
triple
e
floating
point,
but
I
don't
think
that's
worthwhile,
but
it
basically
exposes
the
constants
all
of
the
methods
off
math
that
we've
approved
and
then
I
basically
list
the
ieee
requirements,
and
then
we
get
down
to
I
binary
floating
point
after
that
and
I
decimal
floating
point
which
I've
defined
for
the
ieee
type,
but
we
won't
actually
implement
it
if
we
never
expose
decimal
types
in
the
future.
H
And
then
the
last
interface
in
these
core
in
this
core
set
is
I
vector
which
effectively
exposes
the
vector
of
t
interface.
It's
the
same
interface.
I've
suggested
we
expose
on
vector,
64,
128
256,
but
we've
not
reviewed
yet
it
would
also
be
implemented
by
vector
2,
3
4.
It
could
be
implemented
by
generic
math
factor
types
and
it
effectively
allows
you
to
take
a
set
of
values.
H
K
When
we're
a
little
less
info,
saturated.
H
And
time
constraint,
yeah,
but
then
the
next
section
is
just
the
the
actual
interfaces
or
the
the
core
types
and
the
interfaces
they
implement,
both
the
ones
I've
defined
above
and
the
ones
they
already
implement,
like
I
serializable
so
you'll,
see
like
time
span,
implements
multipliable
and
multiplicative
identity,
and
things
like
that.
F
H
H
Particularly
with
floating
point,
I
probably
want
to
fix
up
based
on
the
feedback
we've
had
so
far,
and
hopefully,
by
the
time
we
do.
The
next
review
they'll
actually
be
the
runtime
prototype,
we'll
be
ready,
at
least
for
me,
to
do
things
locally
and
I'll,
be
able
to
provide
some
actual
scenarios
for
us
to
like
walk
through
and
see
how
important
concepts
that
create.
A
Okay,
that
yeah,
so
people
should
try
and
think
in
the
back
of
their
heads
on
the
value-exposing
interfaces
of.
Can
we
come
up?
Is
this
the
pattern
we
want,
or
is
there
a
better
one
and
then
basically
I
have
that
we
kind
of
stopped
that
binary
number.
G
Tanner
the
additive
identity,
multiplicative,
identity,
min
max
value.
Is
there
anything
that
should
be
added
to
that
list
as
far
as
value?
Exposing
is.
Is
that
complete.
H
I
think
that's
kind
of
complete
right
now.
The
other
constants
are
more
restricted
to
like
floating
point
or
binary
numbers
where
you
can
actually
say
things
like
this
has
a
a
a
significant
and
an
exponent
and
they're,
not
really
generic.
In
that
sense,
it
may
be
that,
as
we,
you
know,
look
more
at
complex
and
maybe
other
libraries
like
math.net.
They
may
have
concepts
that
are
important
for
us
to
expose
as
core
types
as
well,
but
at
least
today
I
don't
have
those.
D
A
Else
is
commenting
on
my
comments.
I
will
post
that
and
emo
I'll.
Let
you
take
care
of
the
email
stuff,
because
I
gotta
go
yeah.
F
G
F
Right
then
thanks
everyone
and
then
I
think
we're
you
know
we
will
flip
it
back
to
needs
work
and
then,
whenever
tennant
is
ready,
we
can
take
another
look.