►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
A
C
C
D
A
E
E
So
it's
not
clear
to
me
that
well
two
things:
it's
not
clear
that
that
code
is
entirely
correct
from
a
runtime
point
of
view,
because
I'm
not
sure
ordering
release
is
sufficient.
I
think
you
may
need
acquirer
release
in
order
to
prevent
the
hardware
from
moving
the
load
across
the
decrement,
and
that
aside,
I
would
expect
the
compiler
to
be
required
to
enforce
ordering
that
is
no
less
strict
than
the
ordering
parameter
passed
to
an
atomic
operation.
A
Yeah,
I
can
believe
that
too.
So
these
are
all
points
that
are
important
in
terms
of
the
you
know
the
arguments
being
put
forward
here.
C
So
josh,
for
the
second
point,
I
don't
think
it
applies
here,
because
this
is
a
shared
reference
to
something
immutable.
So
even
if
there's
synchronization,
no
other
thought
would
be
allowed
to
mutate,
so
we
can
do
the
load
whenever.
C
So
I
don't,
I
agree
with
the
first
point:
there
should
be
acquire
release
or
what
the
real
code
is
does
is.
If
predacker
is
one
then
do
an
acquire
fence,
but
I
don't
agree
with
the
second
point.
I
could.
E
E
So
the
assumption
is
that
on
line
73
here,
there
would
be
a
an
acquire
fence
buffer.
I'm
not.
C
A
store,
a
load
which
which
synchronization
yes
or
no
nobody
can
mutate
that
memory,
if
assuming
the
reference,
is
indeed
live
until
the
end
which
it
isn't.
But
if
it
were
then
so,
let's
assume
there's
another
use
of
inner
dot
payload
label
somewhere
at
the
bottom.
A
C
C
B
C
A
B
Of
their
last
use,
protector
like
ralph
is
that
if
this
were
a
function
parameter
if
enter
were
a
function,
parameter
of
type
ampersand
enter.
C
C
Yes,
that
will
change
everything.
Okay,
so
so
the
the
the
optimization
that
is
actually
in
conflict
with
what
arc
is
does
is
the
kind
of
optimization
that
would
break
arc
like,
for
example,
the
compiler
could
ch
in
fetch
sub
at
after
the
fetch
and
other
read
another
tommy
agreed
well.
Well,
actually,
it's
an
atomic
thing.
Yes!
C
Well,
it's
lvm
race
is
okay,
it
could
add
another
read
after
the
fetch
and
decrement
inside
that
function,
and
it
can
do
that
because
the
function
takes
as
an
argument
or
shared
reference
which
is
guaranteed
to
be
live
for
the
entire
function.
Call
that's
what
the
reference
of
the
attribute
means.
E
I
think
that
supports
the
argument.
The
case
mentioned
later
in
this
document
that
just
the
existence
of
a
shared
reference
to
inner
is
itself
questionable,
because
that
reference
doesn't
have
a
long
enough
lifetime.
C
C
References
are
still
active
in
the
sense
of
they
have
guarantees
and
assumptions
and
stuff
associated
with
them.
The
stack
borrows
approach
generally
is
a
reference
is
active
only
until
it's
last
used.
A
So
ralph
in
particular
I
I
so
I'm
first
of
all,
I'm
totally
you
know
in
agreement
that,
like
there's
lots
of
reasons,
this
optimization
is
broken.
That's
part
of
the
point
of
the
conversation,
it's
also
to
say
that
I
think
some
people's
mental
models
of
what
these
references
mean
still
might.
They
might
still
think
that
the
opposition
is
not
broken.
It's
important
to
spell
that
out,
but
in
terms
of
what
you're
saying
where
for
function,
parameters
they're
treated
differently.
A
If
you
look
at
the
write
up
the
not
the
one
in
the
blog
post,
but
the
one,
that's
the
hack
md,
that's
that's
under
discussion
from
the
from
the
zulip
topic
for
this.
This
meeting
there's
a
version
two
it's
on
line,
90
of
the
source
version
of
the
document.
This
is
the
one.
I
think
that
most
course,
closely
corresponds
apart
from
the
release
ordering
which
may
may
or
may
not
be
broken,
probably
is
broken
rather,
but
the
thing
here
is
the
may
drop
inner.
A
Now
the
inner
thing
is
a
reference
to
inner
it's
a
function
argument
there
is
a
reference
to.
There
is
a
use
of
label
which,
if
you
look
where
it
comes
from
it
is
it
comes
from
loading
off
of
something
off
of
inner.
If
you
believe
the
compiler
is
going
to
optimize
both
these
things
together,
either
that
or
move
the
label
definition
inside
of
may
drop
in,
or
this
is
a
case
where
the
optimization
could
be
applied.
C
Maybe
it's
a
bit
hard
with
the
label
thing
because
there's
a
lot
that
has
to
that
the
compiler
has
to
figure
out
right.
C
Something
much
simpler
in
major
if
you
entirely
ignore
label
the
point
of
the
referenceable
is
that
the
compiler
can
introduce
superior's
loads
like
loads,
where
there
were
none
before
yeah.
C
A
Right
so
I
think
it
sounds
like
it
may
be
somewhat
advisable
to
try
to
ensure
that
code
like
this,
we
make
it
clear
that
you
can.
You
should
not
write
your
your
atomic
reference
kind
of
data
structure,
whatever
it
is
in
this
manner
because
of
this
issue,
the
other
and
the
other
ones.
Maybe
may
or
may
not
be
okay,
but
it
sounds
like
this.
One
is
definitely
not
okay.
Under
our
current
system,.
A
Okay,
all
I
want
to
say
is
underway.
Rest
is
currently
implemented,
etc.
It's
important
to
try
to
convey
that
this
is
not.
This
is
not
legal
and
that
we
should
just
and
as
a
lang
team.
We
should
be
aware
of
this
and
figure
out
the
way
to
tell
people
that
or
decide
that
it
needs
to
be
legal
and
then
compiler
implementation
needs
to
change
accordingly,
so
yeah.
C
I
think
the
the
main
point
here
is
to
if
the
point
is
to
to
like
draft
the
design
space
would
be
to
understand
this
particular
example
and
to
understand
why,
under
the
proposed
fix
that
you
that
that
you
like
so
much
and
that
I
also
like
this,
would
still
be
illegal
right
and
then
once
we
understood
why
why
that
is
the
case
and
what
the
what
that
is,
then
to
start
figuring
out.
If
that's
okay
for
us.
B
Yeah,
it
doesn't
matter
is,
is
basically
we
do
not
have
right
access
to
the
in
to
all
the
data.
That's
in
inner
right.
C
A
C
C
C
B
C
B
As
read
as
immutable,
you
have
immutable
access
to
an
internet
label.
Is
that
what
you
said.
C
No,
I'm
saying
it's
not
just
we
have
immutable
access,
it's
saying
so
that's
the
that's
the
thing
we
can
do,
but
there's
something
stronger.
It's
we
can
rely
on
nobody
having
mutable
access
which,
which
might
encompass
you
might
think,
just
follow
automatically,
but
that's
a
very,
very
different
statement
right.
This
is
the
difference
between
a
shared
reference
and
a
constant
pointer
like
in
conspirator
and
c.
We
have
immutable
access,
shared
reference.
No,
furthermore,
we
know
nobody
else
has
mutable
access.
We.
D
B
C
A
C
De-Allocate
we'd
read-only
means
must
not
be
de-allocated.
Yes,
because
we
are
assuming
nobody
else
can
write.
So
certainly
nobody
else
can
de-allocate.
That
is
the
current
stanza
in
stack
borrows
and
if
this
is
basically
required
for
any
optimization
around
shared
references
like
if
we
it's
it's
references
are
useful
because
we
can
rule
out
others
writing
to
that
memory.
C
A
The
way,
the
way
this
bullet
is
written
right
now
it
doesn't-
I
mean,
we've
already
said
this
multiple
times.
I
just
want
to
make
a
point
about
it
again.
The
role
of
this
is
a
function.
Parameter,
I
think,
is
important,
because
if
it
was
under
the
things
we're
talking
about,
it's
not
part
of
the
bullet
as
written.
Unless
you
understand
that
the
point
where
we
do
the
allocation,
the
lifetime
of
the
inner
has
extended
overlapping
that
point,
because
it's
a
function
parameter
and.
C
B
A
C
B
C
B
B
No.
No
I'm
bringing
it
up
because
I
don't
know
if
I
like
this
rule,
but
this
is
why?
Because
I
think
this
code
has
to
be
okay
as
written,
and
by
has
to
be
okay,
I
just
mean
I
it
just
feels.
Well,
maybe
I
should
let
me
back
up
from
that
statement.
Could
someone
show
me
the
correct
way
to
write
this
code
change
inner
to
a
pointer.
A
A
C
B
C
Again,
that's
current
stack
borrows
roots,
not
not
necessarily
anything
set
in
stone.
C
So
nico,
even
your
proposal,
which
we
haven't
quite
made
yet
to
somehow
bubble
up
the
unsafe
cell
breaks.
If
we
slightly
change
the
example
to
be
even
more
artificial,
arguably,
but
still
if
we
replace
the
inner
pointer,
shade
reference
by
two
shade
references,
one
to
the
atomic
cell
and
one
to
the
label.
C
B
To
computer
to
to
compilery
or
something
but
the
way
I
think
of
it.
The
way
I
think
of
shared
borrows
is
that
when
I
make
a
reference
like,
I
have
anchored
my
right
to
use
that
memory
through
the
existence
of
that
reference,
and
so
it's
not
surprising
to
me
that
when
I
create
two
anchors
I
can't
free
one
and
expect
it
to
affect
the
other.
But
I'm
toying
over
this
question
of
raw
pointers,
where
I
agree
where
I
was
going
to
go,
pajamas
will
just
go.
B
There
was
yeah,
you
could
imagine
bubbling
up
the
unsafe
cell,
but
I
don't
think,
as
as
taylor
said,
I
don't.
I
don't
think
I
want
to
tell
people
that
they're
allowed
to
mutate
memory
that
is
outside
of
an
unsafe
cell,
even
if
stack
borrows
currently
allows
it,
for
example
within
enums.
I
don't
think
we
want
to
tell
them
that's
actually,
okay,
like
maybe
we
tell
them,
that's
ub
we
can't
detect
yet,
but
it's
still
ub
and
that
seems
to
imply
that
making
mutation
and
deallocation
equivalent
is
not
great.
D
I
don't
think
we
should
say
that
you
can
de-allocate
or
mutate
things
that,
like
in
that
example
right.
I
don't
think
that
an
enum
containing
an
unsafe
cell
in
one
of
the
variants
is
safe
to
de-allocate
or
mutate.
So
I
think
that
I
view
mutate
and
de-allocation
with
sort
of
the
same
permissions
in
the
way
that
ralph's
thing
feels
thinking
about
it.
C
Bubbling
is
currently
this
inner
pointer.
The
shared
reference
has
different
permissions
for
different
parts
of
memory
for
the
for
the
atomic
cell.
Part
of
what
it
points
to
this
is
a
shared
read,
write
situation
where
it
can
mutate,
but
it
also
knows
others
might
mutate.
That's
what
an
unsafe
cell
does.
D
C
So
the
permission
is
kind
of
in
a
grained
way,
depending
on
the
on
the
types
of
the
fields
of
the
thing
that
inner
points
do.
C
But
we
could
just
say
inter
is
not
a
freeze
type
and
hence
it's
going
to
have
shared,
read
write
for
everything
inside
indiscriminately
of
what
the
more
fine
grained
type
is,
and
that
would
make
the
life
of
of
people
doing
cockproofs
about
these
things
a
lot
easier.
It
will
also
make
some
of
my
ideas
for
future
versions
of
stackburrows
that
solve
some
of
the
current
problems,
a
lot
easier.
B
C
C
B
Wait,
can
you
repeat
that
part,
oh
you're,
you're,
basically
saying
I
see,
I
think
what
you're
saying
is
if
we
remove
the
unsafe
cell
or
sorry
if
we
go
with
this
rule,
that
says
when
you
have
a
reference
it,
because
some
parts
of
that
of
that
reference
are
because
some
par,
if
you
have
a
reference
to
inner
and
ampersand
inner,
and
even
though
we
consider
it
you
be
like,
and
we
have
the
rule
that
says
that
you
can
only
de-allocate
what
you
can
mutate.
B
C
B
C
Because
you
can
only
allocate
the
entire
thing,
because
we
know
with
the
operational
semantics,
there's
no
way
to
de-allocate
part
of
an
allocation.
Actually,
I
have
to
take
that
back.
We
could.
We
have
to
take
one
more
reasoning,
step.
We
have
to
assume
this
extra
invariant
and
then
we
could
say
it's
the
referenceable,
because
anybody
who
would
de-allocate
label
sorry
anybody
who
would
deal
look
at
refcom
would
also
be
allocate
label.
E
C
B
Right,
so
your
reasoning
is,
if
there's
at
least
one
bite
not
inside
an
insect
cell,
then
you
cannot
de-allocate
and
you
can't
de-allocate,
just
the
bytes
that
are
in
the
insects
in
an
unsafe
cell.
Therefore,
those
bytes
also
won't
be
de-allocated,
but
they
could
be
like
racially
mutated.
I
don't
know,
but.
C
E
A
C
Yeah,
I
I
yes,
I
mean
just
lots
of
little
ways
to
finesse
this.
To
make
the
rules
precise
anyway,
will
require
a
lot
of
interesting
effort.
D
Yeah,
so
certainly
certainly
it's
the
case
that,
like
if
you
had
two
fields
in
a
structure
that
were
both
unsafe
cell
and
then
you
had
like
some
padding
after
them
to
compensate
like
that.
That
would
still
be
that
that
structure
would
still
be
all.
We
would
consider
immutable
and
valid
to
de-allocate
right.
E
Proposed
it
actually
can
I
I
have
a
can
I
restate
this
in
the
positive
rather
than
the
negative,
in
order
to
free
something,
you
must
be
permitted
to
write
to
every
bite
of
it.
Thank
you.
Yeah.
E
Well,
that
helps
because
you're
not
technically
supposed
to
fiddle
with
padding
bites
so
depending
on
how
we
define
that
that
may
be
sufficient,
but
yeah.
If
you
can
write
to
every
bite
of
something
you're
allowed
to
free
it
because
freeing
it
may
cause
it
to
subsequently
be
arbitrarily
mutated
as
something
new
gets
stuck
over.
It.
C
Right
previously,
yes,
I
mean
that
is
exactly
the
new
rule.
If
you
the
the
the
version
of
the
kind
of
the
guarantee
version
of
the
rule
where
so
far,
we
spoke
about
the
rely
version,
so
the
perspective
of
everybody
else.
D
To
clarify
here,
we're
assuming
that
I'm
sorry
maybe
we're
over
over
focusing
on
this
and
we
should
move
on.
But
here
we're
assuming
that
you're
permitted
to
write
to
paddingbytes
for
the
definition.
That's
for
the
purposes
of
this
definition.
D
C
A
In
terms
of
what
so
I
believe
this
reflects
the
proposal
that
was
put
forth
the
unsafe
code
guidelines
group,
so
I
think
I
think
this
is
a
you
know.
An
attempt
to
state
cleanly
what's
been
proposed
and
I
think
it's
a
pretty
good
rule.
The
only
que
it
does
mean
that
it's
gonna,
if
we
adopt
this
rule,
it
does
mean
the
code
with
ampersand
enter
is
not
correct,
like
I
want
to
make
that
very
clear.
A
A
A
Something
is
allowing
these
kinds
of
volatility
allocations
like,
and
but
this
would
require,
then,
that
other,
that
you
know
code
in
the
wild,
be
updated
to
use
that
kind
of
marker
if
it's
another
marker
type
or
an
attribute
or
whatever
some,
and
that
would
be
some
way
then
to
say
on
the
inner
struct
hey
this
whole
thing
you
know,
might
get
the
allocated
and
unsafe
codes
to
be
aware
of
that.
The
compiler
has
to
be
aware
of
that.
Yeah.
E
A
Because
it
would
be
a
more
refined
way
of
because
it
wouldn't
necessarily
have
all
the
capabilities
that
on
safety
cell
gives,
gives
you
first
of
all
right.
It's
a
pretty
narrow,
it's
a
narrower
thing
to
add
it's
not
necessarily
good,
because
it's
this
whole
new
api
surface.
You
have
to
sort
of
provide
and
explain,
but
it's
probably
an
attribute
or
a
rapper
or
something.
C
B
C
B
A
C
Would
probably
prefer
bubbling
out
for
once?
I
said,
but
that's
mostly
formulated
reasons,
but
I
think
not
having
not
having
references
that
have
different
permissions
for
different
memory.
Locations
simplifies
the
model,
a
lot
which
I
think
could
could
be
helpful
for
well
obvious
reasons
of
making
things
simply
simpler
and
and
for
letting
me
use
some
different
structures
instead
of
these
stacks
to
handle
all
the
permissions.
B
B
And
the
only
question
that
is
a
little
bit
unclear
to
me
is
whether,
knowing
that
something
might
be
freed
versus
mutated,
how
much
of
a
difference
that
makes.
I
certainly
agree
with
the
point
of
view
that
you
know
freeing
is
just
mutating
with
undefined
bytes
or
something
it
seems
like
a
pretty
useful.
C
At
some
point
but
different
optimizations,
because
if,
if
we
see
anywhere
later
in
the
function
and
other
access
to
this
location,
we
know
it
definitely
hasn't
been
freed
because
it
would
be
ub
to
access
free
memory.
Yes,.
B
C
B
Nonetheless,
I
do
yeah,
so
I
guess
my
point
is
that,
like
adding
flags-
and
things
like
that
are
still
once,
you
know
that
there's
a
problem,
I'm
not
sure
adding
flags
is
so
great,
like
the
goal
of
that
is
just
to
make
it
more
ergonomic,
basically
right
and
I'm
not
sure
it's
that
much
more
ergonomic
than
knowing
to
use
raw
pointers.
Maybe
we
can
make
raw
pointers
more.
I'm.
A
Really
curious
with
this,
this
recommendation,
these
raw
pointers
versus
narrowing
in
on
the
I
guess
your
point
is,
you
might
mind,
helpers
that
need
access
to
the
other
piece
of
destruct,
but
it's
funny
because
it's
you're.
A
Have
to
reason
very
carefully
about
the
when
things
survive
too.
D
B
Drop
doesn't
have
to
have
a
well
wait
actually.
D
A
We're
at
five
minutes
remaining
just
to
warn
people.
D
B
B
A
So
it
was
more
a
question
of
reasoning
in
terms
of
like
why
I
thought
that
blast,
so
the
blast
radius
includes
buddy
fields
was
like
was
meant
to
be
the
same
thing
as
bubbling.
I
think,
and
my
incl
my
interpretation
was
that
bubbling
effectively
is
allow
them
all.
But
I'm
curious
whether
you
disagree
with
that
you.
C
A
I
have
to
think
about
that
again.
My
attitude
is
that
I
think
that
was
in
part
based
around
the
idea
that
I
was
at
first
thinking
that
people
that
this
that,
let
me
think.
B
I
mean
what
I
would
say
is
that,
and
I
think
it
depends
on
your
point
of
view,
what
subtle
means,
but
in
under
the
mutation
is
freedom
model,
strict
one
ampersand
foo
like
no
matter
what
foo
is
reference
kind
of
means
the
same
thing
except
for
this
one
case
of
ampersand
unsafe
cell,
whereas
the
bubbling
model
I
feel
like
makes,
can
I
say
it
makes
the
meaning
of
a
reference
more
there's
a
much
water
range
of
family,
of
types
where
the
meaning
of
of
ampersand
sort
of
depends
right.
B
A
C
A
C
B
A
A
Case
two
sorry
case
two
variant.
Two,
I
don't
think
I
want
variant.
Two,
that's
right!
The
one
we've
been
talking
about.
That's
right!
That's
right!
I
basically
I'm
unhappy
with
allowing
variant
two,
because
I
think
that
it's
really
goofy,
but
I'm
but
part
of
my
thing
is.
I
even
think
that
varian
1
is
goofy.
I
I
would
prefer
that
that
someone
didn't
have,
but
I
know
I
understand
it's
nll
etc.
A
But
it's
just
interesting.
Where
is
the
last
rep?
So
look
at
looking
at
version,
one,
the
one
where
you're
taking
in
a
ref
and
you're
working
on
that?
I
guess
the
last
reference
is
the
point
where,
if
this
last
reference,
there
is
the
point
where
you
do
the
dereference
to
get
out
the
ref
count
itself
right.
It's
not
the
point
of
the
cast
to
the
star
const.
A
Yeah.
Okay,
the
point
is
I
I
still
I
understand
the
reasoning
behind
why
function
arguments
are
special,
but
I
was
trying
to
nonetheless
come
up
with
a
model
where
they
weren't
and
still
say
version.
Two
is
wrong:
how
does
that
sound
ralph?
Does
that
make
sense
like?
I
think
that
variant
two
is
wrong
version
two
is
wrong.
I
would
like
it
to
be
wrong
for
reasons
other
than
function,
arguments
being
treated
specially.
C
Like
there's
an
easy
way
to
make
function,
arguments
not
special
in
stack
burrows,
but
then
all
of
the
bottles
are
loud.
All
of
the
words
are,
I
think
we
want
function.
Arguments.
B
D
C
D
C
B
A
B
C
So
felix,
I'm
okay,
I'm
sorry
for
going
over
time
here!
Stop
me
if
that's
a
problem,
but
I'm
wondering
why
what
what
bugs
you
about
variant
ii,
if
it's
not
the
function,
argument
being
special.
A
A
B
A
Right
and
that's,
I
guess
you
know
a
matter
of
taste
that
I
have
to
accept
or
something
there's
good.
Probably
I
mean
if
look,
it
sounds
like
there's
very
solid
arguments
for
why
we
need
to
allow
people
to
write
the
other
way.
It
seems
to
me
like
the
fact.
A
B
Sure
they
should
just
use
raw
pointers
using
non-raw
pointers
is
subtle
like
if
you
might
free
something
you
can
sometimes
do
it,
but
why
would
you.
B
B
B
But
I
think
of
I
do
think
of
the
and
that
that
fits
my
model
with
the
function
calls
because
the
way
I
think
of
that
in
my
head
is
it's
the
parent
who
sort
of
gets
depict
if
they
use
it
again,
like
they're
sort
of
using
it.
I
know
they're
not
really
using
it.
It's
not
quite
right,
but
that's
how
it
works.
For
me,
in
my
my
mind,
they've
lent
it
to
me.
I
have
to
give
it
back.
A
Okay,
so
what
in
terms
of
action
is
from
this
meeting
itself
like
it
sounds
like
we
have
rough
consensus
to
actually
go
forward
with
the
the
succinct
version
that
josh
mentioned.
I
think,
does
that
sound
plausible,
the
idea
that
where
was
it,
I.
C
So
so
what
we
haven't
talked
about
is
the
downsides
right
like
and
now
I'm
obviously
too
late
to
start
now,
but
just
to
enumerate
we
lose
the
referenceable
on
some
functional
arguments.
C
I
mean
I
mean
I
mean
in
in
in
the
easy
version
to
implement.
We
lose
it
for
everything
or
freeze
more
precisely.
We
could
add
it
back
in
some
cases.
That's
the
part
where
we
get
into
the
bites
and
petting
bites
and
whatever,
but
we
certainly
lose
it
for
ampersand,
unsafe
cell
and
things
isomorphic
to
that.
A
C
We
still
get,
we
still
get
the
referenceable
on
entry
right.
So
there's
this
entire
other
part
of
the
story
where
the
reference
turns
out.
Lvm
was
very
wrong
about
the
reference
symbol,
because
they
added
that
very
simple
references
which
are
already
not
guaranteed
to
outlive
the
function
called,
so
they
have
to
point
it
anywhere.
I.
B
C
B
Yeah,
that's
fine.
We
can
do
it
for
convenience,
but
it's
I
would
assume
it's
like
temporary.
Until
somebody
gets
less
lazy
and
writes,
writes
the
proper
patch.
B
C
Yeah
yeah,
it
also.
F
C
A
C
C
A
B
A
This
was
confusing
to
me
because
I
thought
earlier
you
were
saying
you
could
cast
it
back
to
a
a
reference
and
the
lifetime
would
be
fine.
Is
that
not
the
case
here?
No,
it
just
doesn't
work
to
cast
it
back
to
a
shared.
C
B
C
A
C
B
That
actually
may
not
be
that,
like
the
only
difference
between
that
and
mutation
is
freedom
from
my
point
of
view,
like
I
think
in
practice,
everyone's
gonna
use
raw
pointers
everywhere
under
mutation
is
freedom,
that's
going
to
be
the
rule
and
you're
only
going
to
use
references?
If
you
know
it's
not
getting
freed
and.
A
B
C
B
A
B
It's
I
think
it's
superior,
the
only
real
downside
is
you
don't
get
the
no
d
referenceable
on
anatomic
you
size,
four
new
types
thereof,
right,
yeah
and
really
unsafe
cell.
A
C
So
right
so
mutation
is
freedom,
doesn't
technically
directly
say
anything
about
volatile,
but
mutation
is
freedom,
makes
it
so
that
we
don't
add
the
referenceable
for
okay
mutation?
Is
freedom
plus
bubbling
makes
it
certain
it
makes
it
so
that
we
cannot
possibly
add
the
referenceable
for
things
containing
unsafe
cells,
which
means
unsafe
cell
is
volatile.
D
C
B
C
C
As
freedom
is,
is
one
step
towards
mutation
is
volatile
and
the
difference
between
the
two
in
terms
of
what
the
compiler
can
do?
Isn't
that
big
right,
the
the
only
thing
that
we
lose?
If
we,
if
we
say
a
mutation,
is
worth
high
freedom,
I
don't
know
if
that
makes
any
sense
is
that
we
can
no
longer
make
this
argument
that
I
mentioned
that
some
other
byte
of
this
allocation
cannot
be
de-allocated,
so
this
byte
cannot
be
de-allocated,
so
we
can
add
the
reference.
D
D
B
C
B
The
framing
of
this
is
just
downsides,
is
really
amusing,
but
I'm
gonna
rework
this
table
but
like
how
is
there
some
reason?
Mutation
is
volatile
freedom
and
I
know
we're
we're
15
minutes
over,
but
I
can't
help
it.
I
feel
like
we're.
Fine,
I'm
I'm
understanding
things
and
I
don't
want
to
stop.
If
mutation
is
volatile
freedom,
what
is
it?
Why
is
this?
What
you
all
were
getting
at,
that
bubbling
and
mutation
involved
in
freedom,
are
like
they
have
the
same
downsides.
Is
there.
C
C
Full
bubble,
yeah
that
I
mean
that's
what
I
thought
we
meant
about:
yes,
yeah,
okay,
whereas
even
mutation
as
volatile
freedom
doesn't
means
you
can
still
expect
the
read-only
parts
of
your
type
to
be
read-only.
Basically,
I.
C
A
C
So
so
there
are
people
that
really
want
to
have
references
that
don't
permit
volatile
reads,
because
references
are
much
more
ergonomic
than
using
raw
punches
for
all
of
that,
which
is
the
obvious
alternative,
so
people
think
okay,
we
do
mm-io,
we
just
wrap
our
mmo
registers
into
unsafe
sun
all
is
okay.
Well,
technically,
it
isn't,
because
okay.
D
B
B
Is
whether
volatile
I
mean
the
question
between
these
two
is
sort
of
how
much
between
the
between
mutation
and
freedom
and
mutations
volatile
freedom
is
like?
Is
it?
Is
there
optimization
difference
between
being
unsafe
cell
and
being
volatile
cell
that
we
want
to
preserve
and
at
the
cost
of
people
having
to
say
right?
Is
that
right,
yeah.
C
It's
the
reference
of
the
attribute
right:
it's
it's
that
the
compiler
can
introduce
various
reads
when
they
are
when
it
somehow
deduces
that
the
allocation
cannot
happen.
If
you
ignore
volatile,
then
asperger's
read
is
okay.
Whenever
the
memory
certainly
exists
right,
if
we
take
into
account
volatile
the
spurious
read
is
not
okay,
because
that
might
make
the
hardware
do
something.
D
Inside
the
same
structure
as
as
something
else
right,
we
would,
we
would
do
the
same.
B
B
D
D
B
Right,
I
think,
there's
an
interesting
question
in
my
mind
of
if
I
I
accepted
the
argument
that
when
I
see
that
you
can
pass
ampersand
self
and
fetch
sub,
I
might
infer
that
I
can
take
a
function
that
takes
an
ampersand
atomic
use
size
and
it
would
be
nice
if
that
was
true,
which
is
not
the
case
for
unprotect
the
atomic
methods.
B
It's
interesting
that
it
seems,
I
think,
there's
always
okay,
there's
a
decent
case
to
be
made
that
I
might
further
infer
that
I
can
rapid
instruct
with
other
fields,
and
it's
interesting
that
that's
not
true.
I
don't
I
don't
know
in
terms
of
like
user
intuitiveness,
I
don't
know
where
the
drop-off
is,
but.
B
A
If
I
don't
know
if
I
follow
that
in
terms
of
why,
like
because
you're
here
we're
not
talking
about
all
cases
where
you'd
wrap
and
wrap
another
structure,
this
is
a
specific
case
we're
implementing
an
arc
or
something
we
are
doing
a
de-allocation
that
covers
those
other
things.
Unless
you
have
to
reason
about
those
other
things
as
well
right,
that's
right!.
B
Read
the
read
the
dots
or
you
know,
infer
that
they
can
use
ampersand,
atomic
util
and
c,
and
there
and
jump
from
that
that
they
can
rapidly
destruct.
All
those
steps
seem
pretty
likely
to
me,
but
then
d
actually
be
implementing
arc
or
something
that
will
free
when
the
like
doing
this
atomic
cell.
In
order
to
manage
memory
lifetimes,
which
I
agree
is
probably
relatively
unlikely.
But-
and
I.
A
B
A
C
D
C
B
C
I
want
to
get.
I
want
to
get
back
to
bubbling
eventually,
but
not
for
this
discussion,
so
this
discussion
no
bubbling,
but
have
this
tiny
extra
step
for
for
volatile,
which
means
we
lose
more.
The
reference
of
attributes.