►
From YouTube: 2021-03-09 Lang team triage meeting
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).
C
Okay,
I
have
my
microphone
set
to
the
wrong
microphone,
but
I
kept
saying
things
and
people
would
make
comments
that
were
like
plausibly
in
response
to
me,
but
not
obviously
so,
and
it
was
very
confusing.
Okay
that
all
makes
more
sense.
C
C
Bonanza
recap
where
the
plan
is
to
go
through
the
dropbox
paper
and
figure
out
what
we
actually
did
and
didn't
do
and
do
those
things
and
then
what
we're
gonna
do
next,
if
we
have
time
then
shepherd's
4.0
triage
update,
I
still
have
to
prepare
the
doc
for
that
and
the
atomic
bomb,
and
we
made
the
rule
that
we
should
try
to
have
these
ducks
at
minimum
the
day
before
in
today's
meeting,
although
I
think,
if
you
want
to
do
earlier,
no
one
will
complain.
C
Okay,
action
item
review.
I
went
over
this
already.
Actually
I
did
this
is
any
of
these
things.
Should
they
be
checked
off
that
weren't
taylor,
felix.
C
Okay,
I'll,
let
you
check
it
off
when
you're
done
great,
so
the
draft
patterns
thing
has
been
accepted
and
I
created
a
tracking
thing,
but
I
realized
we,
don't
I
don't
remember
if
we
had
a
liaison
planned.
I
would
like
to
have
somebody
who's
responsible
for
that,
and
I
would
like
it
to
not
be
me
just
to
be
the
person
who
forwards
messages
and
so
forth
and
tracks.
What's
going
on
josh.
Are
you
someone
who
wanted
to
do
that?
C
Okay,
all
right:
let's
follow
up
I'll
open
a
topic
on
zulip
see
because
scott's
not
here,
I
don't
know
exactly
how
much
payment
they'll
require
really
we'll
we'll
come
back
to
it.
C
So,
actually,
can
you
whoever's
action?
I
am
mark,
I
guess
oh
and
josh's
notes.
Can
someone
write
down
in
the
right
places
and
not
me
that
action
item
niko
to
follow
up
on
zulip
about
liaison
yep,
okay,
so
there's
another
proposal
that
was
opened
allowing
the
compiler
to
eagerly
drop
values.
C
C
You
may
recall
that
there
were
we
talked
about
this
when
we
modified
async
await
the
temporary
rules
for
async
awaits
so
that
they
matched
non-async
away
code,
and
we
talked
about
how
if
we
wanted
to
have
drops
that
were
if
we
wanted
to
make
things
not
outlive
a
weights,
we
probably
wanted
to
solve
that
problem
more
generally
by
having
a
notion
of
eager
drop,
and
so
I
thought
in
talking
with
djc,
he
had
a
bunch
of
examples
of
problems
that
interesting
code
patterns,
and
I
thought
it
might
be
worth
kicking
off
some
conversation
about
whether
we
want
to
explore
this
in
any
form.
C
A
D
C
C
Yeah,
it
sounds
very
right
to
me.
One
thing
I
was
gonna
comment
in
zulip
is
that
we
may
want
to
like.
There
may
be
intermediate
steps
we
can
take
like,
for
example,
more,
like
must
drop
lints
or
must
use
lints
sort
of
encourage
people
to
write
explicit
drops
in
some
cases
and
things
like
that
or
at
least
factor
factor
out
confusing,
especially
for
temporaries.
D
Someone
made
the
point
that
if
we
did
eager
drop
and
in
particular
defined
it
semantically
such
that
we
drop
as
soon
as
we
can,
because
all
of
the
references
to
something
have
been
dropped,
then,
to
some
degree
we
would
make
the
semantics
of
borrow
checking
part
of
the
correctness
of
the
compiler
in
a
way
that
we
have
not
previously
done,
because
you
would
need
the
borrow
checker
to
know
when,
as
soon
as
it's
no
longer
referenced
is
true.
This
is
not
true
for
end
of
scope
drops
which
can
do
a
much
simpler
rule.
C
Yeah
there,
what
I
will
say
about
that
is
that
there
are
options
like
we
don't
have
to
take
into
account
references.
We
could
have
a
rule
that
says
for
temporary
values.
We,
you
know,
do
some
of
the
control
flow
graph
and
decide
where
to
insert
the
drop,
and
if
you
have
a
reference
that
outlives
it,
then
you
get
an
error.
Just
like
you
do
today
like
it
doesn't
have
to
be
today's
rule,
but
it
could
be
a
more
intelligent
rule
without
it
bringing
the
borrow
checker
to
bear.
But
anyway,
let's
I'm
gonna.
C
I
just
wrote
some
comments
on
zulub
to
encourage
people
to
summarize
that
discussion
there,
because
there's
no
way,
I'm
gonna
follow
all
that
and
I
think
we'll
come
back
to
this
another
time.
But
did
you.
E
D
So
there
was
discussion
about
doing
it
at
the
global
level
of
what
would
this
take
and
what
would
the
impact
be?
That's
still
heavily
debatable
separately
from
that
there
are
proposals
for
how
to
scope
it
more
narrowly,
one
of
which
is
to
have
it
be
a
type
by
type.
Opt-In
of
this
type
is
eagerly
dropped.
C
C
Yeah,
that's
kind
of
where
this
started
is
that
I
think
the
current
behaviors
well.
There
are
definitely
error
prone
cases
and
there
are
definitely
cases
where
it
creates
confusing
errors
like
both
directions.
It
and
so
we're
talking
about
changing
it.
And
then,
when
I
started
talking
about
that
with
djc
a
lot
of
the
examples
he
came
up
with
weren't,
actually
temporaries,
and
so
it
seemed
like.
Okay,
maybe.
E
E
E
C
E
I
asked
questions
and
people
responded.
I
haven't
yet
had
a
chance
to
read
again.
It
looks
like
there
are
some
comments,
some
new
comments
as
of
minutes
ago,
so
it.
B
D
D
E
C
E
So
or
sorry,
a
suggestion
in
response
to
sort
of
my
concern
about
about
the
potential
impacts
on
our
ability
to
provide,
like
a
you
know,
more
performant,
rust
compiler
that
didn't
have
these
uv
checks
in
the
future
was
that
we
could
add
a
flag
to
the
rust
compiler.
That
said,
hey
don't
do
these
uv
checks
basically,
and-
and
there
was
some
back
and
forth
on
like
I,
I
was
under
the
impression
that
such
a
compiler
would
then
sort
of
no
longer
be
a
spec
compliant
thrust.
E
D
E
I'm
just
totally
not
sold
at
all
on
the
idea
of
having
this
be
like
a
spec
level
guarantee.
It
seems
like
something
that
we
just
want
to
have
as
a
feature
in
the
rest
compiler
and
don't
really
want
users
to
rely
on
at
all.
So
I
I
don't
understand
quite
why
we're
introducing
a
guarantee
about
it,
but.
B
Right
yeah,
it's
it's
my
reading
of
it
is
it's
only
intended
to
be
deployed
like
in
terms
of
we
would
actually
catch
everything
that,
where
the
behavior
isn't
something
that
has
some
obvious
semantic
attached
to
it,
that's
the
only
place
where
ralph
was
intending
to
add
a
guaranteed
check.
I,
as
my
as
I
read
it,
and
at
that
point
I
don't
know
what
the
flag
would
mean
to
try
to
opt
out
of
that.
E
A
Yeah,
I
I
think
my
interpretation
of
what
ralph
and
ollie
have
said
is
that
sort
of
for
some
of
these
checks
there's
not
like
other
than
sort
of
jitting
or
whatever
the
mirror
and
then
sort
of
running
it
at
compile
time.
There's
not
much.
You
can
do
without
sort
of
being
able
to
detect
them
in
sort
of
an
interpreter
fashion
and
so
sort
of
it's
it's
relatively
hard
to
add
the
flag
as
a
like
you're,
the
optimizations
require
a
significantly
different
type
of
compiler.
I
don't.
E
E
A
A
At
least
my
reading
of
them
are
still
unaddressed
in
some
sense,
but
I
have
not
closely
followed
the
discussion
so.
D
So
I
think
it
sounds
like
there
are
two
concerns
here.
I
think
one
has
been
addressed
and
one
has
not
yet
and
needs
to
be
further
discussed.
The
concern
of
are
we
allowed
to
make
these
things
optional
in
the
compiler
has
been
clarified
in
the
rfc
that,
yes,
we
are
and
that
doesn't
break
any
kind
of
spec.
The
rfc
is
trying
to
provide
there's
separately.
D
The
question
that
seems
perfectly
reasonable
of
is
this
something
we're
trying
to
define
as
part
of
the
language
at
all,
even
if
it's
something
you're
allowed
to
opt
out
of,
and
that's
a
reasonable
question
we
that
the
rfc
has
a
position
on
it.
It
sounds
like
taylor
you're,
saying
that
you
prefer
a
different
option
and
that's
still
an
open
question
then,
can.
C
D
Compilation,
time
yeah.
That
would
be
the
biggest
reason
that
all
of
these
things
may
require
stepping,
through
with
miri,
for
example,
and
at
some
point
people
may
do
const,
evaluation
or
similar
that
is
sufficiently
large
and
complicated
that
it
needs
to
be
compiled
or
jitted
or
otherwise
done
something
for
performance.
In
a
way
that
makes
it
not
trivial
or
not
even
possible
for
us
to
detect
certain
types
of
ub.
E
I
also
think
that
there's
an
argument
from
compiler
uniformity
like
I
haven't,
but
we
haven't
very
well
specced
out
a
lot
of
like
what
some
of
the
mirror
optimizations
we're
going
to
want
are,
but
I
can
imagine
you
know
certainly
that
there
are
mere
optimizations
that
we'll
want
to
do
that.
Have
not
just
you
know,
they're,
not
just
optimizations
in
the
sense
of
that
they're.
E
You
know
guaranteed
behaviors
in
terms
of
like
nrvo
and
things
like
that,
and
if
we
have
to
sort
of
like
lift
out,
you
know
which
ones
of
those
on
aren't
allowed
in
const
eval,
because
they're
potentially
going
to
cause
us
not
to
detect
certain
classes
of
ub
that
we've
promised
to
detect.
I
I
feel
like
that
would
and
then
we
wind
up
having
to
like
special
case
what
mirror
passes
run
in
you
know
when
doing
constitute
val
and
which
ones
don't
like
that.
That
would
be
an
unfortunate
world.
I
think.
C
Okay,
I
don't
have
a
problem
like
it.
Keeping
our
options
open
seems:
okay,
I'm
just
thinking
about
how
from
what
I
can
tell
them.
You
know
the
major
value
proposition
of
rest
is
that
we
bring
safety
and
predictability
to
systems
programming
and
I'm
worried
about
saying,
but
not
when
you're
doing
it
at
compilation.
Time.
C
D
Well,
I
think
that's
actually
where
we
should
be
with
the
rfc
and
I'm
wondering
if
there's
phrasing
that
could
get
us
there
in
that,
it's
not
that
the
rfc
should
be
saying.
We
must
always
detect
this
unless
the
user
specifically
wants
to
opt
out
of
it.
I
think
it's
reasonable
for
the
rfc
to
say
it
is
desirable
for
us
to
detect
these
things
whenever
possible,
and
then
there
are
multiple
reasons
why
we
might
not
be
able
to,
but
it's
reasonable
for
from
a
language
perspective
to
say
these
things
are
undefined
in
practice.
D
E
C
E
C
E
My
my
overall
feeling
is
very
much
what
josh
said
of
like.
I
totally
understand
why,
like
out
of
the
user,
this
would
be
a
nice
thing
to
have
and
like
it
would
be
cool
that
my
compiler
does
this.
But
I
don't
want
to
go
on
like
reddit
and
see
somebody
responding.
Oh
well,
you
know
that
this
code,
can't
d,
isn't
doing
ub
because
it
const
evals
properly
or
something
right,
and
this
rfc
says
that
we
won't
const
eval,
like
without
an
error.
C
No
parody
of
sort
of
run
time
like
const,
val
and
run
time,
do
the
same
thing.
We
do
the
same
optimizations
they
generally
behave
the
same,
and
one
thing
I
would
add
is
that
I
want
us
to
have
a
cargo
test
dash
dash,
unsafe
or
something
which
interprets
your
code
at
runtime
and
detects
ub.
You
know,
maybe
not
all
ub
but
most
or
whatever,
and
you
could
imagine
that
if
we
did
have
that
that
it
may
also
affect
compilation
time
kind
of
I
don't
know.
D
We
actually
do
have
a
cargo
miri
or
similar
that
will
run
your
runtime
code
through
miri
and
scan
for
undefined
behavior
it'd
be
fun
to
have
a
faster
version
of
that.
No,
I
wanted
to
use.
C
Like
real
your
actual
code,
but
yeah
cargo
mirrors
the
the
right
idea,
just
I
want
a
more
generalized
version.
B
What
I'm
asking
so
you
said
you
said:
I'm
interpreting
your
statement
of
a
parody
as
meaning
as
being
against
this
rfc.
In
some
sense
and
saying,
like
you
know,
we
have
the
same
behavior
at
run
time
as
a
compile
time,
and
this
is
adding
some
behavior
compile
time
that
isn't
exhibit
run
time.
But
my
counter
argument
to
that
is
that
the
very
nature
of
undefined
behavior
in
many
cases
is
meant
to
be
interpreted.
As
you
know,
demons
coming
out
of
your
nose
and
at
that
point
I
think,
compiled
time.
B
D
Sort
of
that
you
heard
the
argument
isn't:
can
we
catch
things
that
compile
time
that
we
would
otherwise
have
to
live
with
at
run
time?
The
parody
argument
is
this
is
behavior
happening
in
constabal
that
we
are
currently
detecting
at
constaval
time
that
we
wouldn't
detect
if
the
same
code
was
run
at
runtime,
because
we
compile
it
instead
of
running
it
through
miri.
C
You
could
imagine
that,
meaning
that
some
code
will
run
well
at
runtime,
but
not
a
compilation
time
if
we
weren't
doing
the
same
optimizations
right
things
like
nrvo
or
whatever.
That
may
be
very
important
to
your
overall
performance.
B
Okay,
now
now,
I
think
I'm
least
getting
close
to
what
you're
saying
in
terms
of
so
it
sounds
like
you're
saying
you
want
to
use
this
as
an
argument
for
saying
look,
we
shouldn't
have
to
do
these
checks
on
the
unoptimized
mirror.
We
should
be
able
to
still
apply,
mirror,
optimizations
and
still
run
this
checking
form
thing
and
yeah
it
may
not
catch.
It
may
not
catch
some
things
that
are
optimized
away,
but
that's
that's.
That's.
C
E
E
You
know
performance
or
you
know,
guaranteed
optimizations
in
exchange
for
that,
but
I
don't
think
that,
like
giving
a
guarantee
that
we
will
catch,
these
things
now
seems
like
it's
adding
very
low
to
like
no
value
to
me
in
exchange
for
limiting
our
options
in
the
future,
except.
B
That
it
means
well,
I
can
see
the
value
I
can
see
the
value.
It
adds
that
in
the
future,
like
a
change,
optimization
suddenly
means
that
somebody
who
previously
wasn't
hitting
a
check
starts
hitting
it
and
they'll
file,
a
bug
saying
you
regressed
my
code
right
and
we'll
say
well
that
was
a
uv.
That
was
your
fault,
but
still
I
I
can
see
value
in
being
more
upfront
about.
C
The
other
argument
against
this
rfc
and
we
should
probably
move
on
after,
like
in
a
few
minutes,
but
is
when
the
other
argument
is
that
what
this
is
that
it's
misleading
it's
unclear
what
users,
basically
users,
still
can't
rely
on
us
to
catch
most
kinds
of
ub.
Let's
say
I
don't
know
if
that's
true,
but
there
are
certainly
a
long
list
of
things
that
are
not
caught
in
a
short
list
that
are
right.
Well,.
B
B
C
I
thought
it
was
saying
there
are
some
cases
like
that
there
are
some
cases
that
there's
no
obvious
way
to
make
the
make
miri
continue
right
and
it's
what
it
says
all
of
this
ub
is
that
there
has
in
common
that
there
is
no
obvious
way
to
continue
evaluation,
even
though
the
program
has
caused
ub
versus
the
other
class.
There
is
an
obvious
way.
B
C
Says
obvious,
but
yeah
I
mean
I
guess
in
the
end
of
the
day,
it
seems
like
if
we
said
that
it's
when
you
have
you
be
the
com,
the
compiler
may
opt
to
produce
an
error
but
is
not
required
to
then,
if
there's
no
obvious
way
for
miri
to
continue
it
doesn't
have
to
it.
E
Right
and
ralph
has
all
this
interesting
language
in
the
rfc
and
like
in
the
discussion
thread
about
like
users
can
rely
on
it,
but
not
authors
right
so,
like
you
can't
you
can
rely
on
it
as
someone
using
like
using
the
rust
compiler,
but
not
as
someone
writing
code,
which
I
think
is
a
distinction
that
is
really
subtle.
B
I
still
don't
fully
understand
it.
I
I
at
this
point
my
interpretation
of
that
phrasing,
although
I
still
I'm
quite
unhappy
with
perhaps
response
to
mark's
question
about
this,
because
he
seemed
pretty
dismissive
of
the
question.
But
my
interpretation
of
it,
as
best
I
can
handle,
is
that
consumers
of
unsaid
code
are
like
the
expression
context
that
unsafe
blocks
appear
within.
Maybe
that's
wrong,
but
that's
what
that's
my
best
guess
is
what
the
what
that's
meant
to
convey
there
versus
authors
once
a
code
or
the
things
inside
of
unsafe
blocks.
So.
E
The
question
that
I
specifically
asked
is
whether
or
not
someone
could
write
a
library
that
performed
a
specific
kind
of
ub
in
response
to
you
know
as
a
way
to
guard
against,
like
undefined
behavior
at
runtime,
for
example,
so
giving
you
a
compiler
error.
You
know
when
you
trigger
this
and
and
ralph
said
that
that
wouldn't
be
a
valid
use
of
this.
D
C
So
I
think
I
yeah
okay,
I
I
can
leave
a
comment,
but
my
current
position
is
that
taylor
has
persuaded
me
that
what
we
should
do
is
say
officially
ub
has.
Is
you
be
whether
it
be
at
compilation
time
or
at
run?
Time
and
like
we
try
to
report
compilation
errors,
but
it
is
not
guaranteed
and
the
sex
set
may
change
over
time
and
the
rest
of
it
is
like
implementation
advice.
A
Yeah,
I
I
do
think
I
I
know.
Well,
I
don't
know
if
this
is
correct,
like
per
the
c
plus
plus
spec,
but
I
know
that
in
the
past
I
have
had
the
impression
that
sort
of
people
in
the
c
plus
plus
world
sometimes
say
you
know
I'm
gonna
annotate,
all
of
my
functions
or
whatever,
with
const
or
whatever,
I
think
context
per.
A
And
then
you
know
if,
if
my
code
runs
through
the
compiler,
and
you
know
all
my
test
cases,
then
presumably
I
haven't
had
any
ub
anywhere
in
there,
and
that
seems
like
a
pretty
bad
position
for
us
to
be
in
because
what
we
really
want
to
say
is
like
you
need
to
run
through
miri
or
like
idea,
which
seems
a
lot
more
reasonable.
As
a
sort
of
claim
like
I.
A
A
I
think
the
main
thing
that
scares
me
is
that,
like
I
would
not
expect
if
I
have
a
cons,
offend
function
that
like
removing
const
from
it,
would
all
of
a
sudden
introduce
ub
into
my
program
if
it's
still
compiled,
and
it
feels
like
in
some
sense
with
with
the
guarantee
we're
offering
here
like.
We
will
just
you.
D
Right,
I
would
think
in
particular
that
removing
const
should
always
make
it
less
strict.
It's
we're
never
going
to
have
more
checks
at
run
time
than
we
do.
A
Issue,
if
you
previously
annotated
it
as
constant
and
somehow
you
know
it
was
promoted
or
something
then
by
removing
the
const.
You
now
have
run
time
code,
which
in
theory
has
to
be
safe
against
ub,
for
example,
from
an
unaligned
pointer
dereference,
whereas
it
constant
vowel
time
because
you
previously
had
cons.
You
didn't
have
to
worry
about
that
case,
and
so
your
code
was
correct.
In
some
sense,
I
see
that's
interesting.
A
F
E
Yeah
to
clarify
your
concern
here
is
is:
is
about
sort
of
the
other?
The
other
comment
in
this
not
about
that.
We
generate
errors
on
ub,
but
that
we
sort
of
kind
of
happily
allow
like
right
sort
of
interpretable
semantics.
A
Yeah,
so
so
you
know
if
we
start
allowing
if
we
we
err
on
some
cases,
but
we
don't
err
on
other
cases,
then
there
it
seems
like
there's
an
easy
case
of
you
know.
I
expected
this
to
work
because
I
saw
errors
and
maybe
I
didn't
even
read
any
sort
of
spec
or
documentation,
but
you
know
I
saw
some
errors
and
now
you
know
I
dropped
cons
because
I
needed-
or
I
didn't
even
drop
it.
I
just
called
it
in
a
runtime
context
and
now
I
have
ub
in
my
program
that.
C
A
B
This
actually
gets
me.
I
want
to
bring
up,
which
is
the
there's,
a
meta
question
here,
whether
this
should
have
been
a
compiler
team
rfc
rather
than
a
lang
team.
One
like
I,
I
don't
know
the
answer
to
that,
but
I
I
think
some
of
ralph's
frustration
is
that
they
were
sort
of
advised
to
make
an
rfc
to
get
some
of
these
ideas
down,
and
it's
not
clear
whether
they
actually
really
meant
to
try
to
be
proposing
language
level
changes,
as
opposed
to
like
just
documenting
a
design
for
something
that
would
go
into
compiler.
E
E
A
good
art
I
mean
that's,
my
initial
comments
were
all
prior
to
the
whole
flag
thing.
The
flag
thing
kind
of
makes
me
feel
differently
about
this.
I
mean,
I
think.
C
If
you,
I
think
right,
so
if
the
laying
team,
the
lane
guarantee
that
I
proposed
and
that
I
still
favor,
of
which
I
think
taylor
also
favors
the
like
we're
not
going
to
guarantee
you
anything
and
then
having
this
current
context
more
or
less
be
like
this
is
what
this
is
just
documenting.
The
current
behavior
of
rusty
feels
fine,
so
as
a
comp
as
a
compiler
team
rfc
against
a
lane
team
baseline,
which
is
like
we
left
this
to
the
implementation,
to
figure
out.
B
I
think
it's
more
than
I
mean
I
don't
think
it's
meant
to
be
just
current
augmentation
I've
been
thinking
more
of
like
this
was
meant
to
be
a
tenant
like
something
where
it's
not
a
guarantee,
but
more
something
we
strive
for
and
to
help
us
guide
future
decisions
and
to
be
positioned
accordingly,
which
is
sort
of
what
we
talked
about
already
right
to
say
that,
like
yeah,
these
are
all
nice
to
have.
So
you
get
to
make
that
up
front.
But
it's
not
a
guarantee
actually.
D
That's
a
there's,
a
concrete
parallel,
I
think,
is
worth
drawing
here.
Our
handling
of
overflow
is
not
just
a
compiler
thing.
That's
a
language
level
thing
in
the
context
of,
should
it
be
a
language
property
that,
if
we
could,
we
would
catch
overflow
in
general,
and
there
is
an
optimization
that
we
don't
in
release
mode
because
it
substantially
impacts
performance
to
do
so.
If
we
could
do
so
for
free
in
release
mode,
we
would
and
that's
a
language
level
decision.
That's
not
just
a
compiler
decision.
I
think
that's
what
this
is
as.
D
C
A
language
levelization
and
that
we
should
totally
move
on.
However,
this
keeps
continues
to
be
productive,
which
is
frustrating
to
me.
I
do
think
that
precedent.
I
had
that
in
the
back
of
my
mind
and
then
I
dismissed
it
and
I'm
glad
you
said
it
explicitly.
Josh
like
it
makes
me
wonder
if
or
maybe
I
actually
sort
of
the
precedent.
I
would
want
that,
like
in
debug
mode,
we
will
catch
all
those
things.
I
don't
know
something
to
think
about.
Oh.
E
C
I've
actually
would
I
thought
if
we
had
that
car.
I
always
say
cargo
test
dash
dash
unsafe,
not
to
scare
people,
but
if
and
that's
probably
what
we
actually
want.
But
if
we
had,
you
know
actually
had
this
valgrind
thing
I'm
talking
about
it
would
like
be
cool
if
cargo
test.
If
your
project
contains
unsafe
code,
you
know-
or
I
don't
know
what,
but
sometimes
I
imagine
there
are
projects
that
would
want
it
to
be
the
default
right.
Just.
C
Time
but
I'm
just
saying,
like
the
argument
that
we
used
when
we
did
when
we
made
this
decision
about
overflow,
was
that
checking
in
debug
was
kind
of
good
enough,
because
most
people,
because
it
is
at
least
sometimes
guaranteed
to
be
a
panic
and
somebody's
going
to
be
running
and
testing
your
library
in
debug
mode
and
subserve.
This
panic
like
it,
you
know
what
I
mean
and
I'm
not
sure.
If
that
argument,
I
think
that
is
largely
borne
out
from
me.
There.
B
C
Yes,
we
do
yeah,
that's
another
detail,
we
say,
but
I
guess
I'm
just
saying
it
would
be
nice
if
there
was
a
way
for
me
to
say
I
don't
care
like
yes,
I
understand.
Sometimes
compilation
needs
to
be
fast
and,
and
it
may
not
always
be
detected,
but
at
least
like,
while
I'm
testing
and
doing
development
I
will
get.
I
will
detect
these
kind
of
problems.
E
E
D
B
C
C
C
C
A
C
D
C
I
don't
we
don't
have
a
mechanism
for
that.
I
don't
see
a
reason
that
the
work
that
like
I
think
we
could
continue
that
work
could
continue.
It's
just
not
going
to
change
we're
not
going
to
change
the
default
for
the
new
edition
right.
It
could
continue
as
a
feature-gated
feature.
That
would
be
okay
for
me,
which
I
would
like
to
have
a
project.
D
C
A
Yeah
and
and
nico,
I
will
also
make
a
note
that
in
the
previous
discussion,
I
think
without
you
on
that
rfc-
and
I
reflected
this
in
my
summary
comment.
We
had
discussed
that
potentially-
and
I
I
at
least
was
opposed
to
experimentation
on
nightly,
even
though
we
can
continue
exploring
the
design
space
for
sure.
C
F
F
C
E
Actually,
I
have
a
quick
procedural
question
on
this
one.
Should
this
also
be
a
libsrfc,
because
what
it's
actually
introducing
are
like
they're
built-in
macros,
but
they
are
like
library
macros,
like
they're
things
that
people
use
to
write,
libraries
and
they're
part
of
the
standard
library
it
seems
like
it
would
be
good
to
loop
in
those
folks
for
their
thoughts.
D
That's
an
interesting
question,
so
these
are
effectively
intrinsics
because
they
aren't
going
to
be
implemented
as
library,
macros
they're
going
to
be
implemented
as
built-in
mechanisms
in
the
macro
interpreter
in
the
language.
E
C
F
B
E
D
C
E
E
That
was
a
surprising
name
for
that
thing.
To
me
I
think,
but
I
I
understand.
C
C
F
C
C
F
All
right,
yeah,
it
just
sort
of
opens
the
question
of
like
how
many
other
things
will
how
many
magic
functions
like
this.
Are
we
going
to
want
to
have
in
there
and
what's
the
rule
for
having
them,
but
that
we
can
fund
that
for
later?
I
think.
C
C
D
I've
been
following
this:
there
is
a
lot
of
discussion
here.
A
fair
bit
of
it
is
unpleasant.
I
will
provide
the
caveat,
but
that
aside,
there
is
currently
debate
over
whether
it
is
possible
to
change
represent
without
breaking
existing
code
or
if
it,
if
repressee,
is
sufficiently
widely
used
and
expects
current
behavior
that
we
would
have
to
introduce
a
repper
really
c
or
effectively
equivalent.
D
Nobody
suggested
a
concrete
name
for
it
in
the
rfc
in
the
thread,
but
effectively.
We
need
a
thing
that
is
match
compilers,
exactly
changing.
That
will
involve
changing
the
handling
of
zero
sized
types
and
similar,
and
there
is
some
existing
code
that
uses
zero
size
types
and
may
we're
not
clear
have
expectations
on
that.
F
D
E
Just
to
clarify
on
the
notes,
it's
the
wrapper
c
csts
that
have
been
have
a
specified
alignment
rate.
That's
that's
the
thing.
That's
under
discussion.
E
C
Yeah:
okay,
that's
right:
okay,
I've
added
a
new
section
by
the
way
things
in
the
reference
which
are
tagged
as
nominated
will
appear
here.
There
aren't
any
right
now
trying
to
build
some
more
connections
between
the
reference
and
our
triage,
never
type.
We
have
for
not
very
many
minutes.
Do
we
want.
A
D
C
Yes,
there's
a
okay:
this
is
weird
deprecation
of
nesting
items.
There's
a
pending
fcp
close!
Is
there
a
place
to
put
things
for
2024,
not
that
I
know
of.
I
think
we
have
an
edition
v
next
or
something
we
could
just
keep
it,
but.
C
That's
what
I
think
too,
if
you
want
to
do
it,
do
it,
but
okay,
so
field
has
never
read
lint
warning.
I
started
samurai
looking
at
this
link
and
I
was
like
this
is
complicated
and
it's
got
a
lot
of
examples
and
I
don't
know,
what's
the
exact
thing,
so
I
was
wondering
if
somebody
wants
to
take
an
action
item
to
write
up
what
the
heck
is
going
on
here
and
summarize
it
sorry
which
one
again,
oh
sorry,
this
one
here,
one
or
eight
one,
six
five
eight
field
is
never
read.
C
D
D
Useful
to
store
to
it
because
it
has
a
drop.
C
D
Is
about
these
things
I
think
in
both
of
those
cases
my
inclination
would
be
to
say
this
is
why
we
have
underscore
fields
and
the
ability
to
turn
off
lints,
but
if
there
are
any
cases
where
the
read
and
rust
code
is
not
caught,
that's
another
matter.
C
I
think
I
I'm
going
with
my
my
usual
rule
of
thumb
is
like
I
don't
mind
if
the
lint
flags,
something
where
I
would
really
want
to
comment,
I'm
trying
to
decide
if
this
categorizes
here
plausibly.
I
definitely
think
that
the
it's
only
stored
too,
so
it
can
get
dropped
later.
Probably
merits
a
comment.
Does
the.
C
The
other
option,
the
other
question-
is:
what
do
we
lose
by
not
like
we
kind
of
can
never
warn
about
un
stored
fields
right,
like
especially
the
ffi.
We
can't
really
know
if
you're
gonna
pass
this
to
some
ffi
code.
I
mean
it
would
basically
mean
any
wrapper
c.
We
never
worn
right,
and
that
seems
too
broad
of
a
brush.
C
A
Suggestion
being
made
is
that
if
there's
a
the
address
of
the
field
is
taken,
then
we
should
not
warn.
D
That
actually
seems
reasonable.
I
was
going
to
say
taking
a
reference.
I
would
still
like
the
lint
to
detect
if
that's
never
used,
but
if
you're
turning
it
into
a
raw
pointer
and
passing
it
off
to
something
that
actually
sounds
pretty
reasonable
to
turn
that
off.
C
We
can't
detect
that,
but
yeah
we
could
make
a
best
effort
if
they
used
the
raw
ref
macro.
We
could
detect
that
which
they
ought
to
right.
A
C
E
A
So
are
we
opposed
just
as
a
quick
check
to
reverting
the
pr
that
like
broke
this
just
so
we
have
more
time
since
it's
currently
a
beta
regression,
I'm
kind
of
just.
A
E
I
feel
like
to
clarify
that
that
last
bullet,
I
don't
feel
like
that's
something
we
can
actually
do,
because
what
you're
really
saying
is
we
would
disable
the
lint
if
we
see
a
raw
pointer
to
create
it
to
anything
that
recursively
contains
yeah,
it
seems
to
have.
F
C
I
would
like
you
to
write
a
comment,
scott,
and
it
would
be
great
if
you
summarize
this
all
these
points
that
were
made
in
particular,
taking
a
borrow
that
becomes
a
raw
pointer
requires
yeah
checking
all.