►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Hello
friends,
I'm
our
substitute
emo
for
today
and
we're
doing
just
another
backlog
review.
We
have
enough
blocking
issues
that
that's
probably
all
we'll
get
to
today,
but
gotta
start
somewhere.
A
B
B
B
A
Yeah,
so
I
like
looking
at
the
options
that
exist
on
file
options
like
delete
on
close
and
encrypted
like
they,
they
make
sense
for
create,
but
some
of
them
do
feel
a
little
weird
for
like.
A
A
A
A
D
A
F
A
So
I
guess
that's
all
of
these
things
are,
these
are
just
accelerators
for
existing,
yes,
like
calling
open
is
just
calling
it
with
actually
opens.
The
weird
calling
open
read
is
just
calling
it
with
file
access,
dot,
read
and
okay,
because
yeah
my
my
one
concern
was
just
going
to
be
how
much
of
this
enum
doesn't
make
sense
for
these
operations,
but
they're.
A
F
A
F
It
does
not
need
to
be
a
regular
file,
it
can
be
a
type
like,
for
example,
on
linux.
You
could
have
a
path
pointing
to
standard
input
or
output,
but
that
would
still
open
with
file
stream.
F
G
E
Like
I
think,
functionally
speaking,
there's
nothing
preventing
you
from
setting
up
a
pipe
that
redirects
to
an
http
server
or
a
unc
chair,
or
anything
like
that.
There's
there's
nothing
preventing
someone
from
doing
that.
I
don't
think
you
can
directly
pass
in
like
an
http
address
to
the
path,
though.
E
F
F
H
A
Right,
well,
I
mean
like
two:
options
are
one
you
are
in
the
flag
and
the
other
is
if
they
pass
the
file
options
you
just
take
whatever
they
give
you
and-
and
you
just
have
slightly
different
paths
between
the
two.
It's
really
just
a
question
of
this
is
a
api
implementation,
not
really
dissociated
so
making
sure
that
we're
aware
of
the
consequences
before
we
add
it.
G
F
It's
it's
going
to
work,
it's
just
a
hint
operating
system
about
how
you
are
going
to
use
the
file
and,
for
example,
if
you
specify
random
file
access
on
linux,
the
os
is
not
caching
the
data,
if
you
don't
it's
caching
it
so
it's
just
a
hint
and-
and
we
could
do-
I
think,
like
if
user
haven't
asked
for
random
file
access
on
purpose,
we
can
r
the
sequential
squad
scan.
A
H
I
have
a
question
and
it
relates
to
the
other
five
stream
api
that
we
are
proposing.
The
other
api
proposed
proposal
is
adding
another
argument
to
file
file
info
second
screen
reader
as
well.
H
So
I
was
wondering-
and
I
left
the
questions
there
if
it
would
make
sense
to
instead
pass
a
class
that
grabs
the
element.
H
H
E
I
I
think
a
struct
would
be
better.
It
avoids
the
allocation
while
still
allowing
the
same
thing
for
these
scenarios,
but
I
think
that
depends
on
how
much
more
we
think
this
is
going
to
expand.
F
So
if
you
switch
to
the
fourth
tab-
and
this
is
fifth
yeah-
this
one-
so
five
streams
pre-allocation
so
to
tell
the
long
story
short
when
we
are
creating
a
new
file
as
of
today,
we
don't
specify
any
hint
to
us
about
the
size,
so
the
size
is
equal
to
zero
and
then
every
next
write
to
the
file
extends
the
file.
F
F
So,
basically
everywhere
that
we
know
the
size
up
front
and
another
use
case
is
when
there
is
not
enough
space
and
a
good
example
is
when
you
try
to
copy
a
file,
we
create
a
new
file.
Then
we
copy
a
part
of
the
content
and
at
some
point
of
time
we
get
to
the
place
that
there
is
not
enough
space
available
and
we
draw
an
exception
and
by
exposing
an
api
that
allows
for
specifying
the
size
up
front,
we
could
get
the
exception.
A
A
F
A
A
Yeah
and
then
I
think
in
youtube,
there's
a
comment
of
it's
annoying
that
the
file
async
is
not
the
default
according
to
at
least
steve
tobe.
You
often
will
have
a
performance
reduction
with
the
file
system.
If
you
pass
the
async
flag
that
even
doing
an
async
operation
with
the
general
synchronous
file,
handle
is
usually
your
fastest
option,
but
your
mileage
may
vary.
A
Looking
at
it
from
the
I
wanna
open
files
with
the
async
flag
and
then
the
possible
other
flags
that
may
ever
get
added
in
the
future,
I
think
this
proposal
to
me
looks
good,
as
proposed.
A
G
F
Typically,
when
you
are
using
file
stream
and
your
your
app
does
not
need
to
scale
up
the
fastest
way
to
perform,
io
is
synchronous,
io
and
then,
because
of
the
overhead
we
had
in
the
past,
doing
synchronous
io
on
a
thread
pull
the
second
option.
So
this
is
the
trap
that
people
wrote
into.
It
was
also
faster
than
actually
specifying
asynchronous
upfront
and
then
using
asynchronous
methods.
F
However,
with
all
of
the
the
work
that
we
have
recently
done
in
five
stream
now,
reading
and
writing
of
the
file
is
up,
so
reading
is
up
to
two
times
faster
and
writing
is
up
to
five
times
faster,
the
asynchronous
operations.
So
I
believe
that
we
have
like
outdated
the
previous
statements.
F
However,
I
can
provide
benchmark
results
if
this
is
required
and
steven
added
this
comments
very
recently-
and
I
didn't
have
the
time
to
prepare
the
benchmarks
for
him.
E
A
Right,
like
maybe
you
really
wanted
to
do,
file.open
read
with
delete
on
close
now,
it's
there,
but
yeah.
I
mean,
as
as
steve
said,
these
are
really
just
convenience,
because
everything
here
is,
you
could
open
file
stream
directly
instead
of
using
the
file
accelerators
or
the
path
accelerators
off
of
stream,
reader
and
writer.
A
Yeah
I
mean
there's
always
a
chance
that
he'll
have
objections
when
it
comes
time
for
implementation
and
that
we
end
up
not
doing
it,
but
I
think,
as
long
as
we
feel
that
we're
justified
in
the
thing
the
surface
area
is
correct,
yep
sounds
good,
so
we'll
let
steve
do
feature
review
and
we'll
just
limit
this
one
to
api
review.
A
F
D
So
I
have
a
question
regarding
what
would
be
the
behavior
when
passing
this
hand
I
mean,
does
does
always
I
mean
the
file
system
like
allocate
the
whole
size
on
the
desk
or
just
like
doing
something
else.
D
D
E
I
F
Yeah
yeah
yeah
right
the
files
that
create
with
file
options
already
exist.
So
actually
the
new
overload
is
finally
for
defining
and,
as
I
said,
the
main
benefit
of
this
feature
will
be
like
improved
path
for
all
of
the
operations,
whether
where
we
know
the
file
size
up
front
and
also
improved
reliability
by
just
you
know,
throwing
quickly.
F
That's
a
very
good
question:
what
would
you
what
would
you
suggest?
I
think
we
we
should
just
ignore
it,
but
I
don't
have
strong
opinions.
A
Yeah
I
mean
you
could
look
at
some
things
like
if
they
do,
if
file
access
doesn't
include
right,
then
throw
of.
Why
are
you
specifying
the
thing,
but
then
again,
that's
really
just
saying,
like
you're,
giving
me
nonsense
now
when
you
change
something
else,
that's
possibly
nonsense
later
or
ignore
it.
A
E
Well,
we
do
have
a
forward
compatible
way,
provided
we
only
have
one
method
that
overloads
or
the
two
methods
that
that
or
sorry
only
one
method
that
has
defaults
or
the
two
methods
that
hit
defaults.
There's
no
implicit
conversion
like
this,
the
stream
and
string
case,
there's
no
implicit
conversion
right.
H
E
String
and
stream,
so
that's
safe
right,
which
would
so
we
could
definitely
add
it.
Yeah.
A
A
Right
because
I
noticed
that
streamwriter
it
got
added
as
defaulted
parameters,
but
the
file.create
and
file
stream.
It
did
not.
F
Yeah-
and
here
I
can
explain
myself
so
first
of
all,
I
don't
have
a
lot
of
experience
in
doing
api.
This
is
actually
my
first
meeting
ever
and
I
have
noticed
that
stream
writer
is.
The
fir
is
the
only
api
that
uses
optional
arguments
you
can
see
its
fourth
constructor
has
some
default
values
so
I've.
This
is
why
I
have
decided
to
reuse
this
concept
in
stream
writer,
however,
for
file
and
file
info
and
five
stream,
I
didn't
want
to
introduce
anything
new
in
this
terms.
E
Some
of
that
is
just
because
up
until
basically.net
core
we
base,
we,
we
said
optional
parameters
are
bad,
don't
ever
expose
them,
and
then
we
changed
our
minds
on
that
and
so
newer
apis
we've
started
allowing
it.
E
There
are
definitely
considerations
like
you
have
to
version
them
very
carefully
if
you've
got
one
method
that
has
optional
parameters
and
then
you
add
another
method
with
optional
parameters.
E
A
E
J
B
A
F
A
And
that
if
we
pass
the
option
in
basically
it's
given
the
shift
off
of
magnetic
storage
and
onto
solid-state
devices,
does
the
os
even
respect
this
anymore?
Like
does
it
matter
on
an.
E
However,
I
can
get
back
to
you
with
some
numbers
and
even
if
it
doesn't
matter
on
an
ssd,
there's
plenty
of
users
that
don't
have
ssds
or
who
have
non-ssd
secondary,
drives,
there's
network
storage
cases
etc.
So
and
of
course,
you've
got
linux
versus
mac
versus
windows
versus
ios
versus
android.
So
many
cases
where
I
imagine
it
it
would
be
beneficial
on
at
least
one
of
them.
K
F
Yes,
I
actually
expect
that
this
will
be
the
follow-up
of
the
introduction
of
this
api.
I
expect
that
you
will
improve
the
performance
of
file
that
write
all
text
to
write
all
bytes
file.copy
also.
I
have
seen
places
in
compression
where
we
know
the
size
up
front.
E
I
don't
I'd
also
imagine
even
if
it
does
block
oncreate,
that's
still
more
beneficial
in
some
scenarios
than
blocking
wallet
resizes
every
you
know,
2
000,
bytes,.
J
Yeah,
I
mean
it
depends
on
how
much
other
file
system
work
you
have
going
on.
I
know
that
peer-to-peer
clients
for
downloading
super
large
files
have
done
this
pre-application
in
the
past,
just
to
make
sure
that
they're
not
fragmenting
like
crazy
when
they
download
a
2gig
file
or
something.
A
A
So,
given
that
that
we
already
have
filestream.setlink
is
to
ask
steve's
question
from
the
previous
one
in
a
different
way,
is
this
common
enough
that
it's
worth
the
extra
api
or
should
somebody
just
do
the
two
steps
of
get
the
file
stream
then
call
set
length.
F
A
So
windows
has
that
as
part
of
the
create
file
to
begin
with,
because
with
posix
it
is
just
the
two
steps
you
said.
F
Yes,
however,
here
I'm
relying
on
the
research
that
was
done
by
the
the
user
who
posted
the
the
original
request,
so
I
will
verify
if
there
is
no
api,
for
example,
on
linux
that
is
not
posing
composix
compatible.
That
will
tell
us.
A
A
Do
we
have
anywhere
in
our
code
that
would
use
file
info
dot,
create
and
want
to
pass
this
or-
and
this
comes
back
to
yeah-
I
guess
this
was
carlos
question
of,
should
we
just
start
having
the
the
class
here
so
that
we
don't
need
to
be
adjusting
things
in
the
future,
and
this
is
just
the
kind
of
like
how
many
places
are
worth
adding
for
allocation
size
and
if
it's
a
corner
case,
then
maybe
they
have
to
write
an
extra
line
of
code.
A
L
F
F
A
Yeah,
we
certainly
could
get
away
with
it
there,
but
then
you
know
you
do
get
the.
A
I
guess
the
problem
is
when
you're
using
streamwriter
you
don't.
Actually
I
mean
you're.
You
can
be
smart
enough.
I
guess
to
know
what
the
allocation
size
would
really
be
if
you're
writing
text,
because
you
know
what
encoding
you've
picked
and
if
you
pick
an
easy
one,
then
you
have
an
easy
you.
You
have
a
hope
of
guessing
the
allocation
size.
A
Yeah,
because
we
don't
do
anything,
fancy
utf-16
is
just
straight
up
times
two,
the
yeah
like
I,
I
wonder,
if
the
I
guess
it's
just
the
fourth
one
like
three
of
them
seem
reasonable.
The
fourth
one
seems
marginal,
but
it
completes
the
story
so
yeah.
It
seems.
A
F
Yeah,
so
the
good
news
is
it's:
the
last
api
proposal
related
to
files,
so
both
windows
and
unix
expose
a
way
to
read
and
write
at
a
given
offset
and,
however,
to
and
as
of
today,
we
don't
have
a
primitive
that
allows
for
that.
You
can
seek
the
file
stream
to
give
an
offset
and
then
call
read
or
write.
However,
this
is
not
atomic.
F
Moreover,
five
stream
is
not
thread
safe,
so
you
should
not
be
using
it
for
writing
or
reading
in
parallel
and
alex
the
author
of
the
original
issue,
who
works
had
some
azure
team
they
requested
for
a
feature
that
would
basically
expose
underlying
windows
overlapped.
I
o
feature
which
allows
you
for
doing
a
lot
of
asynchronous
reads
and
writes
at
the
same
time,
but
at
different
offsets,
and
so,
moreover,
we
are
also
introducing
a
breaking
change
to
five
stream
in
dot
net
six,
because
so
five
stream
was
never
officially
thread
safe.
F
However,
we
were
pretending
that
we
allow
for
multiple
concurrent
reads
and
writes,
however,
to
fix
some
of
the
issues
that
were
there
for
a
long
time.
We
have
introduced
the
locking
in
in
five
stream
itself.
So
you
actually
won't
be
able
to,
for
example,
start
multiple,
read
async
operations
and
then
await
all
of
them
at
the
end,
and
this
is
why
we
would
like
to
introduce
two
new
preventive
types.
F
D
E
F
A
So,
the
aside
from
the
fact
that
we're
introducing
new
things-
I
guess
the
the
comments
or
the
feelings
that
I
have
are
first,
I
know
that
file
stream
currently
has
length
as
a
property,
but
that
feels
that
really
only
makes
sense
as
a
property.
When
you
are
opening
for
read,
it
probably
should
really
be
a
method
saying
you
you
don't
get
to
you
shouldn't
assume
that
it
doesn't
change
like
the
the
fact
that
it's
updated
as
side
effects
of
calling
right
really
feels
like
you
want
length
to
be.
A
You
know,
get
length
to
be
clear,
like
you
might
want
to
check
this
again
at
some
point
and
then
the
problem
with
asynchronous
random
access
file
only
having
async
api
is
at
some
point.
You
may
be
in
a
synchronous
callback
and
what
you
were
given
as
the
file
that
you
need
to
write
to.
Is
this
thing
and
now
you're
forcing
sync
over
async,
which
is
why
we
have
the
consider,
I
think,
having
a
synchronous
version
of
any
async
thing
that
you
add.
J
Yeah,
I
would
also
add
it's
it's
becoming
slightly
more
common
to
have
a
method,
an
async
method
that
implements
both
synchronous
and
asynchronous
paths.
J
F
Yeah,
so
so,
actually
having
that
in
five
stream
was
a
big
problem
and
one
of
the
reasons
why
we
have
decided
to
rewrite
it,
because
the
logic
was
like
basically
every
method.
F
So,
first
of
all,
every
method
in
five
stream
was
first
of
all,
checking
if
given
type
is
actually
five
stream
or
a
type
that
there
is
from
five
stream.
And
then
we
had
the
logic
that
was
checking
if
this
is
five
string
created
for
synchronous,
io
or
asynchronous
io,
and
by
separating
these
two
concepts,
and
also
like
we
have
seen
people
like
forgetting
about
passing,
is,
I
think,
to
file
some
constructor
and
creating
python
for
synchronous,
io
and
using
it
in
asynchronous
way
later.
F
So
I
I
don't
expect
these
types
to
be
commonly
used,
and
maybe
this
is
why
stephen
and
anyone
were
suggesting
that
maybe
instead
of
introducing
new
primitive
types,
we
could
introduce
just
say
fire
handle
extension
methods,
which
is
the
alternative
design
proposed
here.
A
Yeah
because
I
mean
I
guess,
the
the
answer
to
the-
if
you
got
called
in
the
synchronous
callback
is
since
it's
exposing
the
safe
file
handle,
you
could
take
the
safe
file
handle,
wrap
it
in
or
then
call
random
access
files,
save
file,
handle
based,
constructor
and
then
call
the
synchronous
operation
on
that
one.
So
you
do
have
a
way
you
can
do
it.
I
guess
yes,.
F
But
we
we
could
verify
that
given
handle
like
we,
we
would
have
to
actually
verify
that
given
handle
was
created
for
asynchronous
io
or
synchronous,
and
this
is
also
what
five
stream
constructor
does
internally
as
of
today,
when
you
are
creating
it
out
of
the
handle.
A
I
mean,
maybe
that's
exactly
what
we're
doing,
because
it's
an
async
file
handle
and
we're
calling
the
synchronous
api,
but
like
we're
we're
at
least
doing
what
we
think.
The
best
thing
that
we
can
do
with
the
os
is
as
opposed
to
making
the
caller
make
something
up
which
usually
is
invoke
the
task.
And
then
you
know,
call
dot,
get
a
waiter
get
results
and
ignore
the
fact
that
it's
yelling
at
them.
F
F
That's
a
good
question.
However,
I
don't
have
an
answer
for
it.
F
I
think
that
some
some
of
similar
powerful
things
are
just
not
supported
on
on
some
of
the
platforms
like
in
browser,
for
example,
I'm
not
sure.
A
Right,
but
is
this
supposed
to
be?
We
expect
pnsc
and
the
constructor,
or
we
expect
a
pnsc
when
you
actually
call
right
or.
A
Yeah,
I
was
gonna
say
the
like:
adding
the
new
classes
feels
wrong
in
ways
that
I
can't
articulate
so
hopefully
somebody
else
can
and
the
the
notion
of
like,
maybe
we
add
them,
as
extension
methods
off
of
say,
file
handle
seems
a
little
better,
but
then
the
the
problem
is:
where
would
we
describe
the
whether
or
not
your
platform
supports
it?
And
I
guess
really
it's?
A
A
A
Expectation
is
oh
try
asynchronous
nope
that
through
okay
wrap
it
in
the
synchronous
version.
F
F
So,
for
example,
the
team
that
asked
for
that
they
are
building
some
high
performance
azure
service
and
they
had
to
basically
implement
some
interrupt.
Wrappers
for
windows
overlapped
api
on
their
own
to
be
able
to
do
to
have
a
single
kernel
object
that
represents
a
file
handle
and
perform
multiple
reads.
M
You
know
with
file.,
I
know
sorry
directory
dot,
enumerate
files
and
whatever
right,
but
we
also
have
a
struct-based
enumerator,
but
that
is
more
advanced
than
not
very
convenient
to
use,
but
it's
very
fast.
So
these
two
types
I
can
see
being
similar,
but
to
echo
jeremy's
point
I
mean
it
is
a
bit
concerning.
If
you
have
a
net
new
type
that
effectively,
you
can't
use
anywhere
right
because
you
basically
in
order
for
this
to
be
used,
somebody
has
to
write
basically
the
code
to
actually
do
anything
with
it
right.
M
A
Yeah
I
mean
we
could
certainly
make
a
a
reader
built
on
top
of
these.
I
guess
you
could
make
a
you
could
probably
make
a
writer,
but
yeah
though
it
feels
weird,
if
we
think
it's
going
to
be
a,
I
mean
it
is
a
power
scenario
it
so
now.
The
question
is
no
matter
if
we
are
adding
new
types
that
aren't
just
a
static
class
for
possibly
being
extension
methods
like
is
being
in
system
io
too
visible.
M
A
Right
because
the
the
premise
like
the
windows
apis
that
were
the
windows
file
system
concept
for
this
is
overlapped.
So
I
do
see
that
there's
the
suggested
overlapped
instead
of
random
access
and
then
that.
A
A
J
These
classes
don't
have
any
sort
of
abstraction
to
them
like
stream.
Do
we
expect
nobody
to
need
something
like
that.
F
They
are
unique
in
a
way
because
other
streams,
like
I
believe,
sockets
they
don't
support,
reading
and
writing
at
given
offset.
So
this
is
why
it's
specific
to
files.
J
E
E
I'm
not
sure
that
it's
actually
as
complicated
to
use
this
api,
as
we
might
be
thinking
really
users
just
care
about.
I
I
can
read
and
I
can
write
and
that's
what
this
api
exposes.
You
give
it
your
input,
it
writes
it
to
the
offset
it
could
internally
buffer
it
if
that's
appropriate,
for
it
to
do
just
like
file,
can.
M
Well,
I
mean
there's
nothing
wrong
with
that.
I
mean
like
the
sample
code
is
pretty
straightforward
right.
All
I
think
we're
basically
saying
is
that
almost
nobody
does
that
with
stream
right
like
people?
Don't
they
don't?
They
don't
go
to
an
xml
document
and
enumerate
buffers
and
then
write
them
to
a
stream
right.
They
just
call
an
api
that
does
that
for
them
right,
and
so,
if
we
have
these
two
new
types,
that's
fine,
but
then
there's
fallout
work
in
order
to
make
those
useful
right.
M
People
want
to
write
ins
longs
or
json
or
xml,
and
then
because
there
is
no
common
abstraction,
it
makes
it
relatively
difficult
for
us
to
to
do
these
things
right,
because
either
we
now
have
one
offs
for
every
single
thing
we
care
about,
or
we
eventually
plug
this
thing
over
stream,
which
presumably
means
we
lose
all
the
value
in
the
first
place
so
like
it
would
be.
It
would
be
hard
right.
E
M
M
Yeah,
that's
the
thing
where
I
think
I
disagree
like
to
me.
It's
it
it's
hard
to
do.
Abstractions
later,
like
basically
like
abstractions
is
not
the
kind
of
thing
where
mvp
I
think
is
is
is
necessarily
the
best
approach,
because
once
you
have
it,
it
is
the
shape
you
have
it
and
when
you
then
start
later
to
try
to
think
about
an
abstraction,
it's
relatively
difficult
to
like
introduce
them
later
so
like.
Basically,
we
have
no
one
shot
at
these
types.
If
we
think
there
should
be
a
common
type,
we
should
do
it
now.
K
M
M
J
Testing
is,
is,
has
become
quite
popular
in
our
ecosystem
and
not
having
some
sort
of
abstraction,
for
this
means
that
anyone
who's
a
fan
of
testing
is
is
likely
to
create
their
own
abstraction.
On
top
of
these
and
never
actually
use
our
class
directly,
it
seems
like
it
would
be
cheap
and
worthwhile
just
to
create
an
abstraction
here
from
the
get-go.
G
See
I
mean
I
disagree,
because
this
is
the
power
user
right.
They
don't
want
abstractions,
they
want
to
go
to
the
metal
right.
Like
I,
I
kind
of
I
I,
like
the
alternative
design
to
tell
you
the
honest
truth
like
I
don't
think
we
need
classes
for
this.
All
they
want
to
do
is
like
call
basically
the
os
api.
G
M
But,
like
I
think,
static
method
like
thinking
of
this
aesthetic
methods,
rather
than
thinking
of
them
as
types,
I
think,
at
least
in
my
view,
helps
with
the
whole
exchange
type
argument
right
because
it's
like
well,
these
are,
as
you
said,
power
user,
low
level,
apis
you're
supposed
to
build
your
own
stuff.
On
top
of
that,
and
so
that's
why
there's
no
abstractions,
because
well,
it's
literally
the
worker
method
so
plug
that
in
wherever
you
need
it.
A
Well,
I
mean
when
you
say
you
wouldn't
make
them
extension
methods.
Do
you
mean
you
would
have
them
be
static,
methods
that
aren't
extension
or
that
you
would
just
modify
say
file
handle.
M
No,
I
would
probably
make
them
just
static
methods
on
save
file
handle,
probably
and
then
not
having
them.
As
this,
I
would
just
say
you
have
to
pass
in
the
file
handle
as
the
first
argument,
because
I
mean
these
are
power
user
apis.
If
you
don't
really
care
about
how
convenient
the
call
side
is
right,.
E
At
the
same
time,
save
file
handle
is
not
always
usable
or
desirable
because
it
comes
with
its
own
overhead
and
abstractions
that
can
be
non-compatible
with
whatever
you're
doing
under
the
covers.
There's
many
p
invoke
apis,
particularly
in
performance
oriented
scenarios
that
they
avoid
the
file
handle
types
at
all
costs
because
they
cause
so
many
issues
for
their
for
their
library.
M
F
Yeah
they
support
both
like
path
and
safer
handle.
Another
issue
with
sapphire
handle
is
that
whenever
we
are
accessing
five
stream
dot
sapphire
handle,
we
are
changing
the
internal
behavior
of
five
stream,
because
we
assume
that
the
handle
has
been
exposed.
So,
for
example,
we
cannot
cache
the
file
length
because
somebody
might
have
modified
outside
and
we
so
in
the
past.
We
were
also
verifying
that
the
caller
has
not
moved
file
offset
so
and
also
when
this
type,
when
this
property
is
accessed,
we
have
to
flash
the
disk.
F
You
can
create
it
on
your
own,
however,
we
don't
expose
a
way
for
for
doing
that
in
a
cross-platform
manner,
so
we
kind
of
expect
the
power
users
to
know
windows
and
unix
apis
and
be
able
to
to
implement
that
on
their
own.
This
is
why
this
alternative
proposal
contains
the
open
file
method
that
would
actually
expose
this
logic
that
we
have
internally.
M
D
M
Yeah
yeah,
I
mean
to
me
this
is
kind
of
like
with
in
the
weeds.
I
think
the
to
me
whether
it's
on
save
file
handle
doesn't
really
matter
so
much.
I
think
that
just
the
like
to
me
it's
basically
either
we
have
a
type
or
we
have
a
static
methods
right.
These
are
really
the
two
design
points,
and
I
I
was
just
saying
like
I
would
prefer
static
methods,
even
if
they're
on
the
new
type
or
something
that
would
still
be
better
than
having
a
type
where
everybody
would
basically
ask
for
an
abstraction
immediately.
E
M
Well,
it
depends
on
the
scenario
right
like
to
the
I
mean
for
the
if
it's
just
primitives.
Yes,
if
it's,
if
it's
things
like
oh,
I
want
to
basically
be
able
to
do
it
into
a
memory
buffer
or
to
a
file
on
disk.
Well,
then,
I
want
some
interaction
between
which
is
basically
the
testing
scenario
or
the
well.
How
do
I
do
this
on
x
document
when
I
given?
If
you
know
like,
do
I
just
take
a
file
path
and
then
just
use
it
in
my
implementation
or
how
would
I
actually
implement
these
things
right?.
E
A
Then
now
we
need
to
make
something
virtual
so
that
their
mock
can
not
write
to
the
file
system.
Like
I
think
eric's,
I
think
it
was
eric
who
brought
it
up
was
seemed
to
be
bringing
it
up
from
the
mocking
perspective
of
that
people
want
to
well,
I
want
to
test
using
these
apis,
but
not
actually
touch
the
file
system.
So
now
I
need
the
abstraction,
whether
it
be
a
class
that
you
mess
with
or
now
they're
going
to
write
the
interface
that
they
give
their
mock
version
and
etc.
E
M
I
think
that's
a
fair
point,
but
I
would
say
that
there's
two
sides
right:
there
is
the
you
either
believe
in.
There
is
extensibility,
but
then
you
design
for
it
or
you
don't
make
it
extensible,
but
I
don't
believe
in
the
let's
just
unseal
the
type
and
pretend
it's
extensible
model,
because
that
that's
that's
not
getting
it
done
either.
E
M
Do
that,
with
extension
yeah
I
mean
unless
there's
virtuals,
I
don't
I
mean
unless
you
need
to
track
state
which
arguably
you
don't
need
for
most
unless
you
change
behavior
like
I
to
me
the
unciting,
the
types
wouldn't
do
much
like.
If
you
really
believe
we
want
to
support
mocking
somehow,
then
we
have
to
think
about
how
would
you
actually
do
it
if
you
want
to
just
write
to
a
buffer
in
memory
right
and
that
you
can't
just
do
that
by
stop
classing.
F
This
and
and
as
I
said
in
the
past,
I
didn't
introduce
an
abstraction
because
other
kind
of
streams
don't
support
this,
so
we
cannot
do
it
with
socket.
We
cannot
do
it
with
a
pipe,
then,
for
me,
introducing
an
abstraction
could
be
kind
of
a
promise
of
like
maybe
in
the
future.
We
will
implement
more
types
that
support
it.
M
Yeah,
that's
I
mean
this
goes
back
to
what
I
said.
Like
I
mean
to
me,
I'm
not
saying
you
need
to
all
I'm
saying
is
that
we
should
not
kid
ourselves
that
we
can
do
this
later
like
we
should
make
a
decision
now.
M
Do
we
believe
this
is
a
zero
cost
abstraction
thing
we
do
as
a
for
power
users,
which
the
trade-off
is
we
don't
abstract,
because
that
would
increase
the
cost
and
friction,
but
then
I
think
we
should
have
a
design
that
kind
of
communicates
that
and
to
me,
static
methods
are
really
the
way
to
do
that.
I
would
I
would
I
would
just
avoid
types
for
that
reason,
because
again
you
have
a
class
the
class
allocates.
M
I
don't
know
like.
I
would
try
to
make
it
as
cheap
as
possible
and
then
just
say
whatever
you
want
to
do
you
do
whatever
abstraction
you
want
to
build
you
build.
If
you
want
to
have
a
buffer,
an
unbuffered
version,
you
just
decide
how
you
want
to
call
these
methods,
but
we
don't.
We
don't
give
you
a
prebake
type
to
do
that.
J
F
Least
I
haven't,
could
you
please
post
the
link
to
the
source
code.
M
B
A
All
right,
so
I
did
some
noodling
in
notepad,
so
if
we
think
that
it
isn't
necessarily
extension
methods,
though
we
could
make
the
extension
methods-
and
I
think
tanner
was
sort
of
arguing
for-
let
me
control
the
lifespan
of
the
safe
file
handle
just.
Let
me
pass
the
it
pointer
and
move
on
with
life.
F
F
M
M
If
you
don't
need
them
or
you
don't
want
them
right,
that's
the
worst
case,
then,
maybe
that's
not
the
appropriate
api
and
if
they're
aesthetics,
I
think
it's
okay
to
say
we
have
overloads
between,
say,
file
handle
and
in
ptr
for
the
for
the
real
user.
That
wants
to
go
down
zero
cost
to
the
metal
kind
of
thing
right.
F
E
E
They
have
a
another
layer
of
indirection
to
get
the
handle
that
they
want
for
the
p
invoke,
and
you
don't
want
to
use
the
save
file
handles
in
the
p
invoke,
because
sometimes
it
doesn't
work
the
way
you
expect,
because
the
marshaller
behaves
a
very
particular
way
with
them
and
that's
not
always
desirable,
and
in
other
cases
you
might
want
to
be
doing
customized
logic
with
it.
So
there
are
many
many
cases
where
you
just
don't
want
that
file
handled
or
where
it's
not
appropriate.
F
F
M
M
I
think
that
might
be
an
okay
trade-off
right,
I
mean
that's,
maybe
something
we
need
to
document
then,
but
that
would
certainly
be
unfortunate
because
then
you
might
actually
lead
people
down
the
wrong
path.
But
if
we
believe
this
is
the
power
user
api
yeah,
I
would
prefer
if
we
could
fail
rather
than
giving
gob
gig
back
garbage,
but
if
we
absolutely
can't-
and
we
needed
it
for
perf.
M
E
A
What's
the
scenario,
if
the
scenario
is
we
can
handle,
we
would
already
we
would
maybe
have
some
internal
usages
ourselves
and
we
figure
that
we're
a
better
resource
for
hiding
a
common
operation.
That
is
spelled
a
different
way
between
our
various
platforms.
Then
it
feels
like
this
is
we're
kind
of
exposing
a
low-level
operation
and
yeah.
If
you
pass
in
ptr
caller,
beware
like
you
were
responsible
for
making
sure
that
the
file
handle's
not
closed,
etc.
A
The
safe
file
handle,
if
you
want
it,
to
have
friendly
errors
of
like
hey,
I'm
not
seekable,
then
like
that's
fine,
that's
something
that
the
object.
A
I
know
that
you're
proposing
say
or
having
the
object
exposed,
whether
or
not
it
believes
it's
seekable,
so
we
could
have
a
more
friendly
thing
with
a
more
friendly
object.
We
could
also
make
that
be
an
extension
method
if
we
wanted,
but
I
I
yeah,
I
wonder
if
adding
the
safe
file
handle
based
things.
A
M
Yeah,
like
I
mean
this
is
the
kind
of
problem
that
we
often
have
right,
like
I,
I
believe
like
there's,
either
usability
or
there's
performance
right
like
you
have
to.
Basically,
you
have
to
decide
what
is
the
most
important
thing
now.
The
thing
in
the
middle
always
looks
very
appealing,
but
there
is
the
real
danger
that
you
now
have
a
usable
api
or
a
not
quite
usable
api.
That's
also
not
quite
fast
enough
right
so
like
then,
you
have
no
customers
right,
so
you
did
so.
M
If
you
want
to
use
the
api
it's
there,
we
make
it
cross-platform,
so
the
heavy
lifting
is
done,
but
yeah
it's
not
the
most
convenient,
because
the
expectation
is
you
have
it
in
your
deep
bowels
of
your
of
your
code,
and
so
you
don't
pay
for
any
abstraction.
I
think
that's
a
that
to
me
is
a
good
design.
J
Keep
in
mind
that
we're
performing
ios
here,
so
that's
going
to
take
over
the
performance
cost
of
any
abstraction
like
I
don't.
I
don't
think
any
abstraction
is
going
to
add
meaningful
performance
characteristics
here.
G
A
No
sorry
yeah
in
and
that's
fair,
I'm
just
like
we're
we're
making
sure
that
that
was
the
context
you
were
speaking
in
yeah.
G
M
Well,
I
mean
like
it
would
be
weird
to
have
one
method
as
an
instance
method,
because
it's
an
extension
method
on
say
a
file
handle
and
the
overload
is
now
not
an
extension
method
over
in
ptr
right.
That
seems
weird,
but
also
having
it
in
pdr
would
be
equally
weird.
So
it
just
seems
inconsistent
at
that
point.
A
M
Applies
right,
like
people
that
want
to
do
power,
users
are
also
trying
to
figure
out
what
to
do
next
right.
So
indeed,
if
you
force
them
down
in
another
static
method,
syntax,
it's
very
easy
for
them
to
discover.
Oh
there's,
an
alternative
that
doesn't
require
a
save
file
handle
awesome.
I
can
use
that
like
once
you're
into
the
oh.
This
is
always
an
instance
method
on
save
file
handle.
Then
you
may
never
discover
them
right.
So.
A
Yeah,
I
guess
I
don't
know
what
modern
usability
studies
say.
People
are
doing,
but
you
know
in
the.
If
you
have
your
cursor
set
at
read
it
offset
and
hit
f1,
then
the
documentation
it
would
take
you
to
would
be
the
static
method
because
it
like
that's
what
it
is
if
it
has
a
extension
invocation,
but.
M
A
M
F
F
A
team
that
creates
some
server
apps
using
some
high
performance
stuff.
M
Yeah,
I
guess
it
would
be
good
whatever
design
we
we
push
you
to
like
validate
with
them,
that
that
makes
sense
to
them
and
if
they
say
absolutely
not,
then
you
should
go
back
to
the
drawing
board,
but.
M
M
M
A
Yeah,
what
what
I
meant
to
do
was
replace
all
right
parentheses
with
right
parenthesis,
throw
an
old
semicolon
but
or
arrow
throttle
semicolon,
but
I'll.
Let
you
do.
A
I
have
decent
editors,
just
not
on
the
machine
that
I
stream
from
it
doesn't
come
up
often
enough
that
I
care
all
right
so
have
I
captured
our
commentary.
G
H
A
You
all
right,
someone
other
than
adam
adding
classes
as
a
target
for
requires
unreferenced
code
attribute
50122..
C
C
There
is
a
comment
from
stephentop
that
is,
that,
okay,
if
we
support
it
for
classes,
why
not
to
support
it,
also
for
extracts
and
interfaces,
which
is
the
alternative
design.
But
the
problem
is
that
strokes
are
problematic
because
they
are
default.
They
can
be
default,
distantiated
which,
if
it's
defaultly
saturated,
we
consider
that
at
all,
and
it
will
need
to
warn
and
well
that's
different.
C
E
I
was
going
to
say
the
language
is
looking
at
allowing
default
struct
constructors.
Finally,
again
regardless
what
you
think
jeremy,
it's
probably
going
to
happen,
in
which
case
new
t
for
a
struct,
will
actually
call
a
constructor
and
not
be
default,
in
which
case
it
and
activator.create
new
instance
will
likely
do
the
same,
because
that's
how
it
actually
works.
If
you
define
that
in
il
today,
so
I
think
struct
likely
needs
to
be
handled
if
not
today,
but
it
in
the
near
future.
A
A
G
And
that
makes
sense
and
it
also
alleviates
when
you
have
a
derived
class
that
is
unsafe,
but
today
today,
when
you
have
requires
on
reference
code
on
a
virtual
method,
you
have
to
have
it
on
the
whole
hierarchy
and
so
a
lot
of
times
what
we
have
is.
We
have
like
a
base
class,
that's
perfectly
safe
and
a
couple
drive
classes
that
are
perfectly
safe,
but
then
there's
one
class,
that's
doing
unsafe
things,
and
so
it's
it's
nice
to
just
slap
the
requires
unsafe
code
on
that
class.
A
Right
but
I
mean
so
logically
speaking,
it's
saying
it
does
apply
to
the
instance
members,
but
that
you've
already
covered
it
because
it
was
covered
at
construction
time
and
that
it's
while
the
the
current
code
may
be
calling
an
instance
member
on
the
type
the
unfriendliness
came
from
the
person
who
constructed
it,
correct
yep.
So
if
you
I
don't
know
how
infectious
requires
unreferenced
code
supposed
to
be,
but
if
you
have
a
parameter
to
a
method
that
has
one
of
these.
G
A
G
A
A
Yeah,
I'm
just
trying
to
think
through
the
things
where
I
see
an
attribute
applied
on
a
type
and
unders.
If
I
understand
what
it
means
when
I
think
that
the
semantics
of
it
should
apply,
and
while
I
had
the
it's
weird
that
you
would
not
include
instance
members,
but
then
it
was
the
well
you
have
because
you
got
the
constructor.
A
Fair
enough,
I
just
yeah
it's
the
without
knowing
what
the
total
implications
of
this
are.
I
didn't
know
if
it
was
supposed
to
be
a
like.
We
have
our
unsupported
api
or
unsupported
platform,
stuff
right,
it's!
So
if
you
call
one
now,
you
need
to
paint
yourself
as
I'm
not
supported
on
this
os
or
you
have
to
have
a
guard
that
makes
it
look
like
you
did
something
sensible
so.
I
It's
basically
the
same,
so
the
question
is
you
know
what
do
we
do
for
parameters?
In
that
case,
honestly,
I
could
go
either
way.
It
also
doesn't
really
matter
that
much
like,
regardless
of
what
behavior
we
choose,
we're
sticking
attribute
targets.class
on
the
on
the
attribute
we
can.
We
can
talk
about
the
ways
of
the
intricacies
of
each
little
detail,
but
like
yeah.
A
No
like
no
matter
what
I'm
just
making
sure
that
we're
not
setting
ourselves
up,
for,
we
have
something
that
looks
like
it
should
work
and
we
have
a
hole,
and
I
think,
I'm
convinced
that
that
everything
is
covered
interfaces,
definitely
shouldn't
get
it
because
interfaces
are
just
syntax.
E
I
I
A
G
I
Yep
it
does,
I
don't
know
what
the
what
emo's
platform
analyzers
do.
M
I
don't
think
you
want
on
the
type.
I
think
we
warn
the
usage
of
the
type,
so
the
parameter
is
fine,
like
what
really
matters
is
what
you're
doing
with
it.
If
you're
just
passing
it
through,
nobody
cares.
If
you
actually
call
a
method
on
it,
then
it
will
probably
work
because
it's
about
what
you
know
code,
you're
executing
right,
just
accepting
and
returning
things
is
fine,
because
you're
not
calling
any
code.
I
A
A
So
you,
your
your
graph,
is
already
going
to
be
tracking.
That
unreferenced
code
is
in
your
universe.
I
M
B
I
A
All
right
looks
like.
A
H
D
No,
actually,
this
is
a
review
reviewed
last
friday
and
we
got
some
feedback
during
the
design
review,
and
this
is
I'm
bringing
back
just
after
addressing
this.
The
concerns
that
raised.
So,
if
you
go
well.
H
A
J
J
J
Yeah
yeah
there
we
go
so
we
think
we
want
to
name
the
the
deflate
options
to
dangerous
deflate
options,
just
with
some
nice
documentation
saying
why
it's
dangerous
and
how
they
might
mitigate
it.
J
Because
otherwise,
it's
it's
really
not
obvious
that
there's
there's
an
issue
and
second
we're
adding
these
websocket
message.
Flags.
One
of
them
is
just
taking
an
existing
bool
parameter
and
turning
it
into
a
flag,
and
the
other
is
the
ability
to
disable
compression
on
a
per
message
basis.
J
Essentially,
you
would
use
this
to
mitigate
the
issue
as
well
by
if
you
have
any
secret
data
and
user
data,
you
would
split
them
into
two
separate
messages:
keeping
one
uncompressed
so
that
it
doesn't
impact
the
other
one.
A
Okay,
so
I
have
two
obvious
things:
one.
You
should
name
the
zero
value
on
the
flags
to
none
and
two,
especially
because
compression
is
the
danger
using
it
is
the
dangerous.
I
think
that
you
want
all
of
the
you
want,
none
to
be
your
default,
because
if
you
added,
if
you'd
already
shipped
this-
and
we
were
adding
compression-
and
somebody
was
already
calling
this
api
and
setting
a
value,
we
don't
want
the
fact
that
the
the
third
bit
was
not
yet
defined
to
mean
that
they're
now
accidentally
assigning
dangerous
behavior.
A
So,
given
your
name
of
dangerous,
the
on
bits
are
the
dangerous
mode
and
the
off
bits
are
the
safe
mode.
L
Comment
on
that,
it's
because,
even
if
you
state
the
deflate
options,
this
has
to
go
through
negotiation
and
server
can
decline
compression.
So
even
if
you
set
the
deflate
option
and
you
go
and
obtain
for
compression
and
still
wouldn't
mean
that
these
is
compressed,
so
it
may
be
confusing.
A
Well,
you've
no
you've
said
you've
enabled
compression
you're,
not
forcing
compression
you're,
not
compressing,
it's
you
are
allowing
compression
to
happen
and
and
the
allowing
that
is
the
dangerous
thing.
A
Is
dangerous,
I
don't
know
if
message
has
a,
but
basically
it's
like
you
need
to
think
about
it
from
the
context
of
four
versions.
From
now
like
somebody
will
have
built
up
what
they
think
the
right
value
of
web
socket
message.
Flags
is
and
if
for
v,
if
four
versions
from
now
you
add
a
new
flag,
they're
already
passing
that
the
value
that
they
want
is
one,
and
if
that
means
that
they're
now
accidentally
opting
into
a
behavior
that
they
wouldn't
have
wanted,
given
that
the
name
is
dangerous,
like
that's
bad.
A
So
to
me
this
feels
like
it
needs
to
be
all
opt-ins
and
not
any
opt-outs.
I
guess,
but
really
the
answer
is
the
zero
value
should
represent
the
default
thing
and
the
one
value
should
represent
the
thing
that
you
have
to
toggle.
J
J
Okay,
let
me
restart
if
you
have
existing
people
calling
into
websockets
to
send
messages
they're
using
the
existing
api
without
any
flags,
and
you
know
that
that
code
is
safe.
J
It
is
not
doing
compression
disable
compression
will
only
take
any
effect
if
you
actually
enable
it
through
this
websocket
creation
options.
A
Right
so
my
like-
and
this
makes
sense
from
an
initial
implementation
like
because
it's
a
brand
new
api,
but
if
we
were
adding
support
for
compression
right
now,
then
anyone
who
was
already
setting
options
they
would
now
be
because
it's
the
zero
state
is
on.
They
would
be
accidentally
implicitly
turning
on
compression
and
that's
why
the
the
zero
bit
needs
to
represent
the
default
and
the
default
needs
to
be
safe.
C
M
Value
yeah:
let's
say
you
already
shipped
this
right:
let's,
let's,
let's
pretend
we
already
have
the
message
flags
and
now
we're
adding
compression
right.
So
let's
just
pretend
that's
the
what
we're
living
in
right.
The
idea,
I
think,
is
that
whoever
turned
on
dangerous
deflate
options
is
now
also
on
the
hook
to
change
the
call
sides
to
send
async
to
opt
out
the
messages
where
it
makes
sense
to
opt
them
out
and-
and
we
like,
we
don't
know
which
ones
that
is
right
so,
like
I
think
it's
the.
M
I
think
the
idea
is,
it's
opt
in
at
the
root
level
and
it's
opt
out
per
message
level,
but
if
you're
the
one
turning
like
opting
in
at
the
root
level
you're
on
the
hook
to
opt
out
the
individual
messages,
so
it's
okay.
If
existing
code
still
doesn't
opt
out
because
existing
code
hasn't
opted
in
at
the
root
level.
M
A
It's
the
same:
it's
the
same
flags
used
for
both
the
websocket
creation
and
the
individual
message.
J
No,
this
this
flag
is
only
passed
to
send
async
the
website.
The
deflate
options
do
not
use
the
flag.
M
A
J
A
A
A
M
J
That's
a
question
we
asked
and
we
don't
have
an
answer
for
that.
We'll
probably
look
at
that
in
another
issue.
If
we
choose
to
look
at
it
at
all,
it
is
off
by
default
in
http
client
at
least
so.
There's
no
imminent
security.
M
A
Because,
with
with
http
web
request,
I
don't
remember
when
we
added
http
client,
but
with
http
web
request.
At
least
we
had
the
api,
I'm
pretty
sure
we
had
the
api
before
the
attack
was
known,
so
it
was
at
that
one
or
that
time
it
was
a
you're
opting
into
a
thing
that
the
server
may
not
support
or
you're,
assuming
that
you
can
compress
faster
than
you
can
transmit,
which
is
generally
the
case,
but
not
always
on
on
limited
resource
devices
and
and
such
so.
A
It
was
like
this
is
a
sort
of
a
space
versus
time
decision
that
you're
making
and
now
we
know
it's
a
dangerous
space
versus
time
decision
that
you're
making
and
the
answer.
Is
you
don't
want
to
do
it?
Unless
you
know
it's
a
something
like
a
html
file?
Sorry
something
yes
like
an
html
file.
That's
statically
generated,
not
html
content
and
here
you're
sending
a
lot
of
messages,
so
they're,
probably
all
data.
So
it's
probably
always
the
wrong
idea.
A
But
so
I
think
it's
we've
learned
here
and
if
we
felt
that
it
was
super
risky
with
http
client,
we
would
obsolete
the
one
and
rename
it
to
dangerous.
Just
to
put
in
your
face
or
we'd
add
a
new
analyzer.
I
think
we
have
a
million
security.
Analyzers
we'd
find
one
that
people
actually
don't
turn
off,
because
it's
not
too
noisy
and
we'd
add
a
noisy
thing
to
it,
and
then
they
would
turn
it
off.
M
M
I
mean
so
I
I
guess
yeah
I
mean
again
like
I'm
not
opposed,
I
mean.
Usually
we
use
dangers
for
things
where
you're,
basically
bypassing
the
type
system
right,
which
is
kind
of
an
inherent
property
of
the
api,
rather
than
we
find
later
on
that
you
know
in
the
workflow
and
how
you
use
the
api,
you
might
do
something
unsafe.
That's
why
I'm
just
gives
me
a
pause
because
it
basically
means
we
need
to
get
this
right
the
first
time
and
that
I
don't
have
confidence
in,
but
I
mean
it
makes
sense.
M
J
Yeah
yeah,
I
know
that
we
we've
typically
used
dangerous
for
memory
unsafe
and
type
unsafe
things,
but
in
this
case
it's
a
really
easy
pit
to
fall
into
without
noticing
it.
So
we
think
it's
good
to
call
out
so
that
people
at
least
hopefully
look
at
documentation.
M
Yeah,
the
one
thing
you
need
to
be
careful
with,
though,
and
that
is
kind
of
again
I
don't
have
a
good
suggestion
here
is
just
something
you
need
to
keep
in
mind.
Is
you
don't
want
to
use
this
term
inflationary
right
because
it
because
that's
so
let's
say-
and
I
have
I
completely
make
up
stuff
now
to
just
make
my
point,
but
let's
say
that
90
of
usages
of
web
sockets,
don't
have
user
supplied
data
right,
it's
just
whatever
the
protocol
is
that
the
person
wrote
if
you
teach
everybody
to
basically
say
yeah.
M
I
just
ignored
the
dangerous
thing
here,
because
I
know
I
own
everything
you
do
the
opposite
of
what
you're
trying
to
do
right.
You
try
to
reach
awareness,
but
that
only
works
when
it's
rare,
if
people
are
forced
to
use
it
a
lot
to
get
that
job
done,
the
prefix
loses
its
value
right,
so
it's
kind
of
if
you
smack
people
in
the
face
the
same
with
warnings
right.
If
you
raise
too
many
warnings
at
some
point,
the
value
of
the
warnings
disappears
right.
You
want
high
noise
or
high
signal
to
noise
ratio
right.
M
J
Yeah
I
mean
we
mostly
wanted
to
avoid
the
scenario
where
someone
says:
oh
compression
will
be
good
because
I'm
on
a
mobile
device-
or
you
know
it's
very
easy
for
someone
to
say
yeah
compression
sounds
good.
I
can
use
less
bandwidth,
but
they
don't
really
understand
the
whole
ramification
of
that
decision.
J
A
I
mean
really
it's:
we
want
we're
using
it
as
a
prefix,
meaning
rtfm,
but
yes,
a
that
would
be
an
abbreviation
and
b.
It's
not
a
very
polite
one
and.
M
Obviously
or
fine
right,
but
I
think
the
yeah
I
mean.
E
M
This
is
something
that
you
know:
it's
a
judgment
call
right.
So
that's
why
I'm
saying
I
don't
have
a
good
suggestion,
but,
like
you
should
make
sure
that
it
is
somewhat
rare
like
if
it
is
very
common
and
if
it's
a
very
popular
request,
you
may
live
in
a
world
where
everybody
ignores
it
and
turns
it
on,
and
at
that
point
the
value
becomes,
you
know,
revert
like
inversely,
proportional
basically
right.
A
Yeah
because,
like
with
safe,
handle
dangerous
get
handle,
it's
you've
touched
this
and
now
safe
handle
can't
save
you
anymore
yeah
and
I
can't
think
of
other
dangerouses
off
the
top
of
my
head.
A
M
Yeah,
which
we
can't
do
for
you
I
mean
it
basically
boils
down
to
you-
have
to
read
the
manual
and
make
sure
you're
hardened
your
own
code
correctly,
but
it
isn't
like
the
problem
with
dangerous.
It's
a
bit
like
a
cop
out
about
basically
we're
saying
like
we
wash
our
hands.
We
told
you
that
if
you
it
up
you
it
up
and
you're
on
your
own
right,
but
like
it's
a
that
only
works
and
we
use
it
sparingly
right.
J
I
mean
the
good
thing
to
consider
is
that
websocket
is
a
relatively
rare
class
for
someone
to
use,
so
I
don't
think
we
would
be
polluting
the
you
know
the
the
public
mindset
of
what
dangerous
means
here,
even
if
this
did
end
up
becoming
a
common
thing
for
people
to
enable
with
web
sockets.
M
I
mean
it
kind
of
comes
to
the
other
thing
right
so
like
if
this
is
an
implementation
detail
of
some
high
level
protocol,
like
I
don't
know,
signal
r,
for
example,
in
asp.net,
they
shouldn't
turn
it
on
clearly
right.
They
should
expose
it
to
the
users
so
because
you
know
they
don't
know,
obviously
whether
you
put
in
user
supplied
data
or
not
so
yeah.
J
I
will
add
that
asp
has
a
flag
to
enable
outbound
compression.
It
is
not
named
dangerous
or
anything,
I'm
not
sure
if
it
was
introduced
before
crime
was
known
about,
but
that's
something
to
consider.
M
Yeah,
that's
kind
of
my
high
level
question
is
like,
regardless
of
the
you
know,
the
actual
mechanics
here
but
like
we
should
make
sure
that
if,
if
we
rely
on
renaming
that
we
catch
all
the
cases
where
people
would
opt
into
this
behavior
right,
so
if
there's
an
asp.net
feature,
for
example,
that
they
already
shipped-
and
maybe
we
have
to
invest
in
analyzer
anyway,
to
make
sure
that
we
catch
everybody
else.
J
Oh,
it
could
be
defaulted,
yeah,
I'm
not
sure
yeah.
I
guess
that
wouldn't
be
ambiguous
with
the
call
site.
A
J
F
A
A
G
M
Yeah,
I
think
you
should
add
the
other
thing,
which
is
make
sure
that,
if
they're
high
level
apis
like
asp.net
signal
r,
for
example,
that
if
you
want
to
make
people
aware
that
compression
might
be
a
bad
idea
that
we
have
corresponding
action
there,
either
either
by
renaming
or
analyzer
or
whatever.
The
mechanism
is.
M
E
M
M
The
other
ones,
I
don't
even
know
the
there's,
the
pod
reload
one,
and
then
there
is
the
the
json
one.
I
guess
the
json
one
is
longer
right.
It
wasn't
that
one
that
requires
more
discussion.
A
M
That
is
funny.
Did
I
only
send
it
out
to
myself.
M
Yeah,
I
can
probably
move
it
to
the
morning.
I
think
I
don't
know
why
I
booked
it
for
the
afternoon.
I
think
it
was
for
the
last
time
and
apparently
I
changed
the
series
which
wasn't
the
intent,
so
I
will
probably
move
it
to
the
morning
slot
because
we
tend
to
be
more
productive
in
the
morning
than
in
the
afternoon.
M
All
right,
then
I
see
you
all
on
thursday,
I
guess
jeremy
thanks
for
hosting
anytime,
I
had
a
good
time
in
tactics
which
is
not
something
people
often
say.