►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Anyway,
so
I'm
sure
ben
will
find
out
that
he
approved
his
suggestion
because
he
was
bugging
me
already
on
it
all
right.
So
then
do
you
want
to
do
this
first
here,
because
I
think
this
is
probably
faster
than
whatever
the
platform
guards
are
going
to
be,
because
last
time
it
took
us
an
hour
and
a
half.
B
A
From
the
well
from
the
blocking
ones,
I
believe
yes,
unless
somebody
marked
them
yesterday.
Okay,
because
I
was
checking
yesterday
and
I
think
the
only
person
that
picked
me
was
cory
and
he
marked
his
blocking.
So
it
should
be
the
only
three
ones
that
we
have.
A
A
C
D
Sure
so
we
need
there
there's
basically
two
goals
here.
One
is
we
want
to
define
for
the
new
apis
we've
defined
in
system.net.connections.
We
want
to
define
what
exceptions
are
expected
from
these
things.
Is
it
just?
I
o
exception?
That's
probably
what
most
folks
are
the
limited
implementations
we
have
today
are
probably
throwing
io
exception,
but
want
to
at
least
have
some.
You
know
basic
guidance
about
what
exceptions
these
apis,
like,
listen,
async
and
connect.
D
Async
should
throw
two
and,
of
course,
as
part
of
that
discussion
we
can
have.
We
may
also
want
to
define
some
much
like
socket
error
on
socket
exception.
Today
we
may
want
to
define
some
some
specific
error
conditions
via
an
enumer
or
something
like
that
that
that
will
allow
users
to
distinguish
between
different
kinds
of
failures
that
can
happen
when
they're
doing
listener,
connector
or
except
the
specific
requirement.
D
Also
that
we
have
from
asp.net
here
is
that
asp.net
in
the
code
that
they're
using
today
does,
via
socket
exception,
detect
three
particular
socket
error
conditions
and
handle
will
just.
I
don't
think
it
does
much
in
terms
of
actually
handling
them
itself,
but
at
least
does
stuff
to
report
them
to
the
user
in
terms
of
mapping
it
to
their
own
exceptions.
D
Those
three
specific
error
cases
are
address
and
use,
which
is
surfaced
from
basically
a
listen
operation
and
then
connection
reset
and
connection
abort,
which
are
connection
aborted,
which
are
surfaced
via
stream.read
and
write
or
async
or
not.
D
So,
at
the
very
least,
we
need
to
define
some
sort
of
way
to
distinguish
those
conditions
that
is
generic
and
not
specific
to
sockets
that
the
that
does
raise
well.
That
kind
of
leads
to
the
the
next
issue
here,
which
is
there's
kind
of
two
sets
of
apis
that
we're
talking
about
here
there
is.
There,
are
the
these
brand
new
connection,
apis
right,
there's
connection
factory
connection,
listener,
factory
connection
and
there's
stuff
like
connect,
async,
listen,
async,
except
async.
D
These
are
all
brand
new
apis,
so
we
are
free
to
define
whatever
kind
of
exception
semantics.
We
want
here,
new
exceptions,
old
exceptions,
new
enums,
whatever,
then.
The
other
case
is
the
exposing
connection,
aborted
and
connection
reset
from
stream.read
and
write.
D
We,
these
are
obviously
existing
apis.
They
throw
I
o
exception
today,
so
we
want
whatever
they
we're
going
to
use
here
in
the
future
needs
to
be
an
I
o
exception
or
a
derivative
thereof,
but
with
some
extra
piece
of
information
about
how
to
distinguish
the
particular
cases
of
aborted
and
reset.
D
So
we've
got
three
options
here
that
we
put
together,
which
I
will
call
the
the
two
exception
or
the
the
add
to
exceptions
case
the
add
one
exception
case
and
the
add
no
exceptions
case,
the
two,
the
and
that's
in
order
abc
here
so
option
a
is
the
two
exceptions
case.
D
We
add
a
new
connection
exception,
specifically
for
the
system.net.connections
apis.
It
lives
in
system.net.connections
as
you'd
expect,
and
it
has
a
connection
error
on
it,
which
is
a
something
of
a
simplification
of
the
kinds
of
errors
that
you
get
back
from
sockets
when
doing
operations
like
connect,
listen
and
accept,
and
the
idea
would
be
that
anybody
implementing
that,
including
the
sockets
factory
here,
would
set
the
connection
error
when
they
throw
an
exception,
and
if
somebody
wants
to
do
something
with
that,
they
can
do
it.
D
The
particular
new
values
are
just,
as
I
said,
kind
of
just
a
a
basic
sort
of
simplification
of
the
socket
error
ones.
These
seemed
like
the
ones
that
were
most
useful
and
most
interesting
to
users.
Without
you
know,
going
into
the
nitty-gritty
of
the
differences
between
socket
error,
address
family
not
supported
and
addressed,
not
available
and
stuff
like
that,
and
then
okay,
so
continuing
with
option
a
the
for
the
the
stream
exceptions
for
stream,
read
and
write,
we
would
define
a
new
exception
type,
which
we've
called
network
exception
here.
D
That
just
basically
derives
my
exception
as
it
needs
to,
and
it
adds
a
network
error
property
here
which
we've
just
defined
two
values
for
boarded
and
reset.
We
don't
love
the
name
network
exception.
The
trick
here
is
that
these
exceptions
make
sense
for
a
class
of
streams
that
are
basically
connection
oriented
streams,
but
they
don't
necessarily
make
sense
for
non-connection
oriented
or
random
access
streams
like
file
stream
or
memory
stream,
where
it
doesn't
really
like
the
connection
itself,
isn't
aborted.
D
The
file
may
be
closed
or
or
disposed,
or
something
like
that,
but
but
it
doesn't
have
the
same
kind
of
semantics
of
a
connection
reset
or
connection
abort,
but
there
are
other
types
of
streams
like
quick
streams
or
maybe
layer
streams
like
ssl
stream,
that's
sitting
on
top
of
a
a
network
stream
underneath
that
we
that
might
want
to
expose
this
added
error
information
so
that
a
consumer
can
do
something
with
it.
So
that's
option
a
option
b.
If
you
can
scroll
down.
D
Is,
as
I
said,
the
one
exception
case,
where
what
we
basically
did
is
we
said
well,
we
we
want
to
have
a
new
exception
here,
and
we
want
to
have
a
a
new
enum
for
the
error
codes,
but
we'll
just
use
one
we'll
define
it
in
system.io
and
yeah
the
connections
api
can
use
this
too,
as
well
as
stream.read,
write
and
anybody
else
who
wants
to
use
it
of
course,
and
then
the
new
just
basically
captures
all
the
possible
interesting.
D
Enumerated
errors
that
we
have
here
connection
api
would
presumably
throw
exceptions
with
those
first
four,
because
they
are
about
listening
and
accepting
and
connecting
and
stuff
like
that,
whereas
stream.read
or
networkstream.read
and
write
would
throw
stuff
like
aborted
or
reset
and
option
c
is
very
similar
to
that.
D
D
Let's
just
add
it
to
I
o
exception,
and
yes,
these
this
set
of
particular
I
o
errors,
don't
necessarily
apply
to
other
all
the
scenarios
in
which
I
o
exception
is
used,
but
that's
okay,
we'll
they
don't
need
to
use
it
additionally
in
the
future,
if
we
wanted
to
add
more
values
to
this
enumeration
that
do
apply
to
file
stream
or
or
some
other
stream
like
that,
we
could
add
more
values
to
the
enum
and,
and
perhaps
you
know,
make
users
lives
easier
by
distinguishing
some
of
those
error
conditions.
D
The
one
last
thing
to
say,
I
think,
before
we
kind
of
have
a
discussion
about
this,
is,
as
there
were
some
comments
in
here.
Like
yon
and
dan
about
how
the
whole
question
of
how
we
surface
particular
error
conditions
is
really
a
broader
discussion
across
the
framework,
jan
linked
to
an
issue
about
how
to
do
this.
I
think
with
file
stream
in
particular,
but
certainly
the
the
the
it
doesn't
seem
like
hey.
D
It
doesn't
seem
like
we
do
a
a
whole
lot
of
this
kind
of
distinguishing
particular
error
cases
in
general.
Today,
at
least
not
with
io
exception
and
b,
we
probably
ought
to
think
broadly
about
if
we
want
to
do
more
of
that,
and
and
if
we're
going
to
do
it,
how
we
want
to
do
it
in
terms
of
enumeration
values
derive
exceptions.
E
E
Basically,
the
the
statement-
caption
type,
should
say
everything
that
you
need
to
say
there
shouldn't
be.
There
shouldn't
need
to
be
whatever
that
the
win
statement
is
or
you
shouldn't
need
to
inspect
it
internally.
So,
but
that's
mostly
in
an
anecdote
by
kristoff
and
not
anything
that
we've
codified
in
a
specific
rule.
D
D
If
that's
the,
if
that's
the
guidance,
I
don't
have
a
strong
preference
here.
I
think,
from
a
networking
point
of
view,
we're
kind
of
just
looking
for
what's
the
general
guidance
and
how
do
we
satisfy
the
the
requirements
that
we've
got
here
to
distinguish
at
least
a
a
at
least
those
three
and
possibly
a
few
more
since
we're
already
doing
this.
E
I
mean
certainly,
I
think,
if
we
were,
if
this
was
bit
banging
all
the
way
down
to
to
the
nick
itself,
and
there
was
no
system
p
invoke
type
stuff
involved,
then
the
answer
would
be
easy.
It's
different
problem,
a
problem
that
should
be
handled
differently,
should
be
a
different
type
of
exception.
E
Once
once
it's
the
we're
wrapping
native
layers,
now
you
get
to
decide,
is
it
better
to
transparently
return
them,
which
is
a
problem
for
the
user?
Should
we
try
normalizing
them
across
os's
into
something
like
an
enum,
at
which
point
we
could
have
done
different
exception
types,
etc,
but,
like
the
the
big
general
notion
is,
if
you
need
a
different,
if
you
would
handle
it
in
a
different
way,
it
should
be
represented
by
a
different
type
and
anything.
E
B
So
these
were
kind
of
modeled
after
the
current
socket
exception,
which
returns
a
socket
error,
and
it
has
been
useful
to
have
an
error
code
there,
just
because
of
typically
you
can
actually
see
in
the
example
here.
Typically,
if
you're
handling,
socket
errors,
you're
kind
of
catching
a
whole
bag
of
them
that
are
all
similar-ish,
but
we've
already
kind
of
consolidated
them
here.
So
maybe
having
separate
exception
types
is,
would
be
better.
E
E
If
you
think
that
there's
going
to
be
a
a
grab
bag
or
like
four
things
that
people
will
handle
but
like
12
different
errors
that
are
worth
logging
differently,
then
maybe
that's
that
you
do
the
base
class,
which
has
the
enum,
but
then
you
for
types
that
you
expect
people
to
handle.
You
make
derived
types
and
yes,
the
derived
type
only
has
the
one
code
ever
represented
in
it.
E
But
what
you've
said
is
this
is
this
is
the
you
know,
connection
refused
exception
and
that
that's
the
thing
that
someone's
going
to
handle
differently
in
their
code
than
address
and
use,
and
and
things
like
that,
I
mean
that's
again-
the
place
to
start
to.
D
Start
the
thing
I
mean
given
that,
given
that
guidance,
it
seems
clear
to
me
that
that
looking
at
the
aborted
and
reset
cases
in
particular
that
those
should
have
their
own
derived
exception
types,
we
should
just.
We
should
define
connection
aborted
exception
that
derives
myoexception
and
connection
reset
exception.
D
That
derives
from
I
o
exception,
we'll
modify
network
stream
and
any
other
streams
that
we
want
to
to
to
throw
those
and
because
they
derive
from
I
o
exception,
that's
backward,
compatible
and
we'll
tell
anyone
who
wants
to
detect
those
particular
cases,
including
asp.net,
hey,
there's
these
new
exceptions,
you
can
handle
them
and
we'll
tell
anybody
who's,
implementing
streams
that
wants
to
expose
those
hey.
There's
these
new
exceptions.
You
can
throw
them
if
you
want
to
and
allow
customers
to
catch
it
as
opposed
to
just
throwing
a
generic
io
exception.
E
And
to
be
clear
on
that
aborted
is
handled
distinctly
from
other
I
o
and
reset
is
handled
distinctly
from
other.
I
o
and
distinctly
from
aborted,
so
aborted
and
reset
are
two
different
special
problems.
D
Yeah
aborted,
so
yeah
this
is
worth
discussing,
aborted
mean
well,
okay,
let's
start
with
reset.
You
establish
a
connection.
You
start
reading
and
writing.
Reset
means
that
your
peer,
the
guy
on
the
other
end,
decided
to
kill
the
connection.
They
said
we
don't
want
to
do
this
anymore,
we're
sending
you
a
reset
and
so
you're
going
to
start
getting
errors
from
your
read
and
write
operations
and
say
the
connection
was
reset
by
the
peer.
D
Exactly
aborted
means
it
was
aborted
locally.
In
other
words,
your
code
decided
that
it
wasn't
interested
in
this
connection
anymore.
Maybe
something
timed
out
or
something
like
that,
and
it
decided
to
go
close.
The
connection
dispose
the
stream
whatever
and
or
shut
down
the
stream
and
any
pending
or
subsequent,
read
or
write
operations
that
you
have
will
get
in
a
the
connection,
aborted
exception,
which
again
is
useful
to
distinguish,
because
that's
much
different
than
like.
It's
not
that
the
it's
not
that
some
connection,
something
failed
with
the
connection.
B
G
B
A
I
mean
that's
the
thing
I
would
caution
against
too
is
because
if
you
go
all
the
way,
then
you
end
up
with
effectively
one
exception
per
enum
member,
which
seems
over
the
board
as
well.
Like,
I
think
what
I
would
do
is
I
would
I
would,
as
jeremy
suggested
like
come
up
with
a
hierarchy
of
things
that
you
think
are
very
likely
people
to
to
handle.
So
I'm
not
a
fan
of
munching
everything
in
io
exception,
because
that
would
be
too
much,
but
similarly,
I
think,
having
one
exception.
A
Pre-Ina
member
also
seems
over
the
top,
because
that's
an
ever-growing
list,
but
the
nice
thing
is,
if
you
have
a
base
type
that
is
reasonable,
like
I
don't
know
a
connection
error
or
networking
exception,
for
example,
then
it's
totally
reasonable
for
us
to
define
more
derived
types
in
the
future.
So,
for
example,
if
you
say
today,
we
expose
address
and
use
only
as
an
enum
member
or
network
exception,
but
it's
so
common
that
people
would
like
just
catch
the
exception
directly.
A
We
can
totally
have
a
new
exception
type
address
in
use
network
exception
that
derives
from
network
exception
because
it
won't
break
any
with
any
of
the
existing
code.
It
just
means
that
if
you
throw
that
instance
and
you
create
the
network,
error
property
better
still
says,
address
and
use,
but,
like
you
can
basically
this
way
you
can
you
can
make
it
a
little
bit
more.
You
know
future
proof
in
the
sense
that
if
in
v1
you
only
have
a
few
error
cases,
you
really
care
about,
and
basically
none
of
them
require
extra
state.
A
People
want
to
write
custom
catch
handlers
for
them,
then
you
can
add
them
on
demand
as
well,
and
we
have
done
this
in
the
past
as
well
with
com
exceptions,
but
I
think
by
and
large,
like
we
don't
want
to
end
up
with
win32,
where
we
have
one
exception
per
error
code,
but
at
the
same
time
we
don't
want
to
end
up
in
win32
where
we
have
one
giant
table
of
error
codes
right,
so
the
truth
is
somewhere
in
the
middle
and
it's
unfortunately
an
opinionated.
Take
on
that.
A
So
it's
hard
for
me
to
say,
like
you
know,
make
these
exception
types
but
like,
as
jeremy
suggested.
I
think
the
key
scenario
is
what
are
the
error
codes
that
are
most
commonly
handled
by
user
code
and
make
sure
you
have
corresponding
exception
types?
Nobody
wants
to
write
catch,
yeah
generic
exception
name
and
then
a
giant
when
clause
right.
That's,
that's
not
discoverable!.
E
The
factory
can
change
to
throwing
the
most
derived
type
granted
somebody
if
the
constructor's
public
could
still
do
it
wrong,
but
it
it
will
mean
that
anybody
who
had
the
filter
in
place
on
the
base
or
what
then
became
the
base
class
will
still
work
and
then
they'll
get
the
derived
type
in
any
version
that's
available,
and
that,
I
think,
is
a
good
path
forward
for
taking
something
from
an
enum
into
a
specific
exception,
so
that
catch
handlers
are
cleaner.
D
That
makes
sense,
I
think
I
so
okay,
given
that
guidance,
then
I
think
for
the
connection.
Apis
we've
just
defined
like
a
new
connection
exception
that
derives
from
io
exception.
I
guess
we
wouldn't
even
have
any
new,
because
the
only
the
only
specific
condition
that
we
know
that
that
that
any
of
our
customers
need
to
detect
today
is
simply
addressing
use.
So
I
think
we
just
define
a
general
purpose.
D
Connection
exception
that
doesn't
even
have
an
enum
just
has
text
that
says
that
describes
what
went
wrong
for
logging
purposes
and
then
we'd
have
one
specific
derived
exception
from
that
that
is
address
and
use.
And
then,
as
you
mentioned,
we
can
add
factory
methods
on
the
exception
itself,
for
particular
conditions,
so
that
they
have
you
know
so
that
it's
future-proof
and
so
that
they
have.
You
know,
standard
text
that
they
use,
but.
D
But
I
don't
think
we'd
actually
draw.
I
don't
think
we
define
derived
exception
types
where
stuff
like
invalid
address
or
connection
refused,
until
we
decided
that
there
was
a
specific
use
case
for
doing
that,
and
especially
since
it's
late
in
the
game-
and
we
don't
want
to
be
inventing
a
whole
bunch
of
stuff
here-
that
we
feel
like
we're
gonna
commit
to
long
term.
Does
that
make
sense.
B
D
B
A
hybrid
of
having
both
enums
and
derived
exception
types.
I
think
that
at
the
minimum,
a
distinction
between
connection
refused
and
host
not
found
is
important
here.
A
Okay,
I
mean
the
reason
why
I
think
having
an
air
property
is
useful
is
in
the
same
reason
why
we
have
it
in
other
places,
already
right
socket
exception,
has
it
sequel
exception?
Has
it
and
it's?
Basically,
when
you
have
a
long
tally
of
error
codes
that
you
know
you
don't
want
to
hide
information
from
the
user
and
you
want
people
to
be
able
to
switch
on
them
if
necessary.
A
So,
but
I
see
it
as
an
sk
patch
right,
it's
more
like
the.
Let's
avoid
thousands
of
exception
types,
but
at
the
same
time,
like
yeah.
F
D
As
far
as
what's
going
on
with
the
socket,
so
we
basically
just
took
the
native
list
and
said
socket
error
equals
these.
You
know
23
error
codes
or
whatever.
In
this
case,
we
have
an
opportunity
to
define
exactly
what
it's
it's
an
abstract
api
already
right.
It's
general
purpose:
it's
meant
to
not
be
tied
to
a
specific
api
like
sockets,
so
we
can
determine
exactly
what
error
conditions
we
want
to
surface,
whether
that's
four
or
forty,
and
I
think
it's
probably
a
lot
closer
to
four
than
40.
E
Yeah
but
yeah,
basically
the
the
what's
on
the
screen
modulo
naming
of
like
if
it's
reasonable
to
to
say
you
know,
host,
not
found,
which
I
assume
it
means
a
dns
resolution
error
and
check
the
entry
that
you
typed
versus
connection
refused
they're,
not
listening
et
cetera
like
those
are.
Those
are
things
that
an
application
could
handle
differently
to
to
tell
a
user
to
you
know
something
different
is
going
on
and
that
maybe,
if
maybe
a
library
would
also
handle
differently
for
what
its
recovery
actions
would
be
of
visit.
E
Is
it
a
wait
and
try
again
or
is
it
like?
Maybe
the
internet
doesn't
exist,
but
that
maybe
they're
not
common
enough
that
they're
all
worth
distinct
exception
cases
right
now,
so
yeah
I
would
go
the
hybrid
model
so
do
define
the
enum
now
and
the
exception,
because
otherwise
you
have.
What
would
your
factory
method
take,
because
you,
you
want
to
be
able
to
say,
give
me
the
correct
network,
exception
or
connection
exception
or
whatever
for
error,
addressing
use?
Well,.
D
E
Fair
enough
factory
methods
instead
of
factory
method-
I
guess
but
yeah,
but
then,
if
you're
going
to
have
the
connection
refused
exception
or
sorry,
the
create
connection
refused
exception
as
a
method,
and
it's
just
returning
connection
exception,
then,
is
that
just
in
the
text
that
somebody
finds
out
what
went
wrong
like
as
again
as
emo
said,
with
the
sql
exception
and
stuff,
sometimes
for
advanced
cases,
people
will
want
to
switch
off
the
the
error
property.
It's
just
that
shouldn't
be
your
your
main
line
design.
It
should
be
the
advanced
design.
E
A
Sorry,
the
only
other
problem
that
you
also
have
when
you,
when
you
have
these
long
arrow
lists,
is
like
you
have
to
decide
what
the
error
code
is
right.
So,
in
your
case,
you
decided
on
an
enum
which
now
has
this
problem
of.
How
do
you
map
the
native
api
to
that
list?
And
can
you
do
this
sufficiently
in
all
cases
right
if
you,
if
you
decide
that
an
exception
hierarchy,
that
is,
you
know,
a
small
set
of
exceptions.
A
It
might
not
be
too
bad,
but
if
you
have
an
error
list
of
like
30
items
eventually,
then
the
question
is
you
know?
How
do
you
do
this
across
operating
systems
when
different
operating
systems
have
you
know?
Some
may
have
three
error
codes,
where
the
other
one
only
has
a
single
error
code
for
the
for
all
three
cases
and
that
might
get
also
problematic,
but
in
sql
it
kind
of
works,
because
the
error
codes
are
maintained
by
one
entity
and
there's
an
unambiguous
one
to
one
correspondence
same
with
win32
but
like
for
abstractions
error.
D
The
value
of
these
is
is
to
have
a
common
way
to
represent
these
conditions
across
different
providers.
E
Right
but
again
that
comes
back
to
like,
if
I
don't
know
that
connection
refused
makes
sense
in
anything
other
than
a
socket,
but
if
it
does
like
the
notion
that
you
want
to
handle
hey
the
other
side,
actively
rejected
the
request
to
surface
that
differently
in
a
in
an
application,
then
you
don't
want
someone
to
have
to
sniff
the
inner
exception
to
find.
Oh,
it
was
a
socket
exception
and
the
socket
error
was
connection
refused,
because
any
time
that
you
needed,
essentially
if
your
catch
looks
at
inter
exception,
someone
has
failed.
D
I
was
saying
I
didn't
mean
to
imply
that
looking
at
that,
your
cash
should
be
looking
at
the
interest
section.
I'm
simply
saying
that,
if,
if
this
is
for
logging
and
diagnostic
purposes,
the
information
will
be
there
right
in
the
inner
exception.
If
you're
making
a
programmatic
decision
trying
to
catch
particular
conditions,
then
yeah.
D
I
agree
that
that,
if
we
want
to
enable
that
we
need
to
do
either
an
enum
or
a
derived
type
here,
and
I'm
still
just
kind
of
struggling
a
little
bit
to
understand
what
the
guidance
is
as
far
as
whether
we
should
just
do
derived
types
here
or
whether
we
should
just
do
enums
and
to
what
extent.
We
should
worry
about
exposing
these
today
versus
versus
limiting
what
we
expose
today
and
keeping
it
open
in
the
future
to
define
more
conditions
that
people
might
care
about.
B
In
terms
of
what
people
care
about,
I
think
and
enum
would
probably
be
okay.
For
most
of
these,
the
aborted
exception
would
probably
be
the
most
commonly
caught.
D
Yeah,
I
think
we're
aborted
and
reset.
We
definitely
want
derived
exceptions
right.
B
Yeah,
the
other
ones,
I'd
be
fine,
saying
keep
those
in
and
eat
them.
For
now
we
can
expose
additional
exception
types
later.
If
we
need
to.
E
I
mean
presumably
they'll
all
be
in
the
enum,
just
the
like.
Looking
at
your
grouping
right
now,
it's
the
the
the
four
in
the
middle
you're
saying
would
not
have
a
public
derived
typed
yet,
and
the
two
at
the
bottom
would
each
get
their
own
type
in
addition
to
being
represented
in
the
enum,
because
they
need
to
set
something
on
the
base
class
property.
D
Yes
and
additionally,
address
and
use
would
have
its
own
derived
type
because
we
needed
it.
Well,
I
guess,
if
it's
on
the
enum,
then
we
don't
need.
E
Right,
it's
all
about.
Do
you?
Do
you
think
that
it's
a
common
thing
for
someone
to
want
to
handle
differently
than
the
other
kinds
of
error?
If
they're
all
going
to
be
lumped
together
and
something
went
wrong,
then
you
don't
need
a
derived
type.
If
it's
oh
address
was
in
use,
I
should
increment
my
port
number
and
try
again.
Then
then
that's
a
different.
If
and
that's
a
common
thing,
then
then
you
would
totally
do
it.
E
B
E
Yeah
cause
again
like
I
can
see
an
application
saying
oh
host
not
found
that's
like
highlight
the
box
in
red
of,
like
you
type
gibberish
here,
but
that
the
average
library
is
just
going
to
look
at
all
of
these
and
either
have
a
common
retry
of
the
networking
stuff
didn't
work
or
never
look
at
it
at
all
and
just
let
it
throw
through
and
and
so
that's
where
you
have
to
decide.
The
balance
is
how
how
common
is
someone
going
to
handle
the
error
but
yeah?
E
So
I
would
say,
sort
of
start
with
this
and
then
anything
that
you
expect
someone
to
catch
or
if
it's,
that
asp.net
is
handling
those
three
things
already.
That's,
basically,
your
your
data
set
of
which
three
of
these
need
a
derived
type
in
addition
to
being
represented
in
the
enum.
D
Yep
sense,
all
right,
I
think
we
have
the
the
the
guidance
we
need
cory,
anything
else.
Otherwise
we
will
go
revise
this
and
come
back
thursday.
Sound
good.
B
Jeff-
and
I
couldn't
quite
reach
agreement
on
here-
it
was
between
option
a
and
b
of
having
kind
of
separating
the
the
stream
errors
from
the
connect
errors
or
kind
of
grouping
them
all
into
one.
Big
network
exception
class
any
opinions
there,
and
if
we
should
keep
just
one
one
base
class
or
have
two
well,
so
I
guess
like
we
did
decide
for
the.
D
D
Except
my
my
personal
take
is,
I
should
just
derive
from
I
o
exception,
because
those
two
are
the
ones
that
affect
stream
apis
and
are
somewhat
separate
from
the
other
ones
that
are
really
about
the
connection
api.
So
if
we
have
a
a
network
exception
or
a
connection
exception,
or
whatever
we're
going
to
call
it,
that
defines
the
exceptions
that
come
from
the
connection
apis
and
it's
got
a
an
enum
that
defines
particular
cases.
E
Connection
aborted
can
would
theoretically
also
apply
out
of
because
aborted
and
reset
are
once
things
are
going
right,
and
I
guess
these
others
are
only
about
establishment.
Yes,
well,.
B
So
if
boarded
could
happen
if
you're
doing
an
accept
and
you
dispose
the
socket.
E
E
Multiple
handshake
establishment
protocol
like
you're
you're,
both
streaming
and
establishing
already
yeah.
E
D
A
you
know,
you
first,
you
create
a
tcp
connection
and
then
you
do
the
ssl
handshake
over
it,
and
you
can
imagine
that
the
tcp
connection
succeeds,
but
during
the
ssl
handshake,
the
peer
resets,
the
tcp
connection
and
and
therefore
causes
the
ssl
connection
itself
to
fail
to
to
complete
the
connection
process.
D
E
Yeah,
I'd
probably
go
with
everything
that
feels
like
a
networking
problem,
just
being
network
exception
extends
I
o
exception
and
then
subset
off
that
I
don't
know
that
I'd
make
weird
peers
to
network
exception
for
networking
problems
again,
just
using
the
name,
that's
here.
So
if
that's
the
distinction
between
a
and
b,
because
I
was
looking
for
the
rules
when
we
missed
when
we
scrolled
past
a
I.
I
think
that
I
like,
what's
on
screen
now,
plus
creating
the
derived
types
off
of
this
for
specific
errors,
yeah.
The
reason.
D
E
D
To
explain
option
a
a
bit,
the
the
the
reason,
the
the
logic
behind
option
a
is.
These
are
the
conditions
that
apply
to
using
the
connection
apis,
and
so
you
ought
to
have
something.
If
we're
defining
an
exception
model
for
this,
it
would
seem
to
make
sense
to
have
something
like
connection
exception,
that
defines
the
set
of
of
exceptions
that
are
exposed
from
connection
apis.
E
So
the
the
again,
the
distinction,
isn't
we
don't
care?
Who
throws
a
thing?
We
care
what
you
do
when
you
catch,
and
so,
if,
if
that's
a
thing
that
can
you
know
connection
aborted,
can
pop
out
of
stream.read
or
you
know
networkstream.read?
E
E
Would
be
easier
for
documentation
to
just
be
like
throws
network
exception
if
some
weird
networking
problem
goes
wrong
right
like
and
then
the
see
the
details
of
the
specific
exception
for
what
actually
went
wrong.
E
E
F
D
Basically,
landing
on
option
b
then
that
that
that,
even
though
we
spent
a
lot
of
time
talking
about
derived
exceptions,
we're
basically
going
to
end
up
with
a
new
and
maybe
derived
exceptions
for
aborted
and
reset.
If
we
think
those
are
useful
enough.
A
D
A
A
E
I
mean,
I
think
you
want
to
take
what
what
b
looks
like
plus,
add
some
factories
to
it,
so
that
you
can,
if
you
have
a
factory
method
that
takes
network
error
if
right
now
invalid
address
just
is
return
new
network
exception
of
you
know,
build
format
with
invalid
address
and
later
you've
decided
that
invalid
address
was
worthy
of
its
own
exception
type
that
you
you
have
that
choke
point
that
says
you
were
trying
to
represent
an
invalid
address
error.
We've
made
a
more
derived
type.
E
This
helps
with
catching
in
the
future,
so
I
think
you'd
want,
b,
plus
a
factory
or.
D
E
B
E
B
B
Of
having
a
factory
is
that
in
the
future
we
could
say
we're
going
to
throw
the
new
derived
exception
type.
So
I
think
it'd
be
better
to
just
prevent
users
from
making
the
error
of
not
throwing.
A
Mean
I
would
say
like
to
me:
the
factory
is
more
important
for
your
own
code
internally,
because
realistically
the
servicing
boundary
or
the
the
compat
boundary
is
for
the
framework
right
that
we,
you
know,
are
consistent
with
what
we
throw
right.
If
somebody
else
throws
exceptions,
I
don't
think
it's
that
important
that
they
are
consistent
with
the
rest
of
the
stack,
because
it's
dedicated
areas
anyway
right
so,
like
the
I
mean
yes,
it
would
be
nice.
Everybody
would
be
consistent
here
but
like
if
you're,
not
the
networking
layer
like.
E
E
Could
be
networking
a
networking
concept
in
a
in
a
nuget
package
like
if
some
new
tls,
like
thing
or
somebody
writes
an
onion
resolver
right
like
if
they're
throwing
an
invalid
address
exception
that
there's
no
invalid
address
exception,
like
them,
throwing
new
network
exception
directly
means
they're
not
actually
participating
in
the
future
handlers.
When
we
add
the
new
drive
type,
so
yeah
I'd
go
ahead
and
make
the
constructor
protected
and
and
make
the
factory
be
the
only
way
to
make
this
level
of
the
hierarchy.
B
A
A
E
Yeah
and
as
long
as
there's
the
the
model
of
create
it-
and
you
know
I
am
the
unknown
error-
type-
here's
my
message
as
long
as
you
have
that
somewhere
for
I
someone
who
has
a
a
problem
that
they
don't
think
can
be
represented
with
any
described
you
know.
Member
then
I
think
I
think
you're
good
on
that
regard,
but
it
allows
for
unification
of
future
ones,
for
if
connection
refused
becomes
a
public
type
or
et
cetera,.
B
Okay,
can
we
define
a
public
static,
create
of
network
error
method
on
this
now
and
approve
this.
A
I
mean
it
goes
back
to
like
what
do
you
want
to?
Have
I
mean,
like
my
understanding,
is
you
still
want
to
decide
which
which
things
to
make
exceptions
for
so
I
I'd
rather
you
take
it
offline.
You
know,
make
modify
the
proposal
for
b
flash
it
out.
Add
a
factory
make
the
constructors
that
you
want
protected
and
decide
which
derived
types
you
want
to
have,
but
if
we're.
D
So,
first
of
all,
we
can
always
add
derived
types
later
right
I
mean
we
could
at
least
approve
this
as
far
as
it
goes
and
then
talk
about
if
we
want
derived
types
and
come
back
for
approval
on
those
later.
Secondly,
I'm
not
sure
we
are
actually
wanted
to
find
any
derived
types.
D
I
think
that
at
least
for
now,
if
we've
got
the
enum
that
satisfies
everything
we
want
and
adding
derived
types
is,
is
something
we
could
consider
in
the
future,
but
I
don't
think
it's
it's
important
enough
for
us
to
try
and
force
something
right
now.
Do
you
agree
with
that
query.
E
Yeah,
I'd
essentially
take
what
you
have
as
the
current
public
constructor.
I
would
flip
the
enum
and
the
message
and
then
make
the
message
knowable
or
make
the
message
optional,
where
what
you
really
just
want
to
say
is
yep,
I'm
a
network
exception
connection
refused
and
that
that's
what
I
expect
your
common
path
would
be.
If
you
think
a
custom
message
on
each
connection
refused
is
what
you
would
really
expect
and
feel
free
to
disagree
with
me
on
that
point.
B
D
D
E
It's
protected
sure,
okay
yeah,
but
the
the
factory
method.
I
I
my
gut
is
that
you
would
want
that
people
would
be
more
likely
to
just
say,
connection
was
refused
and
maybe
here's
an
inner
exception
and
that
providing
a
custom
message
seems
less
likely.
E
A
E
F
E
I'd
put
it
as
network.
E
E
Like
the
the
the
constructor
may
be
correct,
as
is,
and
then
just
the
factory
would
be
the
one.
That's
error,
comma
exception,
comma
message.
A
E
M
as
a
practical
question,
can
you
tell
me
the
difference
between
socket
error
host,
not
found
and
socket
error
host
unreachable,
one
of
those
dns
and
the
other
is
buying.
E
Yeah,
so
I
don't
know
that
I
would
call
those
one
item
instead
of
two,
because
one
of
those
is
again
thinking
from
an
application
level.
One
of
them
is,
I
think
you
typed
the
wrong
name
in
this
box
to
connect
to
or
you
you
have,
an
error
in
your
url
and
the
other
one
is
maybe
maybe
you're
in
an
isolated
network
or
maybe
they're
offline
or
so,
since
those
are
different
problems,
you
would
want
to
surface.
I
wouldn't
collapse,
those
two,
so
maybe
it
would
be.
Maybe
ad
host
unreachable.
D
The
the
question
here,
I
think,
is:
do
we
think
that
those
conditions
make
sense
for
anyone
other
than
sockets?
I
mean
it's.
D
E
Thinking
of
something
like
you
know,
complicated
protocols
like
tor
right,
like
invalid
address
could
happen
at
complicated
layers
which
are
different
than
the
sockets,
and
I
don't
know
how
they
actually.
I
don't
know
how
tor
actually
works.
So
I
don't
know
if
there's
a
difference
between
host,
you
know
not
found,
and
I
I
lost
the
routing
in
the
middle
and
and
whatever,
but
but
these
things,
when
I
look
at
them,
I
can
they
feel
generic
like
hey.
E
Something
didn't
work
here
like
versus,
like
a
name:
lookup
failed
versus
a
connection,
failed
versus,
etc.
So.
B
E
E
I
don't
know
what
address
not
available
means,
but
the
things
of
like
this
was
gibberish
at
sort
of
the
nick
level
instead
of
the
dns
level.
All
feel
like
one
big
thing
to
me
in
the
99
case.
F
A
E
You've
got
the
factory
there
and
now,
bringing
in
other
types,
probably
is
something
we
could
even
just
do
over
email
of
hey.
We
want
to
make
you
know,
connection
aborted
exception,
extends
network
exception.
As
a
thing
we
returned
from
the
factory
now
we'll
be
like
great
ship.
It.
A
Alrighty,
so
now
we
are
for
the
remaining
hour
based
on
last
meeting
success,
so
jeremy
missed
out
on
a
bunch
of
discussion,
but
I
can
summarize
it
where
we
landed,
so
let
me
scroll
up
a
little
bit.
So
basically,
the
problem
goes
like
this
right,
so
we
let
me
actually
scroll
back
to
the
top.
It's
probably
easier
to
explain
this
way.
A
So
what
we
have
today
is
we
have
runtime
information
where
we
basically
expose
these
apis
and
then,
as
part
of
the
guarding
feature
we
edit
these
apis
here
the
intent
was
to
say:
well,
we
basically
use
runtime
information
as
the
place
to
do
os
checks,
so
we
should
put
it
there.
The
downside
of
that
approach
is
that
there's
two
issues.
One
of
them
is
it's
an
interrupt
services.
The
intent
originally
was
is
interrupt
services
because
well,
what
do
you
check
for
the
os?
A
Because
you're
going
to
p
invoke,
which
is
not
going
to
be
the
case
for
the
majority
of
users
who
write
guarding
calls,
because
the
idea
is
they
call
os
bindings
which
are
high-level
apis?
Of
course,
the
implementations
of
those
will
most
likely
use
p
invokes,
but
the
user
doesn't
have
to
know
that.
So
if
we
force
down
everybody
to
intro
to
have
a
using
statement
for
interrupt
services,
they
import
a
bunch
of
junk.
We
don't
want
most
people
to
use,
so
it
seems
like
a
bad
decision
to
do
that.
A
A
Then
the
proposal
was
to
say:
okay,
let's
move
them
on
something
like
environment,
because
that's
where
people
do
os
checks
today,
which,
according
to
uses
information
for
os
version,
runtime
information,
you
can
see
how
that
differs,
and
you
know
clearly
the
pi
artist
environment
in
this
case,
environment
has
downsides
too.
Jan
pointed
this
out
in
the
comments
as
well
that
it's
kind
of
a
dumping
ground
for
a
bunch
of
stuff
that
we
added
over
the
years.
A
A
That
will
be
the
you
know
these
two
methods
here,
but
then
people
said
well,
you
know
what
you
really
want
to
write.
Is
you
want
to
have
strongly
typed
apis?
You
don't
want
magic
strings,
so
what
people
really
want
to
have
is
basically
helper
methods
per
operating
system,
where
you
just
say,
is
android
or
is
android
version
at
least,
and
that's
where
we
landed
on
this
shape
that
you
see
right
now
that
was
kind
of
the
the
takeaway
from
last
time,
I'm
still
not
in
love
with
environment.
A
I
can
live
with
environment,
given
that
it's
not
too
bad.
It
has
like
20
members
today.
I
think-
and
all
of
those
here
would
be
somewhat
nicely
grouped
with
the
is
prefix.
The
only
other
is
methods
we
have
are
checking
for
architecture,
and
they
are,
I
feel,
like
very
related
to
you
know.
What
thing
are
you
running
on
right
now,
which
is
basically
what
these
apis
all
help
to
answer,
so
I
don't
think
it's
that
bad.
I
mean
the
naming.
A
Conventions
are
a
bit
odd,
thanks
to
the
fact
that
we
have
lower
cased-
or,
I
guess
camel
case
platform
names,
but
I
don't
know
whether
we
feel
strongly
enough
to
fix
that.
But
that's
what
we
have
now
if
things
get
added
in
the
future,
I
can
totally
see
us
adding
more
members
here.
I
would
generally
defend
this.
A
The
approach
to
say
if
we
feel
an
operating
system
is
important
enough
for
us
to
add
a
member
on
os
platform.
We
should
totally
add
you
know
the
two
methods
here
as
well
and
similar
to
west
platform.
We
have
this.
You
know
primary
apis
or
fallback
apis
where
you
can
always
write
the
code,
even
though
you
don't
have
static
methods
for
the
operating
system,
because,
let's
say
you
target
the
lower
version
of
net
five,
for
example
right,
so
that's
pretty
much
it
so
do
people
have
any
questions,
comments
or.
A
But
I
guess
in
this
case
it's
defendable,
because
if
they
get
it
wrong,
they
get
a
squiggle
in
the
ide
and
if
they
invoke
the
fixed
level,
the
fixer
will
tell
them
what
to
do.
We
don't
have
the
fixer
yet
we'll,
probably
not
ship
one
and
five-o
either,
but
I
guess
that's
the
experience
that
we
pursue
long-term.
So
I
am
personally
okay
with
that,
because
we
tell
people
what
the
correct
code
is
and
we
saw
them
at
compile
time,
but
then
they
got
it
right.
E
Right-
and
I
guess
that
is
the
relationship
we
had
before,
which
is
that
the
the
boundary
condition
like
it
was
less
than
or
greater
than
or
equal
to
on
one,
and
it
was
less
than
on
the
other
and.
F
G
A
E
B
G
Okay,
okay,
so
the
yeah,
so
you
have
okay,
let's
checks
for
guardian
with
comparison,
it's
less
than
okay,
so
it
was
just
a
shorthand
before
I
guess
to
do
those
two
things
combined
right:
okay,.
A
I
mean
it
is
easy
on
the
analyzer
right
so
like
the
one
thing
that
I
haven't
really
looked
into
this,
yet
we
can
probably
talk
about
this
more,
but
my
understanding
is
that
the
way
these
checks
are
exposed
in
the
flow
analysis,
you
don't
see
a
compound
check
right.
What
you
end
up
seeing
is
you
see
one
node
that
has
multiple
incoming
arrows
and
so
each
of
those
arrows
basically
has
a
label
corresponding
to
all
the
conjunctions
right,
and
then
you
have
different
arrows
coming
in.
If
you
have
disjunctions
right,
so
that's
it's.
A
It
might
not
be
the
most
convenient
form
in
the
analyzer
to
check
these
things,
but,
as
somebody
else
pointed
out
like
we
should
try
to
make
it
right.
E
So
yeah,
my
my
gut
here,
since
you
called
me
out
specifically,
is
having
had
the
the
wonderfulness
of
missing
the
first
half
of
this
is,
if
we
I
know
we
generally
don't
like
nested
types,
but
if
nested
type
calling
is
because
really
we
don't
like
instances
of
nested
types,
but
if
nested
type
calling
is
sensible
in
all
of
our.
E
Then
I
was
gonna
say
in
all
languages,
but
I
have
literally
no
idea
how
you
do
anything
in
cobol.net,
but
that
that
maybe
we
won't
like
environment.os
dot
and
then
ask
these
things.
Just
so,
environment
doesn't
get
itself
too
cluttered
and
it,
and
it
focuses
all
of
the
things
that
are
os
versus
environment
variables
and
command
line
arguments
and
things.
A
E
No,
so
I
would
put
all
these
at
like
on
operating
system
just
as
static
as
android
static
is
android
version.
At
least
I
wouldn't
make
different
subtypes
for
the
different
families.
It's
just
making
sure
that
environment
doesn't
like
the
other
common
thing
for
environment
is
good
environment
variable
and
just
make
it
so
that
there's
not
so
much
clutter
that
you
don't
even
see
that
there.
A
C
B
I
feel
like
if
you're,
if
I'm
developing
a
library
for
net5
I
would
probably
want
to
use,
is
os
platform,
even
if
I'm
if.net
6
is
out,
and
it
supports
some
other
os
or
platform
to
check
on.
I
would
still
probably
just
target
net
five
and
use
a
string
there.
D
A
A
All
the
ones
that
you
see
on
screen
right
now,
so
basically
that's
all
the
ones
we
know
of
that.
We
want
to
support
in
by
six
right.
So
it's
a
yes!
There
will
be
cases
where
you
can't
do
that,
because
I
don't
know
we
do
some
other
fancy
stuff
that
we
haven't
even
thought
about
yet,
but
you
know
the
expectation
would
be
that
mainline
code
would
get
away
with
static.
Typed
calls
right.
B
A
B
What
about
having
these
just
be
some
const
strings
somewhere,
rather
than
an
is
method.
A
You
could
I
mean
the
argument
that
liver
had
last
time,
which
I
kind
of
buy,
is
that
it's
just
shorter
and
it's
also
discoverable
the
problem
with
string.
Literals
is
also
like
you,
don't
really
get
told
where
they
are,
because
you
don't
have
a
type
to
look
for,
but
it's
like
well.
Does
anybody
have
a
const
with
a
string
somewhere,
like
you
kind
of
have
to
wire
this
up?
That's
kind
of
why
the
strongly
typed
enum
that
we
have
os
platform
was
nice.
A
The
problem
with
os
platform
is
that
we
put
interweb
services
so
similar
to
runtime
information.
We,
I
don't
want
to
loop
this
thing
in
for
mainline
checks
and-
and
I
think
the
methods
are
just
shorter
to
write.
I
think
the
nested
types
would
be
not
too
bad
because
you
just
insert
a
dot
somewhere
but
like
it
would
be
the
same
number
of
characters.
B
Make
the
is
methods
jit
intrinsics,
if
we
really
wanted
to
at
some
point
to
reduce
the
code,
we're
compiling
so
maybe
they're
better
anyway.
B
E
Right
I
mean
like
certainly
the
you
know
at
the
level
that
we
would
be
building
things
differently
here.
We
know
we
have
a
different
system
or
a
system
private
core
lib
for
windows
and
non-windows.
So
the
all
the
other
things
would
just
say,
return
like
we
could
make
them
say,
return
false
and
then
the
jet's
going
to
immediately
fold
any
calls
that
they
do
because
that'll
be
a
const
that'll,
get
promoted
to
constant,
tiered
jitting
will
just
start
dead,
dead
code,
you're,
moving
left
and
right.
E
If
they're
calling
the
the
the
methods
and
not
passing
in
the
string,
the
one
where
we're
passing
in
the
string
means
it
needs
to
do
logic.
So
there
is,
there
is
value
for
having
the,
not
the
non-argument
ones,
whether
that
be
through
operating
system.mac,
os
dot
is
running
or
or
what
but
yeah.
Because
I
think
that
this
you
know
the
moving
things
into
a
higher
in
level
is
reasonable.
I
would
possibly
also
just
add
the
is
os
platform
os
platform
unless
we
have
a
layering
inversion
problem.
E
I
wouldn't
do
it.
For
that
reason,
if
they
were.
F
C
A
C
A
A
A
A
A
A
If
you
have
a
grouping
in
between
it,
removes
some
of
the
noise
and
then
basically,
once
you
understand
how
one
of
the
types
works,
you
know
all
types
work
right
and
then
the
last
part
is
just
the
spelling
is
slightly
less
problematic,
because
if
you
have
operating
system,
dot,
mac
os
of
a
lowercase
m,
it
doesn't
read
quite
as
bad
because
you
have
to
put
a
period
in
between.
Like
is
mac
os
with
like
lowercase
s
next
to
lowercase
m
looks
weird.
A
Capitalizing
m
has
other
problems,
because
that's
why
we
haven't
done
it
on
runtime
information,
either
sorry
on
os
platform
either.
But
that's
that's
the
naming
the
biggest
downside,
but
maybe
we
don't
care.
Maybe
we
just
capitalize
the
letters
and
we'll.
A
So
the
first
point
is
basically
the
the
the.
If
you
look
at
the
number
of
methods
or
members
that
operating
system
has,
if
you
introduce
basically
one
type
operating
system
in
between
you,
move
the
methods
all
down
by
one
level,
which
now
means
the
top
level.
Things
on
top
of
operating
system
is
basically
just
one
type
of
operating
system,
rather
than
a
number
of
methods,
times
operating
system
right.
So
right
now
we
only
have
two,
but
god
forbid,
we
either
add
a
third
one
which
we
might
right.
E
A
A
Well,
it's
basically
just
maybe
hierarchy
is
the
wrong
word,
but
it's
basically
a
group
by
area,
but
you
basically
have
one
grouper
accelerator
right.
You
have
android
ios
mac,
os
tv,
os
watch,
os
windows
and
then,
as
I
said,
just
demonstrate
the
browser
freebsd
linux.
It
doesn't
make
sense
if
the
for
the
for
version
accelerators
for
those,
because
they
don't
really
have
the
notion
of
a
version.
A
B
Also,
a
a
great
history
of
checking
for
specific
browser
versions.
Well,.
F
E
Yeah,
I
don't
like
because
right
now
adding
I
mean
I
agree
on
the
the
brand
casing
that
it
that
it
would
make.
You
know
you
would
go
to.
B
A
A
E
A
A
C
E
I
guess
it
won't
necessarily
well,
I
guess
it
would
be
amortized
one,
because
even
on
a
on
a
build
that
doesn't
know
if
it's
watch
or
tv
or
ios
that
it
can't
figure
that
out
until
runtime,
it
should
only
need
to
load
it
compute
it
once
so.
The
cc
tour
would
decide
which
of
those
three.
It
is
and
and
answer
that
but
yeah,
I'm
okay
with
either
method
or
property.
E
A
E
C
E
E
A
Yeah
I
mean
to
be
fair.
I
think
that
if
we
put
it
on
operating
system,
I
think
I
don't
actually
care
how
many
there
is,
because
I
mean
realistically
that
list
the
list
of
platforms
would
never
be
like
200
right.
It
will
be
like
you
know,
let's
be
generous
and
say
20
or
30
right
and
having
60
members
on
a
type
is
not
like.
You
know.
The
world
is
ending.
E
Right
but
on
on
environment,
I
would
think
it's
weird
that
there's
60
members
for
asking
os
version
questions
and
then
the
the
what's
my
current
working
directory
and
go
find
this
environment
variable
or
sort
of
just
buried.
Next
to
that.
A
But
so
maybe,
if
you
put
it,
I
mean
I
mean
it's
similar
to
ui
controls.
But
if
you
go
to
let's
say
text
box
in
winforms
right,
you
will
probably
have
60
methods
easily
right
because
there's
like
a
property
for
freaking
everything
right.
So
the
and
it's
generally
not
a
problem.
I
mean
it's
a
you
know,
that's
just
what
the
what
the
type
is
for
right-
and
I
think
here
it's
the
same
thing.
If
you
say
operating
system
is
just
for
check
operating
systems.
It
makes
sense
if
it
lists
everything
we
have
supported
right.
A
So
that's
and
then
over
time.
If
things
just
get
out
of
fashion
because
we
dropped
support
for
it,
let's
say
in
some
hypothetical
future
world
we
stop
caring
about
windows
entirely.
Maybe
then
we
just
edit
our
browser,
we'll
hide
windows
and
say
like
yep,
the
api
existed
in
the
past,
but
the
operating
system
is
going
to
support
it.
So
there's
no
point
of
asking
those
questions
and
that
I
think,
is
reasonable
right
and
then
we
would
yeah.
A
C
C
A
C
E
A
A
A
E
Yeah
I
mean
I
guess,
because
if,
if
we're
already
having,
if
all
the
types
that
we're
going
to
have
statically
known
about
in
os
platform
are
already
going
to
be
represented
here,
then
there's
probably
not
more
value
or
not
a
lot
of
value
left
in
that
strongly
type
string,
which
may
mean
that
we
deprecate
it
in
favor
of
this
one
I
mean
we
obsoleting.
It
is
probably
painful
because
it's
a
net
standard,
two
type.
A
Yeah,
I
mean
absolutely
like:
let's
take
obsoleting
kind
of
like
on
the
side
for
a
second,
let's
just
first
decide.
Are
we
stopping
evolving
that
because
I
mean
so
first
thing:
is
we
added
a
bunch
of
members
to
os
platform,
specifically
the
ones
that
listed
here
as
well
like
android,
ios,
mac,
os
tv,
os,
virtual
browser,
and
so
if,
if
we
basically
say
we
put
these
as
helper
methods
on
operating
system,
I
would
actually
go
in
and
delete
the
memory
somewhere's
platform.
B
E
Yeah,
I
don't
how
long
ago
did
we
add
them.
E
C
F
E
Operating
system
is
the
only
place
we
put
things.
I.
A
E
A
E
I
don't
know
because
I
don't
remember
the
I.
F
B
E
Yeah,
I
don't
know
xamarin
guys
could
probably
tell
us,
but.
A
A
E
Yeah
it
looks
like
foundation
version
is
ns
foundation
version
number
underscore,
ios
underscore
six
underscore
one:
that's
how
they
got
did
all
their
pound
defines.
So
as
as
you
suggested
emo.
It
was
an
underscore
to
indicate
why
there's
a
lowercase
letter
here.
E
Yeah,
I
would
leave
the
os
version
as
brand
casing,
because
we
can
and
then
do
pascal
conversion
here,
because
readability
right.
C
E
Sorry,
if,
if
we
think
that
they're,
if
we
think
that
they've
existed
for
a
short
enough
time,
that
people
haven't
already
started
using
them
in
this
preview,
but
given
that
we're
like
at
the
end
of
the
release,
I
would
say
it
would
be
fine
for
both
of
them
to
be
represented.
E
If,
if
we
had
definitely
if
we
had
done
it
like
for
the
first
preview
of
five,
I
would
say:
don't
remove
it
now,
it's
it's
not
worth
the
the
breaking
change
to
upgrade
of
the
wonderful
people
who
try
our
stuff
before
it
goes
public
or
before
it.
A
Yeah,
I
think
it
was
very
recent
I
mean
like
that's
why
I
think
it's
fine
to
yank
them
out.
The
thing
is
with
yanking
out,
though,
like
yeah.
What
so,
I
think
we
can
say
if
we
yank
them
out,
we
yank
them
out
if
we
leave
them
and
we
leave
them
in
with
the
casing
they
have.
Otherwise
it
also
kind
of
defeats
the
point
of
leaving
them
in
because
it
would
be
for
compatibility,
and
if
you
change
the
casing,
it
will
break
that
too.
A
So
I
think
that
seems
like
a
reasonable
middle
ground.
So
then
I
think
the
conclusion
is:
let's
try
to
yank
it
out
and
see
whether
we
can
pull
that
off
and
then
we
would
say
we
would
not
put
it
on
environment.
We
put
it
on
system
operating
system,
aesthetic
members,
and
are
we
happy
with
the
shape
that
I
proposed
so
basically.
E
So
what
you
have
on
screen,
but
environment
becomes
operating
system
and
we
we
pascalify
all
the.
A
E
A
E
Do
so
going
back
to
the
platform
compat
with
with
hierarchy
or
whatever
do
we
expect
that
anyone
should
want
to
check,
is
ubuntu
2004
or
do
we
think
that
really
they're
just
only
likely
to
ask
the
generic
linux
question.
A
No,
I
think
they
might.
I
mean
the
question
is:
how
would
that
work?
I
think
we
could
decide
that
we
make
that
work
already
by
you
know.
If
you
ask
on
ubuntu,
and
you
use
the
string
ubuntu,
we
could
say
the
isos
platform
resource
platform
version
at
least
would
give
you
the
correct
answer,
and
then
we
could
expose
the
accelerator
as
well.
It's
just
nobody
else.
B
Isn't
that
missing
how
linux
works,
though
I
mean
I
feel
like
this
should
check
the
kernel
version
and
well.
B
Checks,
yeah
no.
A
But
that's
what
I'm
looking
for
like
temperature
releases,
so
I
think
no,
I
think,
there's
two
sides
here
right
so
there's
the
version
checks
only
make
sense
when
the
thing
you're
testing
is
actually
versioned
by
a
single
party
right
so
like,
I
think,
for
example,
posix
you
could
argue
well,
it's
basically
asking
which
version
of
posix
do
you
use?
Does
the
current
operating
system
support
or
which
which
which
part
of
the
spec
do
you
implement
right?
A
I
don't
know
what
what
what
else
is
there
like
susan
when
it
still
existed?
They
are
similar
to
windows
right
they
they're
released
by
one
party
they're
versioned
by
one
party,
so
ubuntu
1804
is
a
is
a
very
you
know,
well-defined
thing
and
you
can
say
well.
A
Are
you
8,
04
or
not
right,
and
I
think
that's
that
seems
reasonable,
but
because
you
can
actually
make
assumptions
about
the
operating
system
at
that
point,
if
I
know
they
run
this
version
of
the
kernel
like
yeah,
I
may
know
which
kernel
api
is
to
call,
but
the
vast
majority
of
problems
that
we've
tried
to
solve
here
is
in
user
land
and
so
like.
What
do
you
know
about
the
user
mode?
What
version
of
open
ssl
they're
running?
If
you
know
the
linux
kernel
version
like
there's,
not
much,
you
can
do
with
that.
B
C
E
C
E
C
A
E
You
made
the
mistake
of
saying,
open
ssl.
They
had
breaking
changes
in
their
api
and
abi
between
1011
and
30,
right,
which
for
ubuntu
is
1604
1804
and
2204..
A
Yeah
to
me
this
kind
of
so
I
think
that's
the
other
reason
why
I
think
jan
has
always
said
like
you
need
to
ask:
you
need
to
be
able
to
ask
for
the
actual
version
number
as
well,
because
sometimes
you
have
to
fingerprint
it
say
like.
I
know
this
version
of
the
operating
system
or
the
later
version,
but
this
particular
version
is,
is
has
this
behavior
that
I
have
to
somehow
you
know,
recognize
and
and
and
quirk
right,
and
sometimes
you
get
away
with.
A
You
know,
actually
checking
for
you
know,
load
library
can
actually
load
the
library
or
whatever
right,
but
sometimes,
if
they
did,
they
have
to
like
you,
you
know,
use,
you
know,
use
an
os
check,
but
but
it
seems
to
me
we
would
be
handling
those
cases.
By
saying
we
have
generic
query
apis
for
any
opera
operating
system,
and
I
think
it's
reasonable
for
ubuntu
and
red
hat
to
respond
to
red
hat
plus
version
number
or
ubuntu
plus
version
number
and.
A
Like
on
the
wise
version,
here,
you
get
the
actual
operating
system
version,
as
reported
by
whatever
you
name
or
win32
apis.
But
those
are
not
the
main
scenarios.
We
expect
mainland
scenarios
to
be
going
with
accelerators
because
those
have
generally
well
defined
behavior,
and
you
generally
avoid
all
the
you
know.
The
craziness
that
is
package
managers
and
breaking
changes
from
the
operating
system.
E
I
will
just
add,
given
that
we're
putting
all
these
static
things
on
operating
system-
and
you
just
mentioned
that
sometimes
it's
useful
to
get
the
exact
version
which
is
being
reported
from
operating
system.
That's
an
instance
property
that
I
don't
see
how
you're
supposed
to
get
it.
So
would
we
want
to
add
a
current
version
and
current
version
string
static
accelerator
on
the
type
you
can.
A
E
A
I
mean
I
I
would
generally
say
I
would
not
move
it
here
simply
because
if
you
have
it,
people
will
use
it,
but
we
generally
don't
want
them
to
use
it,
but
we
generally
want
people
to
use
these
accelerators
because
of
the
open-ended
checkness
and
we
can't
change
environment.
So
I
would
just
you
know
of
course
leave
it
there
and
then
say:
if
you
really
need
to
do
something
crazy,
because
you're
part
of
the
bcl
team
or
you're
just
you
know
some
crazy
interrupt
guy,
then
by
all
means
do
it.
E
Right
so
we
make
the
convenient
things
for
am
I
this
os
family
and
am
I
at
least
this
version,
because
that's
the
essentially
feature
detection
and
then,
if
you
really
care
about
also
doing
the
upper
bound,
you
can
either
add
the
static
knot
or
you
can
just
read
the
version
property
yourself,
which
you
have
to
do
a
little
bit
more
work
for,
but
that's
okay,
because
it's
possible
it.
It
doesn't
need
to
be
easy.
All
right,
that's
seems
sound.
A
A
A
A
Yes,
it
should
and
the
reason
I
said
it
is
for
existing
code
because
that's
the
same
reason
why
we
relaxed
rules
earlier
for
windows.
Right
to
say
it
should
be
okay
to
put
an
attribute
on
the
method
without
a
version
number,
because
it
means
0.0
and
maybe.
A
C
A
A
Well,
I
mean
the
way
I
would
write
it.
I
would
just
say
like
this,
you
know
is
the
is
the
type
operating
system
is
the
method
starting
with
is
or
whatever
the
string
comes
after
is
the
operating
system
right,
except
for
the
version
at
least
right
like
that's,
and
then
you
just
compare
the
strings
you
might
would
say.
Well,
if
is
the
is
the
inner
member
you
pass
to
isos
platform?
A
You
know
you
take
that
string
of
that
member
name,
and
you
just
say
it's
a
compare
ordinal
to
whatever
the
project
settings
were
right.
So.
E
A
Yeah,
we
would
do
so.
I'm
sorry,
I
mean
ordinal
ignore
case,
but
like
fair
enough,
but-
and
I
think
we
have
some
special
handling
to
say.
Mac
os
and
osx
are
considered
the
same
for
compatibility
reasons
with
the
past,
but
like
yeah.
Those
are
the
kind
of.
F
C
A
Cool
so
then,
I
think
this
covered
all
the
controversial
parts
from
last
time.
E
Yep
and
then
we
also
the
the
methods
that
we're
removing
the
is
version,
at
least,
that
we're
moving
off
runtime
information.
E
Again,
we
feel
comfortable
with
that
being
not
I
mean
it
is
a
breaking
change
for
anyone
who
called
it,
but
we
don't
feel
that
it
will
be
too
disturbing
for
our
preview
users
like
it's
not
like
everybody's
writing,
these
checks
in
every
method
they
write
so.
C
E
Yeah,
I'm
just
thinking
out
loud
of
making
sure
that
we're
not
punishing
people
for
using
previews
by
moving
something
at
the
last
minute.
I
know
we
reserve
the
right
to
I'm
just
making
sure
that
we're
comfortable
with
the
decision.
I
think
we
are
I'm
just
asking
it
to
make
sure
the
email
really
feels
that
way.
A
E
Yeah
I
mean
if
it
was
the
thing
that
that
essentially
everybody
who
was
using
five
already
would
be
doing,
and
we
had
added
it
in
the
first
preview.
Then
I
would
think
that
it
might
be
too
just
too
disruptive
to
move
it
now
if
we
were
entirely
removing
it,
because
we
thought
it
was
a
bad
feature.
That
would
be
a
different
argument
but
yeah.
I
I
think
that
we're
probably
good
doing
it,
I'm
just
making
sure
that
we
understand
the
risk
reward
of
moving
it
at
this
time.
A
I
honestly
think
the
only
risk
we
realistically
have
is
like
building
our
own
stack.
Somebody
will
probably
have
at
least
used
one
of
them
somewhere
right,
but
that's
a
normal
build
break
that
I
don't
think
the
vault
will
end
when
we
do
that
and
it's
it's
a
pretty
straightforward
thing
and
then
yeah
for
customers.
We
generally
tell
them
like
previews
are
previous.
I
mean
the
whole
point
of
shipping.
Them
is
to
react
to
customer
feedback.
A
Indeed,
and
this
one's
we
haven't
really
advertised,
so
I
would
be
shocked
with
lots
of
usages
there.
So
the
only
open
thing
that
we
still
probably
want
to
talk
about
at
least
quickly
is
the
attributes.
So
we
talked
about
this
last
time.
So
originally
my
proposal
was
to
put
them
all
in
system
runtime.versioning.
A
Then
eric
said
he
wants
to
have
them,
basically,
where
the
methods
are
and
the
methods
were
basically
interrupt
services
we
proposed
to
move
them
there,
then
we
said
well,
like
that's
all,
not
great.
Let's
move
them
then
to
system,
and
then
I
said:
well,
we
don't
want
to
move
so
too
much
into
system
either.
A
So
basically,
the
compromise
we
landed,
in
was
to
say
we
will
put
the
attributes
that
people
are
expected
to
apply
in
system
which
would
be
three
not.
The
two
here
would
be
supported,
unsupported
and
obsoleted
in
and
then
we
would
move
the
target
platform
attribute
and
the
os
platform
attribute
the
abstract
base
type
in
system
runtime
versioning,
because
those
ones
nobody
cares
about
right.
This
one
only
exists
in
the
docs
so
that
you
can
click
on
them
and
you
generally
don't
click
on
the
name
space.
You
click
on,
let's
say
unsupported.
A
You
see
the
base.
Tab
is
wise
platform.
You
click
on
that
one
and
you
see
the
derived
type,
so
the
name
space
there
doesn't
really
matter
too
much
and
then
target
platform
attribute
is
the
same
thing.
It's
like
it's
applied
to
the
entity
assembly
automatically.
You
basically
never
use
it
unless
you
open
the
thing
in
il
spy.
You
just
see
that
oh
target
platform
was
windows
cool,
that's,
basically,
the
only
reason
why
we
have
it.
So
I
think
those
team
make
sense
to
me
in
versioning
and
then
those
make
sense
in
system.
E
It
yeah
it
sounds
reasonable.
I
know
that
we
didn't
so
just
you
know,
saying
the
the
alternative
part
of
why
we
moved
the
things
out
of
runtime.
Versioning
was
because
anyone
using
the
attributes
was
also
going
to
be
calling
the
methods,
basically
right,
and
but
do
we
think
that
calling
the
method
means
you're
using
the
attribute.
A
Sort
off
so
the
so
the
I
think,
the
so
there's
two
sides
to
it
right.
I
think
it's
okay
to
have
a
using
statement.
If
you
use
the
attribute,
because
you
know
auto
completion
and
stuff,
so
I
don't
think
it
would
be
terrible
if
you
would
leave
them
in
runtime
versioning,
it
would
be
terrible
to
use
them
in
a
drop
services
right,
but
that's
already
taken
care
of
by
moving
the
methods
out
of
there.
A
A
So
I
will
basically
just
forward
the
checks
to
my
callers,
but
instead
of
them
calling
20
methods,
you
only
have
to
call
maybe
one
method
or
instantiate
one
type
and
call
a
method,
and
so
in
that
sense
you
will
very
likely
end
up
having
to
mark
your
own
stuff
with
these
attributes,
and
so
yes,
I
think
there
will
be-
I
mean,
maybe
not
every
single
time
we
do
it.
But
you
know
I
don't
know
at
least
50
60
of
the
cases.
You
will
probably
end
up
marking
the
some
some
part
of
your
code.
G
E
A
Mean
system
one-time
versioning
is
relatively
clean,
namespace.
It
has
like
five
types
in
them
so
doing
that
wouldn't
be
bad,
but
we
have
to
understand
that
effectively
by
no
means,
if
you're
doing
ios
development,
virtually
large
chunks
of
your
copays
will
have
a
using
for
that
namespace,
which
might
be
okay
right.
I
mean
the
same
with
networking
and
other
stuff,
but,
like
you
know,
eric
didn't
like
the
name,
I
think
it's
not
too
bad,
because
it's
not
really
how
the
runtime
itself
is
versioned,
it's
more
like
what
features
does
the
runtime
offer
for
versioning?
A
That's
how
I
read
the
name
and
then
I
think
it's
fine
to
have
os
platform
stuff
in
there.
I
think
it's
not
too
bad
to
have
them
there
from
the
point
from
then,
whenever
and
intellisense
standpoint
it
will
auto
complete
anyways
and
in
many
cases
people
will
use
the
code
fixer.
You
know
once
we
have
it,
so
I
don't
think
it
would
matter
too
much,
but
I
I
do
see
the
argument
for
you
know
operating
system
is
in
is
in
system.
E
Personally,
I
have
a
slight
preference
for
putting
all
six
types
in
system-
runtime
versioning,
but
I
if,
if
anyone
wants
to
say
well
the
three
you
you
should
really
be
in
system
to
be
next
to
operating
system,
then
I'll
say:
okay,.
E
E
Yeah,
those
should
be
out
of
the
way
there
there.
Those
should
not
go
into
system
the
the
three
that
people
use
yeah
I
if
we
want
to
avoid
cluttering
system
having
them
be
in
system
runtime
versioning
is
fine.
E
You
can
always
avoid
the
using
statement
and
explicitly
qualify
your
attributes
right,
but-
and
I
don't
think
it
would
be
terrible
for
them
to
be
mixed
in
that
case,
because
it's
the
problem
before
was
going
to
be,
you
need
a
using
for
interrupt
services
and
for
versioning
you
probably
already
have
a
using
per
system.
I
mean
you
can
not
have
one,
but
you
probably
already
have
one
so
we're
not
adding
two
namespaces
to
solve
the
problem,
we're
adding
one
namespace
to
solve
the
problem
and
to
me
that's:
okay,
that's
why
I'm!
C
A
C
F
C
A
So
then,
let
me
make
a
proposal
here,
because
we
very
rarely
have
the
problem
that
we
put
something
in
system
and
so
that
we
put
ins
that
we
didn't
put
something
in
system
and
afterwards
wish
we
had,
but
we
very
often
have
the
reverse
problem.
So
unless
we
feel
super
strongly,
they
should
go
in
system.
I
would
say:
let's
put
them
in
versioning,
because
you
know
system
is
not
the
name
space
that
needs
more
types,
and
I
think
that's
given
that
versioning
is
a
relatively
clean
name
space
and
doesn't
really
pollute
your
intellisense.
C
A
A
I
think
stuff
like
that.
I
think,
like
anything
that
is
like
declarative
attributes
or
facilities
to
read
data
about
versioning
right,
whether
it's
os
platform
I
mean
I
could
imagine
if
you
ever
have
read
with
based
query
apis
that
would
or
with
you
know,
maybe
not
query
apis
but,
like
you
know,
any
sort
of
things
that
encapsulate
its
logics
in
some
way.
Might.
F
A
A
G
C
E
All
right
all
the
attributes
system,
runtime,
versioning
or
system
runtime
version,
whatever
it
is,
and
the
methods
move
to
statics
on
the
operating
system
class.
E
C
Do
want
to
kind
of
just
hammer
again
on
the
runtime
information
plan
about
like
what
are
what
is
our
uber
plan
with
that
thing,
because
we
did
add,
like
the
the
runtime
identifier
to
it
in
5.0
right.
This
is
how
you
get
the
rid
of
the
current
machine
like
are,
we
saying
is
our
plan
of
record
runtime
information
is
basically
no
more
we're
not
making
any
more
investment
in
it.
A
I
mean,
I
would
say,
like
you
know,
there's
some
things
on
it
that
we
don't
have
anywhere
else
right.
We
have
these
diagnostic
strings.
For
example,
I
mean,
unless
there's
a
super
strong
need
why
they
need
to
move
somewhere
else.
I
wouldn't
go
out
of
my
way
to
move
them
somewhere
else.
Just
so
I
can
deprecate
the
type
I
I'm
personally,
okay
with
saying
the
planets
we
don't
add
to
it
and
if
there's
still
stuff,
that
is,
you
know,
and
some
hk
is
necessary
to
be
used.
C
A
A
C
A
C
A
This
seems
to
be
the
final
plan
that
sammy
just
post
to
comments.
What
I
have
we
agreed
to
move
all
attributes
to.
A
A
E
No,
this
is
this
is
the
same
thing
that
happened
last
week,
where
your
broadcast
internally
has
stopped.
Okay,.
A
A
A
E
Not
introducing
we're
only
introducing
a
preview
breaking
change,
not
a
not
a
major
version,
breaking
change.
B
A
A
On
the
attributes
yeah
we
it-
we
went
back
and
forth
on
this
one
like
I,
I
personally
stopped
caring
honestly,
because
it
kind
of
depends
on
your
viewpoint.
I
guess,
because
in
the
project
file
we
call
it
target
framework
and
then
has
a
version
number
in
it
right.
So
I
think
name.
F
E
Yep,
that's
fine,
I'm
just
making
sure
that
that
was
where
we
landed
and
that
you're
not
rewriting
history
by
just
copying
and
pasting
what
you
wanted
to.
A
E
It's
still
the
name
of
the
check
that
we
had
we're
not
using
the
the
accelerator
type,
but
I
mean
it's
possible
that
the
feedback
that
we'll
get
from
later
is
that
people,
the
people
who
are
using
the
strings.
They
may
still
want
the
strongly
typed
string
and
we
may
end
up
moving
os
platform
to
system
run
or
system
private
corelib
just
to
help
out
with
that
and
and
then
it
all
still
makes
sense.
But
I
wouldn't
do
that
as
part
of
this
release.
Yeah.
A
A
Right,
I
can
live
with
that
too.
All
right.
So
then
let's
say
this
is
it?
Let
me
approve
this
guy
and
then
we
made
some
good
progress.
A
Controversials
somebody
in
chat
this
support
suggested.
The
idea
is
computer
operating
system.
Android
is
computer.
That
means
similar
to
his
all
right.
So
then
this
is
it
for
today
and
then
I
see
you
on
thursday.
I
think
right.