►
From YouTube: 2021-05-04 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).
D
C
Awesome
did
you
already
start?
Yes,
you
already
started
the
recording
as
the
usual
standing
reminder.
We
have
the
action
item
list.
Please
take
a
look
and
see
if
there's
any
items
that
are
on
your
list,
that
you've
either
done
but
not
checked
off
or
haven't
done
already.
C
And
then,
let's
head
right
into
the
pending
proposals,
we
have
lang
team
86,
which
is
a
lot
where.
C
A
I
just
want
to
briefly
talk
about
tomorrow's
meeting.
We
normally
have
a
plan
where
we
do
have
a
planning
meeting
on
the
calendar.
I
didn't
send
out
any
requests
for
updates.
I
don't
know
because
I
didn't
forgot
to
do
it.
I
don't
have
a
good
setup
for
that.
A
Yet
I
don't
know
if
we
have
how
many
design
meeting
proposals,
but
I
know
at
least
at
least
one
generators
that
we
deferred
do
we
want
to
have
up,
maybe
a
for
so
one
option
which
mark
floated
that
I
thought
was
kind
of
appealing.
So
we
could
have
a
foreshortened
planning
meeting
to
pick
our
design
meetings
and
maybe
do
one
meeting.
A
Yeah
I'd
like
to
have
a
script
that
just
sort
of
I
can
run.
I
I
found
someone
to
write
the
script
for
me,
but
I
need
to
tell
them
what
it
should
do
so,
hopefully
that
will
happen
soon
in
any.
C
Case
start
a
topic
in
the
appropriate
zoolop
for
each
project,
asking
for
status
updates
on
a
date
basis.
C
All
right,
so
I
don't
think
there's
any
activity
on
lang
team,
86,
eager
drop,
so
that
still
requires
a
write-up.
It's.
C
A
Somewhat
different
but
they're
all
sort
of
semi
black
on
me
of
various
kinds,
somewhat
different
in
that
they've
made
varying
amounts
of
progress.
A
But
the
question
is:
I
don't
really
know
what
the
question
is,
how
how
much
to
prioritize
closing
these
issues
and
how
to
think
about
them.
I
think
there's
a
larger
question
of
how
to
think
about
our
soundness
issues.
I
have
would
like
to
see
us
doing
a
drive
to
get
them
down
to
zero,
but
it's
been
hard
to
motivate
that
as
a
actually
doing
that
work,
I
don't
know
I'm
kind
of
opening
it
to
the
floor.
A
A
E
B
A
A
If
folks
have
a
sense
for
how
urgent
kind
of
overall
sound
those
issues
are
in
terms
of
any
particular
reason
like,
there
seems
to
be
a
number
of
kinds
of
risk,
reputation,
risk
actual
risk.
As
far
as
I
know,
we
haven't
really
ever
hit
like
any
cves
or
things
as
a
result
of
a
soundness
issue,
but
I'm
not
dying
to
have
the
first
one
I
mean
we've
had
cvs,
but
usually
they
were
more
like
incorrect
on
safe
code
or
something
like
that.
As
far
as
I
know,.
A
But
yeah,
I
guess
another
question
would
be
whether
anyone
sort
of
to
felix's
point
what's
the
best
way
to
distribute
some
of
this
effort.
Is
there
people
who
are
particularly
interested
in
learning
more
about
this
area?
A
In
this
group,
I
think
the
trades
working
group
is
a
plausible
place
to
start
drumming
up
support,
but
it
you
know
we
have
existing
stuff,
we're
working
on
like
gats
and
infiltrate,
some
of
which
is
entangled.
My
hope
had
been
to
close,
especially
these
hrtb
related
things
through
progress
on
chalk,
but
also
like
the
the
gat
improvements
and
other
stuff
we're
doing
sort
of
around
that
area,
and
beefing
up
the
way
we
handle
these
higher,
more
advanced
logical
constructs
to
be
more
correct.
F
How
much
sense
of
whether
the
sort
of
fixes
in
this
area
like,
if
you
know
a
partial
fix,
is
likely
to
result
in
breakage
for
actually
sound
code
that
currently
compiles,
and
so
it's
sort
of
like?
If
we
want
a
more
complete
solution,
you
know
we
need
to
invest
a
lot
of
time,
but
a
partial
fix
is
also
going
to
break
people
that
you
know
are
not
actually
doing
anything
wrong.
C
A
E
A
Yeah
we
do,
I
don't
have
to
know
them
on
top
of
my
head.
We
have
like
in
preliminary
integration,
and
you
know
we
can
say
what
percentage
of
the
test
suite
passes,
for
example,
but
it's
still
a
fair
distance.
I
wouldn't
want
to
block
urgent
things
on
talk
landing,
but
I
think
the
other
thing
that
I'm
not
sure
about
when
I
look
at
these
issues
is.
A
I
would
like
to
have
a
way
to
assess
like
these
are.
These
are
on
this
list,
because
they're
recently
uncovered
that
doesn't
make
them
higher
priority,
necessarily
right
than
the
older
issues
we
knew
about
and
have,
if
anything
they
maybe
are
like
it's
hard
to
say,
but
maybe
the
older
issues
have
been
around
longer
right.
A
C
A
Well,
they
can
read
the
issues
and
dig
into
them
and
make
offer
some
suggestions,
I'm
not
sure
yeah
what
else
to
offer
there.
C
Do
we
need
to
like
go
try
to
find
more
type
theorists
to
pull
into
rust,
compiler
development.
A
Plausibly,
I
think
this
was
what
motivated
the
traits
working
group
discussion,
because
that's
sort
of
like
a
good
vector
for
those
sorts
of
people,
so
it
I
mean
one
answer-
might
be
to
try
to
do
an
initiative
of
this
kind
of
like
okay,
let's
do
a
soundness
push,
but
that
is
something
that's
been
on
my
mind,
but
I
think
I
put
it
off
for
now
because
it
didn't
seem
like
top
priority,
but
I
think
that
is
the
kind
of
thing
we
might
do
is
to
build
up
a
stronger
set
of
people
in
that
area.
C
A
F
A
A
Right,
I
mean
that's
what
that
would
be
part
of.
It
too
is
there's
an
existing
community
of
folks
right.
I
think
I
will
okay,
I'm
going
to
try
to
start
a
converse
start
up,
make
a
short
list
of
people
and
get
some
action
excite
around
this,
at
least
around
these
four
issues,
and
maybe
broader
start
a
rolling
effort.
E
I
know
you
wanted
to
address
all
issues
on
mass,
but
since
the
specific
issue
of
the
the
first
one,
the
f
and
out,
is
valid
type
for
unsized
types,
that's
an
issue
that
has
two
different
pr's,
one
that
you've
offered
one
that
esteban
wrote
like.
What
do
you
see
is
the
way
to
resolve
the
question
of
which
of
those
to
land
if
either.
A
C
In
joining
that,
if
only
to
try
to
get
more
expertise
on
what
kinds
of
things
go
into
a
discussion
like
that,
so
I'd
love
to
just
listen.
All.
A
C
All
right,
then,
let's
go
ahead
on
to
the
next
set
of
items
and
in
the
meantime
you
can
schedule
that
meeting
asynchronously,
okay,
so.
A
C
A
C
E
F
Okay,
yeah,
I
I
I
wasn't
sure
I'm
happy
for
feedback
on
that
point,
but
it
you
know
the
alternative
is
creating
like
five
action
items.
I
don't
know
which
is
better.
C
Well,
I
think
it
depends
if
we
actually
want
every
person
to
review
it
individually,
then
I
think
we
do
need
an
action
item
for
each
person.
If
the
thing
is
like
a
number
of
people
need
to
build
consensus
on
this,
then
fcp
works
pretty
well
for
that
already,
so
the
only
reason
to
add
additional
action
items
would
be
if
we
feel
like
we
need
to
avoid
diffusion
of
responsibility.
A
F
Yeah,
I
I
I
yeah,
I
don't
know,
I
think
the
main
thing
here
was
that
at
least
for
me
it
was
it
felt,
like
the
sort
of
reason,
for
the
action
item
was
less
so
that
everyone
should
do
it
and
more
so
like.
If
one
person
does
it,
then
we
can
move
to
fcp
or
you
know,
raise
concerns.
C
Right,
actually,
I
think
that
would
be
a
good
question
to
ask
here
is:
has
anybody
looked
at
the
stabilization
report
well
enough
to
feel
that
this
should
be
put
into
fcp
and
then
evaluated
via
the
fcp.
G
G
Can
read
that
and
propose
scp
if
that
would
help.
C
F
C
Five
minutes
ago,
yes,
awesome,
so
then
that
one
doesn't
need
any
further
action
in
this
meeting.
We
just
need
to
review
and
check
boxes.
Asynchronously.
C
Us
a
quick
overview
here.
A
Yeah,
I
can
summarize
it's
a
bit
of
a
grungy
detail
issue,
but
it
come
this.
This
is
a
feature.
This
is
a
feature
gate
we
introduced
when
we
were
adding
async
fn
it.
It
doesn't
feature
gate,
any
usable,
any
user
visible
feature
in
some
sense.
It
feature
gates
an
extension
to
the
region,
inference
algorithm
that
allowed
us
to
handle
functions.
That
return.
A
Let
me
copy
and
paste
the
example
allowed
us
to
handle
cases
like
this,
where
the
infiltrate
names,
two
different
regions
which
aren't
related
to
one
another
like
there's,
no
subset
or
superset
relationship.
We
used
to
require
that
there
was
some
subset
or
superset
relationship,
and
we
needed
that
for
async,
fn
and
just
out
of
caution,
I
put
a
feature
gate
so
that
it
only
affected
async
f10.
A
It's
been
stable
for
async
I
found
ever
since
async
fn
was
stabilized
not
aware
of
any
real
issues
that
have
come
up
as
a
result
of
it.
I
don't
think
it's.
A
There
are
some
potential
complications
with
other
language
features,
but
they're
inherent
in
the
design
of
the
language
and
not
something
that
like
are
caused
by
making
the
inference
engine
smarter.
The
particular
complication
I'm
referring
to
has
to
do
with
infiltrate
when
used
in
let
position
and
basically
what
it
comes
down
to
is.
Our
current
region,
inferencer,
has
is
not
particularly
smart
and
would
have
some
trouble
solving
the
constraints
that
arise,
but
that
is,
like
I
said
kind
of
inherent
to.
A
C
Makes
sense
one
quick
confirmation,
based
on
skimming
the
stabilization
report
and
there's
a
specific
reason.
I'm
asking
about
this:
the
syntax
that
you
wrote
for
our
member
of
tick,
a
or
tick
b
is
meta
syntax.
Talking
about
the
internals
of
the
resolver
and
not.
C
A
A
I
would
like
to
have
this
some
of
this
semantics
like
documented,
and
then
we
could
reference
them
and
that
might
make
it
easier
also
because
we
wouldn't
be
making
up
syntax
on
the
fly
every
time.
C
E
C
G
G
A
G
A
A
The
plan
I'm
working
towards
the
stabilization
of
async
functions
and
traits
and
one
of
the
stepping
stones
is
named
infiltrates
or
a
subset
of
them,
which
we
call
slice
zero,
which
avoids
some
of
the
inference
limitations
that
where
the
behavior
from
the
of
the
compiler
deviates
from
the
behavior
of
the
rfcs-
and
this
is
one
of
the
things
on
the
list
of
stuff
to
cross
out
in
order
to
get
that
work
done.
C
Awesome
is
there
a
road
map
issue
somewhere
that
talks
about
the
steps
towards
async
fun
in
trait
there
it
is
hold
on
a
second
with
risk,
presumably
one
of
the
steps
along
the
way.
I'm
about
to
put
it
here.
A
A
So
at
some
point
need
to
do
more
of
an
advanced
write-up,
but
that's
probably
the
best
source
right
now.
There
are
also
some
hack,
mds
and
other
planning
we've
been
doing
yeah
that
would
have
been
part
of
a
project
update.
E
C
C
Okay,
let's
move
on
to
the
next
item,
we
have.
C
Makes
sense
so
this
is
more
a
two
level
bullet
list
where
the
first
level
is
columns.
C
Whatever
works,
okay,
anything
else
before
we
go
on
to
84039.
A
C
Okay,
we
have
a
proposal
to
uplift
the
invalid
atomic
ordering
lint
from
clippy
to
rust,
see
for
context.
We
have
previously
requested
that
individual
uplifts
from
clippy
to
the
language
should
come
one
at
a
time,
so
that
we
can
get
an
explanation
and
justification
for
each
one.
So
this
seems
to
be
following
that
process
and
there's
a
fairly
specific
lint
here.
That
makes
sense.
C
I
think,
honestly,
if
we
want
one
day,
make
it
a
harder
error,
then
we
would
want
to
start
with
a
lint,
and
then
we
can
ratchet
that
length
upward
over
time.
B
G
All
right,
let's
do
it
meta
thing.
I
would
love
to
have
like
some
sort
of
attributes
that
could
be
applied,
that
the
linter
could
look
at
to
allow
people
to
write
this
kind
of
lint
with
attributes
so
that
we
didn't
need
100
of
them.
If
this
was
just
a
some
some
language
feature
for
this,
this
condition
must
hold
for
this
parameter
or
something
that
would
be
amazing.
F
In
theory,
we
might
get
that
like
to
some
extent
for
free
with
like
if
we
had
these
functions
as
constant
like
you
could
imagine
that
the
compiler
would
like
partially
evaluate
them
and
be
able
to
detect
the
panic.
F
A
Yeah,
I
was
thinking
two
things:
first,
that
it
seems
related
to
the
operands
for
cmd
operations,
which
I
still
think
might
make
a
nice
language
feature
a
way
to
say
you
know
this
third
one
is,
that
must
be
a
compile
time
constant
and
I
call
it
n
or
something,
and
then
you
could
imagine
having
conditions
on
it.
But
secondly,
if
we
do
I'm
still
interested
in
the
idea
of
adding
you
know,
making
rust
have
more
the
ability
to
do
more
formal
verification
and
logical,
predicates
and
preconditions
and
so
forth,
which
is.
G
Yeah
my
go-to
example
is
like
there's
a
special
distinct
lint
just
for
iterator
step
by
to
say,
don't
pass
zero,
yeah
and
like
if
we
added
a
distinct
link
for
every
language
for
every
library
thing
that
takes
a
a
primitive
type
but
doesn't
support
all
the
values,
then
that
would
be
a
mess.
It
would
be
real
nice
if
that
could
be
library
changes
and
used
by
everyone.
Instead
of.
C
And
the
flip
side
of
that
is
that
it
would
be
nice
to
have
that
same
partial
evaluation,
not
just
to
say.
Oh.
Can
we
statically
tell
that
we're
going
to
panic
at
runtime
because
you
passed
zero
to
step
by,
but
also
can
we
statically
tell
that
you're
not
passing
zero,
so
that
we
can
eliminate
that
panic.
C
G
C
I
did
by
the
way
fcp
this,
so
please
check
your
boxes.
If
you
are
happy
with
this
lint
one
general
design
thought
on
the
const
evaluation.
There
there's
a
similar
pattern.
That
applies
not
for
constant
evaluation,
but
rather
the
split
function
pattern
where
monomorphization
style
optimization
applies
when
you
have
a
function
that
takes
a
t
and
the
only
thing
it
does
with
the
t
is
turn
it
into
a
fixed
type.
We
kind
of
want
the
compiler
to
do
one
step
of
evaluation
and
then
process
the
rest
of
the
function.
C
The
same
thing
applies
here
where
you
could
have
an
annotation
that
says:
I'm
going
to
have
some
panics
right
at
the
start
of
the
function
or
assertions
right
at
the
start
of
the
function.
If
we
had
a
precondition,
panic
attribute
or
similar.
That
says,
please
evaluate
my
initial
panics.
If
you
can,
that
seems
appealing.
C
C
A
F
Yeah,
I
I
I
at
least
when
I
was
trying
to
when
I
nominated
this
didn't
come
up
with
a
sort
of
obvious,
like
reason
why
you
know
this
in
particular
is
dangerous,
but
other
uses
of,
like
floats,
aren't
necessarily
dangerous.
A
A
A
I
don't
know
it
is
what
it
is
arguably
inconsistent
with
other
constants
or
something
but
like
float,
doesn't
not
behave
in
a
nice
way.
Yeah
personally,
I
kind
of
think
that
said,
like
floats,
are
just
weird
in
every
language
and
finicky
because
of
the
way
that
they
ig
spec
works.
E
It's
in
future
income
pad
like
I,
I
thought
this
was
the
set
of
things
where,
like
once,
we
have
had
the
infrastructure,
like,
I
don't
think
the
future
and
compact
stuff
for
cargo-
that
the
report
thing.
That's
at
the
table,
your
upstream
dependencies
having
future
compatibility
issues
that
hasn't
been
stabilized.
Yet
I
don't
think.
C
C
F
C
F
A
But
there
was
kind
of
ambiguity
about
what
do
we
expect
like.
I
would
like
to
settle
the
story
about
constants
and
generics
and,
as
part
of
that,
settle
the
fate
of
this
lint
sorry
constance
in
match
missions,
and
I
don't
I
don't
know
how.
I
think
that
this
I
think
I
have
kind
of
that
was
kind
of-
and
we
were
talking
about
this
in
the
con
generics
meeting
a
couple
meetings
ago,
like
I
think
it's
influenced
by
con's
generics,
but.
G
E
E
I
thought
there
were
some
cases
where
you
see
the
dispatch
to
the
partial
eek
method
and
versus
where
you
versus,
where
you
see
direct
comparison.
That's
what
I'm
trying
to
say.
I'm
sorry,
I'm
not
being
clear
here.
I
don't
know
if
it
always
into
being
partial
leak,
I'm
not
sure
either.
E
No,
no,
I'm
not
being
clear
sorry.
What
I
meant
was
that
there
was
at
least
it
used
to
be
the
case
that
the
the
match-
compilation
wouldn't
use,
equals
the
equals
operator
and
every
point.
But
what
would
do
a
structural
dispatch?
I
just
can't-
and
I
yeah
I'm
not
being
helpful
here.
I
thought
there
was
a
case
where
it
might
end
up
doing
that
here,
but
I
can't
recall
off
the
top
of
my
head.
E
F
A
F
F
A
I
don't
know
so
I
think
the
direction
we're
probably
going
to
wind
up
going
is
that
pattern
matching
on
constants
is
just
not
the
same
as
comparing
them
with
equals
and
has
its
own
behavior,
which
is
more
structural
equality,
which
is
more
how
things
are
implemented
today
in
many
cases,
and
but
I
guess
I
just
agree
with
scott
overall-
that
we
should
just
keep
it
a
warning
for
now
and
make
a
plan
and
settle
it
as
part
of
a
bigger
picture.
But.
C
I
do
want
to
raise
one
possibility
here.
I
agree
that
we
should
have
a
plan,
but
at
the
same
time
we
can
do
conditional
branches
in
that
plan
and
see
if
both
paths
agree
on
the
next
step,
which
is
to
say
it
may
be
that
we're
not
sure
whether
this
should
be
a
future
income
headed
toward
a
hard
error
or
whether
it's
just
a
you
probably
don't
want
to
do
this,
and
you
should
really
know
what
you're
doing
and
we
may
not
know
which
of
those
two
plans.
A
A
What
I
was
going
to
say
is
that
actually
think
of
this,
but
it's
probably
the
case
that,
whichever
way
you
go,
this
behavior
is
compatible
because
if
it's
it's
compatible
with
the
eq
interpretation,
because
that's
how
it's
implemented
and
if
you
think
of
unrolling,
you
still
have
to
define
what
happens
at
the
leaves,
and
this
is
a
leaf
and
we
can
kind
of
say
what
we
want
to
happen.
A
E
G
A
G
C
Yeah,
this
would
apply
any
time
you
do
a
a
float
literal
in
a
pattern.
G
And
is
this
just
non-range
patterns
or
range
patterns
as
well
like?
Can
I
just
put
1.0
dot
dot
equals
1.0
and
the
compiler
will
shut.
G
Because
I've
been
subjected
to
some
linters
in
other
languages
that
don't
like
you
doing
equals
on
floats
even
for
zero
and
it
just
sort
of
results
in
people
doing
greater
than
or
equal
to
zero
had
less
than
or
equal
to
zero,
which
didn't
improve
anything.
But
it
made
the
linter
shut.
G
G
Well,
I
don't
think
the
end
point.
I
think
the
problem
is
the
endpoint
in
predictability
in
a
way
because
this
works
perfectly
fine
for
an
integer
like
two.
If
you
have
a
float,
that
is
exactly
two
and
you
match
it
against
two.
I
assume
it
will
do
exactly
that,
the
same
as
doing
equals
equals
two
and
an
if
statement
would
do
right.
G
C
C
I
was
just
gonna
suggest.
Maybe
we
should
summarize
the
open
questions
that
we
had
to
the
issue
and,
in
particular
the
mention
of
range
patterns
and
the
question
of
what
is
the
path
going
forward,
whether
we're
headed
toward
a
hard
error
or
not,
and
mention
that
we
don't
need
answers
to
all
of
those
questions
in
order
to
resolve
this,
but
we'd
like
answers
to
some
of
them
and,
in
particular,
is
the
handling
of
range
patterns.
What
we
want.
F
Yeah,
it's
worth
noting
that
the
author
of
the
pr
I
had
already
asked
about
the
range
patterns
question,
and
they
said
that
you
know
similarly
to
matching
against
a
constant
matching
against
the
range
where
the
you
know.
Edges
of
that
range
are
potentially
ill-defined
or
well
not
ill-defined
but
sort
of
fuzzy.
Is
you
know,
in
some
sense,
just
as
bad
for
some
value
of
bad.
A
A
I
agree
with
you
josh,
I
kind
of
after
having
thought
about
this
a
little
bit
I
feel
like
we
probably
could
settle
this
sub
question
without
settling
the
larger
constants
question,
so
I
would
sort
of
like
to
do
that
and
stop
thinking
about
it.
I
don't
that
said.
The
resolution
I
currently
favor
is
not
what
this
pr
proposes.
G
C
I
responded
to
this
and
scott
seconded
the
notion
that,
unless
there's
some
kind
of
warning,
then
you
end
up
with
warning
free
code.
When
you
really
shouldn't-
and
I
personally
when
I
use
to
do
like
this-
expect
to
keep
getting
warnings
about
unused
variables,
but
it
seems
worth
bringing
up
for
discussion
and
finding
out
do
we
want
to
just
close
this?
Do
we
want
to
propose
that
to
do
itself
is
something
that
should
produce
a
warning
or
not.
A
Do
feel
like
there's
a
problem
where
rust
code
is
super
annoying
in
the
early
days,
giving
you
lots
of
warnings
around.
You
know
why
you're
building
something
up:
lots
of
warnings
about
dead
code
and
other
stuff
that
you
know
will
get
used.
Eventually,
I'm
not
sure
that
this
narrow
take
on
the
problem
doesn't
motivate
me
especially
hi,
maybe
because
I
never
used
to
do.
F
I
I
think
in
all
cases
where
at
least
I've
been
sort
of
developing
code
or
whatever
and
trying
to
you
know,
do
something,
and
maybe
I
get
a
lot
of
warnings,
but
maybe
there's
some
errors
and
just
burst
the
thing
that
annoys
me
a
lot
more
is
when,
like
I
need
to
scroll
up
to
find
the
air,
because
I
have
a
wall
of
warnings
and
it
feels
like
tackling
that
is
not
tackling
this,
and
I
would
rather,
you
know,
generally
speaking,
the
unused
variable
warnings
are
not
really
annoying
me.
A
C
For
what
it's
worth
the
that
early
state
of
developing
rust,
I
personally
find
that
to
be
really
satisfying
of
here's
20
warnings
that
tell
me
what
I
haven't
done
yet.
Here's
19
warnings
that
tell
me
what
I
haven't
done
yet
code
till
all
the
warnings
are
gone
right,
so
josh.
C
C
I
wasn't
disputing
your
point
mark.
I
was
responding
to
nico's
point
of
the
annoying
early
prototype
stage
and
I
was
thinking
that
that's
kind
of
the
awesome
early
prototype
stage.
I
do
agree
that
it's
easy
to
lose
warnings
in
a
sea
of
lose
errors
in
a
sea
of
warnings.
That's
a
different
problem.
G
I
I
think
I
agree
with
both
you
and
nico
josh
they're
like
oh,
you
have
some
parents
whatever.
I
don't
care,
whatever
happens,
or.
G
A
Yes,
I
definitely
don't
want
to
just
allow
warnings.
It's
not,
but
wasn't
there.
There
was
an
rfc,
which
I
think
we
accepted
to
add
something
like
expect
where
you
would
say
like.
I
expect
a
dead
code
lint
here
and
then
you
can
actually
get
an
error
if
you
don't
get
a
dead
code
lint,
that's
what
I
usually
really
want
for
dead
code,
especially
and
a
lot
of
these
cases.
Actually
I
want
to
say
like
I
know
this
is
wrong.
It's
intentional,
but
I
do
if
I
accidentally
fix
it.
E
C
A
whole
joking
meta
discussion
about
what
happens
if
you
expect
unexpected
lengths
and
whether
there.
A
C
A
F
A
C
And
then
I
would
be
happy
to
fcp
close
the
proposal
here
and
then
people
can
check
their
boxes.
A
C
A
C
Bug
casts
lint.
There
were
several
discussions
about
this,
and
the
last
state
of
this
was
that
we
didn't
quite
have
consensus
on
exactly
what
we
wanted
here,
because
it
doesn't
implement
the
original
solution
to
the
issue.
There
was
still
some
discussion
of.
Do
we
want
what
this
is
anyway,
but
there
was
some
back
and
forth
on
which
pieces
we
want
which
pieces
we
don't.
C
A
C
So
you're
not
talking
about
whether
the
problem
of
accidentally
passing
the
lowercase
max
function
instead
of
the
uppercase
max
constant.
A
It
seemed
to
me
like
that
problem
was
not
actually
solved
by
this
lint
in
a
reliable
way.
It
didn't
work,
for
example,
for
you
size
max,
which
is
something
I
commonly
reference.
A
A
C
Right
exactly
so,
I
mean
the
ideal
solution
to
this
would
involve
the
mythical
portability
lint,
and
I
invoke
that
as
mythical,
because
it
really
would
solve
a
lot
of
problems.
It's
also
incredibly
hard
to
get
right,
but
the
problem
and
solution
is
you
don't
want
to
cast
a
pointer
to
a
32-bit
value
unless,
of
course,
you've
declared
that
your
code
will
only
run
on
32-bit
platforms
along
the
same
lines?
G
Here's
a
here's,
a
proposal
to
throw
it
there.
We
say:
let's
do
this
lint,
but
remove
the
it
fixes
that
original
issue,
because
it
doesn't
fix
the
issue
that
last
you
looked
at
this.
It
said
it
was
fixing
that
and
then
we
can
tune
this
lint
as
necessary.
I
don't
know
if
we
want
to
you,
know,
put
it
in
as
allow
and
ask
for
a
creator
run
to
see
how
bad
it
would
be,
or
something
like
that
had
it
had
one
sorry,
I
didn't
look.
A
A
C
F
C
We
could
do
that
would
eliminate
this
issue.
We
could
add
this
lint
and,
as
noted,
you
could
allow
it
if
you're
on
a
32-bit
only
platform.
We
could
also
start
working
with
the
libs
team
on
the
idea
of
initial
introduction
of
a
truncate
function
or
similar
to
explicitly
say
no
really.
I
want
to
truncate
this
to
u32.
A
That's
a
good
point
about
eye
size.
We've
been
ignoring
that
completely.
We
should
definitely
permit
eye
size.
A
C
G
C
C
Just
I
would
say,
taylor
is
not
currently
on
the
call
and
he's
the
person.
I
would
expect
to
be
chiming
in
right
now,
so
I
don't
think
we
have
confirmed
consensus
since
the
strongest
opponent
of
this
is
not
present.
C
C
E
G
The
that
would
be
a
disallow.
C
G
G
C
E
So
I'm
trying
to
understand
the
suggestion
you've
made
if
you
wrote
it
on
the
ticket
as
well.
You
say
you
want
to
force
people
to
go
through
fn
so
as
and
you
want
them
to
have
to
write
out
the
explicit
type
for
this
thing
in
terms
of
the
arguments
and
return
type.
C
Yeah,
I
think
that
that's
a
reasonable
proposal
and
scott.
You
should
post
that
and
I
wouldn't
be
surprised
if
we
have
consensus.
I
wouldn't
be
surprised
if
we
don't,
so
you
should
post
that
and
see
if
we
do,
but
that
aside.
Hopefully,
we
can
proceed
further
on
the
issue
and
discuss
it
there.
We
are
out
of
time.
As
a
quick
note,
I
want
to
call
attention
to
the
very
last
item:
eight
four,
eight,
seven,
nine
just
because
it's
something
we
yeah.