►
From YouTube: 2020-10-14 Backlog Bonanza
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
C
D
Yeah,
so
I
just
to
refresh
everybody's
memory.
We
talked
about
this
in
the
last
backlog
meeting
on
here,
and
the
sort
of
general
consensus
was
that
we
wanted
something
to
solve
this
problem.
D
This
problem,
being
the
ability
to
have
more
accurate,
derives
that
take
into
account
what
type
parameters
and
what
type
bounds
are
actually
necessary,
but
that
we
didn't
particularly
like
the
everybody's
sort
of
gut
reaction,
was
that
this
rfc
wasn't
quite
the
way
we
wanted
to
see
it
happen,
and
so
I
I,
though,
felt
sort
of
uncomfortable
with
the
idea
of
closing
this
rfc
without
actually
having
read
it
first,
so
I
went
and
read
it
and
I
actually
I
don't
know
I
found
that
I
liked
it
more
than
I
expected
I
would
based
on
the
previous
discussion.
D
I
think
my
kind
of
gut
check
on
this
rfc
was
that
I
saw
the
the
syntax
initially
and
was
sort
of
like
taken
aback
by
it,
but
after
after
reviewing
it,
it
seems
like
it
has
some
sort
of
nice
properties
in
terms
of
how
it
interacts,
with
the
way
that
you
would
spell
spell
these
bounds
and
it's
sort
of
a
more
flexible
and
more
general
option,
and
I
think,
is
like
a
little
bit
more
intuitive
than
some
of
the
other
syntaxes
that
got
proposed
in
the
doc
that
were
using
that
were
using
some
some
like
derived
or
sorry.
D
Some
prop
macro
specific.
You
know,
syntaxes,
like
x,
type
or
or
something
like
that.
With
that
in
mind,
the
actual
proposal
in
the
like
reference
section
of
the
rfc
is
primarily
about
extending
the
types
of
syntax
accepted
by
derived
based
procedural
macros,
and
so
I
I
think
that
that's
actually
a
pretty
reasonable
starting
place
would
be
to
come
up
with
a
shape
that
that
looks
something
like
this
and
decided
to
to
start
allowing
procedural
macros
to
accept
it.
D
D
There
are
some,
like
particular
little
thorny
bits
around
the
exact
naming
of
types
and
how
shadowing
works
then,
and
I'm
not
I'm
not
sure
exactly
how
how
what
we
want
to
do
in
those
cases-
and
I
don't
I'm
not
sure
that
I
totally
agree
with
the
rfc's
position,
but
it
does
actually
have
a
proposal
there
and
get
in
adding
this
ability
to
procedural
macros
would
give
us
the
chance
to
sort
of
experiment
with
this
and
come
up
with
and
and
see
you
like
what
worked
for
people
in
practice.
A
D
Of
the
rfc,
but
that
we
didn't
know
we
didn't
see
an
answer
to
in
the
rfc
at
the
time
was
the
ability
to
apply
these
these
sorts
of
patterns
and
and
shifted
bounds
to
multiple
different
trade
impulse,
for
example.
If
if
you
only
had
a
certain
type
parameter
inside
of
a
phantom
data,
you're
inside
your
type,
you
might
imagine
that
you
don't
need
that
that
type
as
a
bound
for
any
of
your
impulse
copy
clone.
D
You
know
debug
or
anything
right,
and
so
it
would
be
convenient
to
have
a
syntax
for
that.
The
rfc
proposes
or
doesn't
propose
but
suggests
possibly
a
further
extension
where
we
used
plus
to
to
signify
this.
I
don't
love
that,
but
and
it
sort
of
merits
its
own
discussion,
but
I
basically,
where
I
landed
on
this-
was
that
I'm
I'm
more
open
to
this
rfc
that
I
than
my
initial
reading
so.
C
So
you
were
saying
that
I
I
kind
of
got
lost
at
the
end
there,
but
but
before
that,
the
high
level
part
is
that,
like
this,
rsc
specifically,
is
really
just
about
extending
the
set
of
syntax
or
I
guess
it
has
two
parts.
One
is
extending
what
the
derives
can
accept
and
the
other
is
making
a
specific
proposal
for
what
they
should
do
or.
D
Yeah
yeah,
it's
both
of
those
and
the
specific
way
that
it's
extending
the
syntax
does
sort
of
push
towards
the
the
direction
being
the
syntax
being
offered
by
the
rfc.
But
there
are
some
particulars
with
how
I'm
trying
to
figure
out
the
right
way
to
phrase
this.
D
There
are
some
particulars
of
how
this
interacts
syntax
interacts
with
other
language
semantics
that
you
could
kind
of
make
to
interesting
decisions
about
that
aren't
strictly
based
around
the
syntax,
and
those
are
things
that
I,
I
would
think,
might
merit
some
experimentation,
at
least
on
on
nightly
in
user,
written
procedural
macros.
C
D
C
It
should
be
like
this,
and
I
see
so.
What
is
the
the
actual
syntax
that
is
being
like,
what's
being
proposed
in
a
in
terms
of
the
extension
to
drive?
Is
that
you
can
put
these
angle
brackets
and
they
get
passed
as
like
an
extra
set
of
tokens
or
something
to
the
derivative
right.
D
C
D
So
I
I
conceptually,
I
think,
it's
helpful
to
think
about
it
as
though
it
has
an
impul
before
it
before
the
angle
brackets,
because
if
you,
if
you
add
an
impul
there,
it's
literally
just
like
the
header
that
we
have
with
some
like
collision
added.
D
B
You
know
sorry,
this
is
a
bit
jumping,
but
you
just
said:
if
you
typed
out
the
impul
header
yourself
and
then
it
just
sort
of
worked
it
made
me
go
made
me
have
a
little
out
there
idea
of
like.
Can
we
like
what
version
of
this
could
be?
You
actually
type
out
the
impul
header,
and
then
we
have
a
some
way
of
just
it.
Auto
derives
the
internals
with
presumably
some
sort
of
marker.
B
B
B
D
Yeah
you
brought
up
an
interesting
point
there,
which
is
that
already
today,
there's
a
bunch
of
proc
macros
that
have
needed
ways
to
resolve
this
problem.
For
example,
the
fall
off
from
like
having
to
write
serialize
or
deserialize
implementations
in
survey
versus
writing.
A
drive
for
them
is
quite
significant
in
terms
of
difficulty,
and
so
there's
already.
D
There
are
already
workarounds
and
crates
like
that,
and
if
we
maybe
had
a
way,
a
standard
way
of
doing
it
and
and
ways
to
give
those
macros
more
information
that
that
could
be
sort
of
helpful
and
having
that
align
with
a
general
purpose,
syntax
that
users
learn
when
they
learn
rust,
rather
than
when
they
learn
such
and
such
procedural
macro,
I
think,
would
be
helpful.
D
Say
say
more
about
what
what
the
question
is.
I
mean
I
think
it
does
address
a
problem,
but
maybe
there's
an
additional
problem
that
you're
asking
about
that.
C
D
That
seems
like
a
better
ask
to
to
david,
but
I
don't.
I
don't
want
to
claim
that
too
early,
but
it
does
seem
like
this
is
a
problem
that
would
be
common
to
many
derived
macros
and
having
a
common
syntax
that
it
answers
that
sort
of
problem.
Rather
than
asking
procedural
macro
authors
to
all
come
up
with
their
own.
D
C
C
Yeah,
but
but
to
dial
back,
because
I
think
we
got
to
move
on
like
the
question
is
I
guess
if
we
were
to
accept
the
rfc,
that
would
mean
we
approve
this
general
direction
and
we're
going
into
some
experimentation
phase
or
something
like
at
most
right.
We
don't
the
details,
we
don't
necessarily
agree
with
it
feels
like
it
feels
like
it
feels
like
a
project
to
me.
C
D
So
I
think
I
agree
with
that,
so
I
I
guess
I
would
maybe
the
feedback
here
is
that
we
want
to
ask
for
a
proposal
for
experimentation
with
this
like
adding
this
syntax
to
procedural
macros,
and
that
we
would
be
like
inclined
to
accept
a
proposal
like
that.
If
there
were
people
who
were
interested
in
taking
that
on,
I
guess.
C
Yeah
I
mean
I
would
I
don't
know
how,
if
how
much
I
can
speak
for
a
full
like
linkedin
consensus,
but
I
think
saying
I
would
definitely
entertain
a
project
proposal
to
add.
You
know.
Add
the
syntax
make
a
group
that's
going
to
like
chase
this
and
report
back,
implement
it.
Try
it
out
and
report
back
on
the
experience
from
it.
C
I
do
like
this
and
better
though,
but
you
know
you
do
like
what
better
I
there
will
be
some
bike
shedding
like
I
that's
part
of
the
experimentation,
I
guess
is
going
to
be
some
amount
of
just
bike
shooting
I
do
feel
like
yeah
real
super
annoying.
This
is
like
an
ergonomics
initiative,
sort
of
problem
where
you
you
kind
of
get
used
to
it,
but
it's
never.
It's
always
annoying
right,
no
matter
what
I.
B
I
feel
like
there's
there's
a
lot
of
different
levels
at
which
this
problem
could
be
attacked
of
like
how
much
can
you
actually
handle
in
here,
because
I'm
looking
also
at
we've,
seen
some
issues
and
stuff
lately
about?
Oh,
we
need
to
support
ignoring
fields
and
clones
or
a
variety
of
those
other
things
that
sarah
day
also
has
attributes
for
yeah.
So
there's
this
like?
How
deep
does
this
dsl
go,
because
it
could.
B
A
D
I
don't
know
I.
I
don't
actually
know
that.
I
agree
that
that's
the
90
case,
but
I
I
maybe
that's
worth
it
like.
Maybe
that's
worth
gathering
data
about
and
seeing
like
what
different
you
know
if
we
made
something
like
this
available
for
experimentation
like
and
going
around
and
seeing
what
places
can
use
this
and
what?
What
places?
Isn't
it
enough
for
right?
D
There's
also
once
you
want
to
get
into
the
sort
of
full
generality
of
this
kind
of
feature,
there's,
I
think
an
obvious
overlap
with
delegation
yeah
that
is
sort
of
like
unfortunate,
because
we
have
like
sort
of
a
long-standing
history
of
entertaining
proposals
for
delegation
that
don't
go
anywhere
because
there's
just
too
many
things.
People
wanted
to
do.
C
D
C
Yeah,
I
guess
the
problem
is,
I
don't
know
who
that
liaison
is,
but
but
we
can
try
to.
D
C
C
A
C
It's
tagged
currently
as
both
but
yeah.
We
we
need
some
some
group
I
feel
like
that
group
belongs
more
in
compiler
than
than
lang,
but
I'll
bet
it
was
like
excited
to
deal
with
these
kind
of
questions.
I
guess
I
don't
really
care
if
it's
inland
or
compiler,
but.
C
C
C
All
right
next,
one
super
trade
item
shadowing.
C
C
B
B
E
C
Would
actually
just
now
that
I
think
about
implementation
wise?
I
think
this
would
kind
of
just
work
like,
in
other
words,
I
think
we
kind
of
just
have
to
suppress
the
method
resolution
from
considering
the
super
trade
methods
and
it
would
all
kind
of
fall
out
so
yeah.
I
think
that
would
be
okay
with
this.
E
It
has
surprisingly
divided
like
it's
like
seven
of
seven
downs.
Maybe
there's
a
component
human
against
it
on
the
thread.
C
C
C
C
D
Mean
there's
odd
boats.
I
don't
know
how
much
we
care
to
consider
this,
but
there
is
a
way
in
which
allowing
this,
like
is
a
breaking
change
to
stuff.
That
expected
that
not
to
happen.
For
example,
I
could
imagine
like
someone
having
offered
like
a
macro
that
called
a
method
on
a
on
a
concrete
type
right
that
that
users
created
that
was
required
to
I
don't
know,
derive
some
trait
and
then
expect
that
that
method
resolves
to
the
the
method
added
by
the
trait
and
the
preference
here
being
given
to
a
subtract.
E
And
I
think
like
right
now:
it's
taking
cases
where
you
know
that,
like
the
type
influences
the
substrate
and
so
currently
because
it
implements
both
traits
which
have
met
with
the
same
name,
it
just
errors.
So
it's
taking
some
currently
errors
in
all
cases
and
make
it
work.
I
don't
know
that
the
macro-
I
guess
not
only
it's
a
breaking
change
for
the
macro,
go
from
erroring,
because
there
are
conflicting
methods,
but
possibly
erroring,
because.
D
D
C
B
I
put
a
urlo
link
into
the
generic
parameters
on
drive
conversation
that
might
be
of
interest
to
anyone
who's
asking
about
what
I
meant
about
the
default
thing,
but
we
probably
shouldn't
talk
about
it.
C
Maybe
this
that's
the
right
follow-up
here,
but
the
idea
was
that
there's
work
on
llvm.
C
That
would
allow
you
to
have
kind
of
secret
values.
C
A
So
I
will
note
that
josh
postponed
or
said
that
rfc
bought
postponed
14
days
ago
on
this
rfc.
C
And
saying
like
if
this
is
still,
let's
come
back
and
talk
about
it,
it's
a
good
way
forward.
C
Okay,
other
people
agree.
Then
you
should
check
your
box.
C
I'm
not
sure
if
that's
exactly
what
this
is
like
what
this
is
proposing.
E
So
I
think
it's
interesting
that,
like
it
specifically
proposes
like
like
at
first
glance,
it
sounds
like
it's
just
like
solving
placement
without
doing
anything,
but
it
still
requires
that,
like
allocating
like
push
to
be
a
push
with
or
something
that
will
call
the
closure
after
it's
been
allocated.
C
C
B
C
I
agree
I'm
trying
to
think
if
there's
any.
No,
I
don't
think
so.
I
mean
yeah,
never
mind.
I
was
trying
to
think
if
there
was
any
like
laying
team
side
of
the
thing
where,
in
order
to
do
the
optimization,
you
have
to
assume
sort
of
certain
things
about
like
that.
Certain
kinds
of
reads
are
not
visible.
I
think
that's
all
pretty
squarely
in
the
compiler
area.
C
I
know
it's
something.
We've
definitely
talked
about
around
mirror
of
what
kind
of
where
do
we
have
to
introduce
temporaries
so
that
we
can
allow
enough
freedom
that
we
can
be
overwriting
this
value
and
make
sure
that
anyway,
all
right?
So
I
think
we
can
stand
by
our
prior
statement
of
recommendation
implement
in
compiler.
First
then
consider
the
optimization
and
adding
library
methods,
which
would
be
more
of
a
concern.
C
F
I'm
sorry
I'm
joining
late
here,
but
this
is
a
topic
that
I
think
I
have
a
lot
of
at
least
background
in
from
previous
stuff,
with
placement,
placement
and
and
whatnot.
Does
that
rfc
actually
talk
about
the
previous
work
with
the
aero
operator
and
whether
like
we
need
to
reconsider
re-adding
it
or
you
know,
talk
about
that
or
did
it
to
side
steps
and
says
we
don't
need
to
have
linguistic
syntax?
It's
confused
methods.
C
It's
sidestepping
yes,
it's
the
latter.
I
understand
it.
It's
saying:
if
we
guarantee
return
optimization,
then
you
could
add
methods
like
new
with
which
would
take
this
big
data
structure
right.
C
By
the
way,
this
this
is
all
by
the
same
people,
so
I
guess
we
don't
have
to
say
hey
by
the
way
check
out
this
linkedin
proposal
that
you
wrote.
I
don't
I
don't
fully
follow
what
you're
saying
felix
actually.
F
My
claim
is
that
we
remove
my
the
biggest
reason
that
I
recall
that
we
removed
the
aero
operator
previously
was
because
we
weren't
guaranteeing
that
it
actually
worked
in
terms
of
guaranteeing
that
that
it
didn't
allocate
a
temporary
and
so
it
wasn't
paying
for
it.
It
wasn't
paying
its
way
and
the
reason
for
that
was
because
it
was
implemented
as
a
macro.
F
You
know
sugar,
but
to
implement
what
they're
talking
about
here.
You
have
to
guarantee
the
optimization
that
you
know
throughout
the
compilation
pipeline,
which
to
me
means,
if
you're
going
to
do
the
work
to
actually
ensure
that
you
would
presumably
be
able
to
also
make
the
arrow
operator
work
right,
yeah,
maybe
the
answer
there
is
just
do
this
thing.
If
it
works,
then
great,
maybe
we'll
add
arrow
later
right.
C
That
seems
like
it
seems
like
you
could
modify
this
statement
slowly,
maybe
we
would
add
library,
methods
or
maybe
we
would
consider
an
operator.
You
know.
Maybe
I
mean
honestly,
we
could
have
met
like
all
our
operators
are
sugar
for
a
trade
method
right
that
becomes
possible
now,
if,
if
you
have
the
guarantee
optimization.
F
C
Sorry
I
have
to
take
this
call
real
fast
sorry,
interrupt.
E
B
E
F
It's
true,
and
they
are,
they
are
separable.
It's
just
one
of
those
things
where
my
memory
we
spent,
we
spent
like
ages
like
arguing
over
the
syntax
stuff
and
then
ended
up
abandoning
the
resolution
we
came
to
because
of
the
implementation
issues,
and
so,
even
though
they
are
independent
at
the
same
time,
it
seems
like
they
ended
up
intertwined
in
some
funny
way.
I
think.
D
I
write
an
understanding
that
you're
saying
that
if
we
were
to
to
get
to
the
place
where
we
had
these
optimizations
available,
that
as
an
alternative
to
guaranteeing
specific
behavior
of
existing
functions
or
new
functions
that
we
would
maybe
that
would
be
a
signal
that
it's
time
to
reconsider,
adding
the
error
syntax
in
yeah.
F
D
D
F
B
The
the
thing
I
think,
that's
kind
of
cool
about
the
closure
apis
is
in
a
way.
A
closure
is
a
c
plus
initializer
list.
C
I
no,
but
I
do
feel
like
didn't.
We
we
kind
of
did
reach
a
conclusion
here
right.
I
I
agree
with
you,
scott
yeah.
I
think
if
I
understand
what
you're
saying,
but
I
do
seriously
want
to
move
forward,
do
some
someone
want
to
leave
a
comment
I
mean
I
think.
As
I
said,
this
is
the
same.
You
kind
of
already
said
this
once
doesn't
happen
too
long.
C
F
Yeah,
I
think
that's
a
fair
way
to
approach
this.
I
I
can
leave
a
comment
if
I
go
back
and
re.
Listen
to
the
conversation
that
you
all
just
had
in
my
absence.
B
C
I
agree
with
that:
yeah
yeah,
okay,
access
to
traits
associated
functions
and
constants
from
trade
objects.
E
E
Yeah
yeah,
so
this
does
basically
proposes
making
associated
constants
and
functions
into
methods
and
fields
onto
the
trade
object
so
that
they
can
access
the
v
table
like
those
in
the
v
table
and
then
use
that
to
actually
call
the
function.
B
D
E
Yeah,
but
here
do
they
address
like
because
the
thing
is
like
I
mean
just
it's
a
non-trivial
change
around,
like
you
have
a
generic
function,
parameterized
by
d,
trait,
plus
question
mark
sized,
and
then
this
t
colon
colon,
a
function
like
that
doesn't
actually
work
any
like
right
now.
The
way
that
it
works
right
is
yeah.
C
Yeah,
maybe
I
think
the
short
version
is-
or
I
think
the
real
I
don't
know
if
I
I
don't
know
what
I
think
about
having
a
way
to
carry
a
v
table
like
maybe
maybe
not,
but
I
think
I
agree
strongly
with
the
workaround
is
okay,
it's
not
enough.
It's
not
worth
the
effort
to
evaluate
and
fix
this
at
this
moment.
E
Yeah,
the
argument
in
favor
is,
like
external
crate,
has
not
a
non-object,
safe
crate,
and
now
you
can
use
you
can
like
decide
separately
right
without
coordinating
with
the
definer.
But
I
also
think
that
it's
not
something
we
should
do
right
now
and
I'm
not
really
sure
if
we
should
do
whatever,
but
like.
B
Yeah,
I'm
just
I
agree
that
I
don't
know
that
we
should
necessarily
have
a
way
to
people
for
people
to
pass
around
v
tables,
but
that
was
my
attempt
at
what
is
the
kind
of
thing
that
we'd
want
to
act
when
to
make
this
more
important
to
have
than
just
than
the
like.
Well
just
add
a
refself
method.
C
B
I
I
think
my
feeling
there
is
more
like
as
long
as
the
way
that
you
have
to
use
these
things
requires
going
through
an
instance.
Anyway,
the
method
is
fine,.
D
Oh,
I
I
disagree
with
that.
I
I
mean
I'm
happy
to
send
you
code,
examples
and
stuff
if
you
want,
but
I
have
had
cases
where
it
was
an
extremely
annoying
situation
where
I
was
like
wind
up.
Writing
a
whole
bunch
of
extra
code,
because
I
needed,
in
some
cases
a
trait
to
be
used
without
an
instance
and
in
a
way
that
had
a
size
bound
and
in
other
cases,
in
a
way
that
had
an
instance
and
did
not
have
a
size
bound.
E
C
C
C
C
C
B
C
C
Okay,
but
it
basically
works
for
the
I'll,
have
to
go
review.
But
I
feel,
like
the
simple
cases,
are
the
most
important.
C
I'm
going
to
skip
over
this
one,
actually,
I'm
just
I
want
to
close
this
because
I
want
I
have
it.
I
want
to
rework
it
and
like
the
libs
team
charter,
which
was
super
awesome
and
maybe
copy
and
steal
some
of
what
they
did
so
put
eco
to
close.
E
E
E
C
C
In
favor
of,
but
they
serve
a
very
different
purpose,
and
I
was
wondering
whether
unsafe
locals
made
any
sense
that
I
know
that
there
have
been.
C
Like
occasional
questions
around
well,
if
you
move
out
of
a
variable,
is
that
a
compiler
free
to
reuse,
that's
deck
space,
or
does
it
still
hang
around?
And
I
don't?
I
don't
want
to
burden
too
much
on
one
or
fc,
but
I
could
imagine
extensions
in
that
direction
that
allow
you
to
declare
things
as
unsafe.
It's
a
signal,
I'm
doing
weird
stuff
with
them.
B
I
don't
know
if
anyone
saw
one
of
those
threads
and
I
think
it
was
unsafe
code
guidelines
on
zulip
about
some
of
the
papers
of
looking
at
unsafe
code
and
rust,
because
at
least
one
of
the
survey
papers
had
a
thing
for
here's.
The
number
of
functions
that
are
marked
unsafe,
but
do
not
contain
unsafe
code,
and
that
means
that
they
didn't
need
to
be
unsafe,
which
is
incorrect.
Currently.
D
Niko,
I
I
know
you
you
touched
upon
this
in
the
way
back
in
tootsie
pop
days,
but
it
seemed
like
there
was
a
suggestion
that
you
were
making
there
that
our
optimizations
could
potentially
change
based
on
whether
a
particular
local
was
marked
as
unsafe
or
not
and
unsafe.
Not
having
like
runtime
behavior
is
something
that
I
I
think
I
care
about.
E
E
E
I
think
on
the
thread,
there
was
basically
some
question
of
whether
maybe
we
should
just
also
just
do
both
like.
We
can
have
this,
but
then
we
still
have
racy
on
safe
cell,
because
we
don't
actually
like
reduce
the
requirement
for
sync
on
unc
statics.
But
to
me
that
seems
sort
of
like
the
worst
of
the
two.
C
Worlds,
that's
right.
I
guess
there
was
some
objection
to
unsafe
droppings
requirement
because
it's
kind
of
non-orthogonal.
C
C
C
C
D
D
I
should
say
that
again,
this
unsafe
is
like
adding
extra
behavior
and
the
idea
that
it
wouldn't
add
extra
behavior
elsewhere
is
surprising.
E
I
guess
yeah,
I
mean
it's
sort
of
like
the
same
way
that
unsafe
blocks
I'll
add
the
ability
to
dereference
raw
pointers
right
like.
D
D
Right
but
it's
surprising
to
me
that
unsafe
on
a
static
would
have
any
behavior
other
than
making
it
unsafe
to
access.
If
I
already
know
about
the
unsafe
behavior
of
unsafe
on
a
field,
and
so
then,
if
I
went
to
go,
make
it
safe,
for
example,
and
then
other
like
my
code
stopped
compiling
because
a
sync
bound
was
introduced.
That
would
be
surprising
right.
E
E
A
One
thing
I
will
mention
is
that
doing
some
sort
of
libs
review
recently
there
was
sort
of
this
notion
of
platforms
which
don't
have
threads
in
the
first
place,
where
sort
of
sync
on
statics
and
more
generally,
like
mutexes
and
stuff,
doesn't
even
like
you
don't
need
it,
you
don't
want
it
and
you
get
these
like
weird
situations
where
you're
you
know
implementing
it
for
a
mutex
type,
because
otherwise
you
can't
put
that
mutex
type
in
a
static,
even
though
you
know
the
music
just
has
a
cell
inside
it
and
it
feels
like
there
could
be
a
world
where,
on
some
platforms
like
wasm,
potentially
you
would
want
to
sort
of
say
more
generally
that
statics
never
require
the
sync
bound,
whether
whether
they're,
safe
or
unsafe,.
A
I
know
I've
I've
definitely
written
code
where
I've
sort
of
wanted
cell
to
be
like
the
the
default
in
some
sense.
F
E
D
Oh,
I
was
just
saying
nico
and
I
talked
about
this
ages
ago
with
respect
to
some
async
stuff,
where
you
wanted
to
be.
You
wanted,
like
generic
modules
that
are,
you,
know,
sort
of
generic
over
whether
or
not
you
care
about
thread
safety,
and
I
find
that
I'm
often
like
writing
libraries
along
along
these
lines,
where
it's
like
you
know.
If
my
end
user
wants
cares
about
threat
safety,
I
want
to
be
using
mutexes,
but
otherwise
I
I
don't.
D
I
would
prefer
to
be
using
cells,
for
example,
and
I
feel
like
there's
sort
of
a
large.
A
I
mean
the
whole
compiler
right
now
is
generic
over
whether
we're
parallel
or
not,
by
swapping
out
like
a
single
module,
yeah
sort
of
scary,
but
it
works
out
well
in
practice.
B
I
could
definitely
imagine
a
like
binary
level,
I'm
just
going
to
be
single
threaded,
but
sorry
I've
got
to
drop
because.
C
Progress
we're
getting
here,
we're
getting
close
now
we're
going
to
the
more
recent
stuff.
It's
a
little
juicier
all
right.