►
From YouTube: Lang Team Triage Meeting 2020.05.07
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).
A
B
So
before
you
got
before
everybody
got
here,
I
had
already
looked
and
saw
the
three
nominated
issues
and
or
sorry
p,
high
issues
and
those
three
issues
were
the
same
ones.
We
talked
about
last
week
that
don't
we
don't
think
we're
making
forward
progress
on
that's
worth
talking
about
in
the
meeting.
B
So
I
think
the
next
one
would
be
the
well-formedness
check
on
types
with
no
type
parameters
that
one
was
nominated
and
you
wanted
to
see
that
one
so
folks
wanted
to
see
that
one
discussed
in
a
meeting.
A
A
Okay,
just
are
we
still
at
the
same
monday
time?
At
this
moment,
we
haven't
made
any
changes
right.
B
So
we
haven't
made
any
changes,
yet
we,
it
was
a
little
late
last
week
and
then
this
week
there
was
some
juggling
going
on.
He
would
probably
be
a
good
idea
to
go
ahead
and
make
the
change
now
on
thursday,
so
that
people
have
friday,
monday
and
so
on,
to
get
used
to
the
change
and
they
see
when
the
new
meeting
is
going
to
be.
So
it
would
be
a
good
idea
to
go
ahead
and
nail
down
when
those
times
are.
A
B
C
B
B
I
think
that's
going
to
be
our
best
time
for
the
design
meeting
and
then
for
the
triage
meeting
looking
through
I'm
looking
for
a
time
that,
at
a
minimum,
all
six
members
of
the
lang
team
can
attend,
and
there
are
a
handful
of
times
that
work
for
that,
but
none
ideally
and
all
of
them
are
going
to
have
some
people
marked
as
if
need
be.
So
we
need
to
figure
out
who
minds
doing
which
times.
B
A
Maybe
yeah
not
during
this
live
meeting
right
now.
I
guess
then.
B
Yeah,
I
agree,
but
we
should
start
a
zulip
discussion
to
confirm
which
time
we
should
use,
but
I
think
we
should
go
ahead
and
commit
to
moving
the
design
meeting
to
wednesday.
10
a.m.
U.S,
pacific
and
I
will
take
the
responsibility
of
writing
that
up
for
a
blog
post
and
changing
the
calendar
entry,
but
I'm
hoping
to
write
up
one
post.
That
also
says-
and
we've
moved
the
triage
meeting.
So
I'd
like
to
figure
that
out
today
as
well.
A
A
D
B
B
B
B
I
unnominated
68717
because
it's
just
waiting
on
people
to
check
their
boxes.
It
is
already
in
fcp
or
rather
in
proposed
fcp.
So
if
anybody
doesn't
want
to
check
a
box
there
and
wants
to
register
an
objection,
then
they
can
do
that
asynchronously
nico.
Do
you
believe
there
is
progress
we
can
make
on
six
nine
seven
one
four
one
in
this
meeting
more
well
forming
in
this
check
on
types
with
no
parameters.
D
A
Of
change
like
what
this
pr
did
was
basically
to
introduce
additional
checking,
but
that
checking
only
takes
place
if
the
type
alias
has
no
generic
parameters,
and
otherwise
it
doesn't,
which
I
think
is
not
a
great
place
to
stay
for
a
long
time.
It
might
be
an
okay
place
to
land
as
a
transition
point
you
know,
so
my
an
example,
I
don't
know
an
example
would
be
that
this.
This
would
error
with
the
pr,
but
but
this
would.
A
B
A
Do
we
want
to
leave
this
blocked
until
we
discuss
it
more
broadly,
do
we
want
to
close
it
and
still
try
to
discuss
it
more
broadly,
just
by
just
saying
basically
we
don't
want
to
do
this
in
isolation,
but
we
might
do
it
as
part
of
the
plan
and
let's
get
it
off
the
prq.
For
now,
that's
the
guest
minor
thing
and
the
final
thing
would
be
just
to
say.
You
know
we
just
don't
think
we're
gonna
tackle
this
problem
right
now,
because
it's
so
long-standing.
A
Only
because
I
have
I
forget
if
this
is
a
sign
geneva
too
many
open
pr's,
and
they
stress
me
out,
but
it's
kind
of
an
orthogonal
problem
to
whether
we
should
talk
about
this
issue
more
broadly,
and
I
think
we
should.
A
B
A
B
Okay:
okay,
let's
enqueue
that
for
that
then
so
the
next
one
up
is:
let's
go
back
to
71
599,
coercion
between
functions
and
non-capturing
closures.
Nico!
You
nominated
this
one
as
well
for
discussion
because
of
the
change
to
the
type
behavior
you
did,
although
I
don't
see
it
in
this
list
of
mine.
B
A
B
A
Stupid
paper,
no,
thank
you.
I
guess
that
goes
here
in
the
list,
so
the,
but
this
is
about.
As
some
of
you
may
recall,
we
added
a
extension
at
some
point
that
let
you
write,
closure
notation
but
get
out
a
function
pointer
which
has
no
captured
environment.
A
A
However,
you
have
to
do
it
right
now.
I
think,
in
a
fairly
limited
way,
it
has
to
be
triggered
by
the
expected
type.
So
the
code,
I
wrote
of
works,
fine,
but
something
like
this
if
it
does
not.
As
far
as
I
know,
someone
could
test
it
if
they
want,
but
I
think
that's
true
and
also
what
does
not
work
and
what
the
pr
this
is.
What
the
pr
is
actually
immediately
trying
to
address
is
something
like
something
where
you
combine.
A
A
This
will
not
type
check
today
because
because
it
won't
but
but
I
think
it
would,
if
you
put
in
like
a
an
as
here,
so
that
the
definition
knows
kind
of
when
it's
being
type
checked,
that
it
needs
to
be
sourced,
and
so
this
this
vr
makes
some
changes
that
try
to
make
this
last
case
type
check.
A
I
think
I
think
it's
not
too
hard
and
what
I'm
trying
to
what
I'm
pushing
towards
is
that
we
try
to.
If
we're
going
to
fix
this,
we
try
to
fix
it
sort
of
across
across
the
board
so
that
in
general
a
closure
can
be
coerced.
A
But
if
you
do
so,
you
get
an
error
if
it
has
captures-
and
I
just
wanted
to
like
check
in
inform
people
that
this
was
happening
and
hear
if
there
are
any
concerns
or.
B
Given
that
we
already
support
doing
this
via
assignment
it
sounds
like
this
is
just
a
natural
extension
to
being
able
to
use.
As
for
this,
what
would
be
the
fundamental
reason
we
wouldn't
want
to
do
this.
A
B
B
For
now,
for
simplicity's
sake,
maybe
go
ahead
and
take
it
down
at
the
bottom,
like
you're
currently
doing,
and
we
haven't
tried
having
point
by
point
minutes
the
way
that
you're
doing
before.
So
why
don't?
We
assume
for.
C
B
F
Agreed
for
the
coercion
thing,
I
think
it
could
also
be
explained
similar
to
the
const
block
idea
that
scott
had
as
sort
of
we're,
simplifying
what
you
have
to
type,
even
though
technically
it
was
legal
before
we're
just
making
it
easier
for
you.
A
F
D
Like
most
notably
the
last
case,
you
wrote
nico
the
let's
see
equal
slice
or
array.
However,
you
want
to
put
it
if
that,
if
you
put
the
type
annotation
on
the
c
there,
so
you
said,
let's
see
colon
array
of
f
of
function,
pointers
that
would
then
work
right,
because
that's
analogous
to
the
very
first
case,
you
wrote.
D
A
Okay,
it's
slightly
more
general
in
the
sense
that
you
this
variable
c.
You
now
have
access
to
the
closure,
both
with
its
closure
type
and
with
a
function
pointer
type.
Sorry,
I
don't
know
how
to
turn
those
off
at
the
moment,
but
before
you
only
had
one
or
the
other,
but
I
think
it's
not
a
big
difference.
D
I
see
because
now
we
have
the
dynamic
behavior
that,
as
will
extract
the
the
code
pointer
from
the
closure.
A
C
A
Yeah,
that's
good.
It
reminds
me
of
how
one
well,
this
is
off
topic,
but
I'm
gonna
go
anyway.
It
just
reminds
me
of
the
fact
that,
because
each
function
like
flu
and
bar
here
have
it
has
a
unique
type,
it's
been
observed
that
today
we
require
you
to
specify
the
avi
at
the
definition
of
the
function,
but
if
you
want
to
have
an
alternative
api
that
is
but
plausibly
we
could
allow,
we
could
allow
it
to
get
coerced
to
many
different
apis
and
just
generate
shins,
and
things
like
that.
A
C
Oh,
that
would
let
us
turn
funds
into
unsafe
funds
and
stuff
like
that
too
right,
or
do
we
already
do
that
yeah?
You
should
do
that
too.
A
Maybe
yeah
it
depends
how
far
you
want
to
go.
You
probably
want
to.
I
would
guess,
you'd
want
to
make
that
an
explicit
coercion.
C
B
Okay,
so
it
sounds
like
it
sounds
like
we
might
want
to
fcp
merge
this
and
confirm
consensus.
A
B
Oh
you're
already
good,
very
good
yeah.
I
think
that
the
the
only
question
is
does
pin
make
this
different
than
in
the
non-pinned
case,
in
terms
of
is
it
okay
to
pre-memory
without
calling
the
destructor
of
that
memory.
B
B
B
E
B
B
B
B
A
I
wish
we
had
made
it
well,
we
didn't
you
had
we
had
made
it
what
I
wish.
We
had
said
that
panicking
and
destructors
always
aborts.
In
retrospect
this
has
come
up
many
times
and
every
time
I
I
feel
like
that
would
have
been
the
better
choice.
C
A
C
B
Well,
if
you're
in
the
middle
of
dropping
something
and
you
panic,
we
could
technically
call
a
function
that
the
user
can
provide,
and
then
we
can
say
that
if
you
do
anything
in
that
function,
other
than
return
like
that
function
must
return,
never
meaning,
not
return.
B
We
could
give
you
control
over
that.
If
you
need
some
way
to
potentially
recover
but
yeah,
I
don't
see
any
way
that
you
could
reasonably
recover
from
the
situation.
Ralph
is
describing
suppose
that
you
are
managing
memory
that
is
going
to
be
dmade
into
or
copied
into,
or
some
asynchronous
operation
is
going
to
right
into
it,
and
you
then
try
to
you
know
your
drop
would
have
canceled
that
operation.
B
A
A
B
A
B
I
can
certainly
think
of
common
cases
where
your
drop
might
potentially
panic
in
terms
of
all
you'd
have
to
do
is
call
dot
unwrap
on
some
system
function
that
you
don't
expect.
Error-Ended
errors.
A
A
A
E
E
B
Okay,
I
will
make
a
quick
note
on
that
issue,
pointing
out
the
one
thing
that
we're
talking
about
here
of
what
use
cases
we're
concerned
about,
and
then,
if
we
want
to
have
a
longer
discussion
of,
should
we
migrate
to
abort
in
general?
Or
can
we
abort
just
in
this
case
or
is
there
something
else
we
can
do?
We
can
either
have
that
asynchronously
or
queue
it
up
or
for
that
matter
see
if
we
can
get
taylor
involved
in
that.
B
All
right,
so,
let's
move
on
to
the
next
item
here
there
we
go
add
a
must
use
trait
to
complement,
must
use
the
attribute.
This
was
five
days
ago
and
let's
see
who
nico
nominated
this
one.
A
Yes,
I
did
we've
discussed
it
before
so
the
con,
I
don't
have
the
I
guess.
I'm
not
gonna
worry
about
the
document,
but
let
me
pull
up
the
pr
since
I'm
sharing
my
screen,
you
might
as
well
use
it
for
something.
The
the
context
is
that,
especially
you
know
we
keep
finding.
A
It's
kind
of
important
because
it
must
use
is
how
we
prevent
the
case
where
you
forget
to
await
a
future,
which
is
a
common
mistake.
Example
in
this
case,
is
optimum
to
propagate,
must
use
through
option.
So
this
pr
proposes
or
is
experimenting
with.
Let's
say
is:
if
it
doesn't
have
an
example,
does
that
mean
must
use?
A
And
then
you
can
sort
of
say
I
implement,
must
use
for
all
t
for
option
of
t
if
t
is,
must
use
and
stuff
like
that,
I'm
a
little
bit
skeptical
of
this,
but
I
don't
want
to
color
the
discussion
too
much
like
we
don't
have.
Jonas
in
here.
I
don't
know
how
strongly
they
would
advocate
for
it.
We've
talked
about
it
before
and
I
had
basically
the
same
concerns
at
that
time.
I
just
wanted
to
bring
it
up
to
sort
of
head
off
this
direction.
A
Prefer
to
extend
the
attribute
in
slightly
more
ad
hoc
way,
but
I
can
go
into
mine
I'll
leave
it
there
for
now.
B
B
On
the
other
hand,
are
there
cases
where
that
isn't
universal,
for
instance,
if
result
is,
must
use?
Is
there
a
case
where
option
of
result
is
something
where
we
don't
want
to
force
you
to
use
the
result.
A
Okay,
so
you're
saying
I'm
not
aware
of
any,
I
don't
think
I
understand
the
question.
Maybe.
B
B
A
I
was
gonna
say
that
I
don't
think
that
occurs
because,
or
at
least
like
we
don't
handle
that
very
well.
But
what
does
occur
is
you
can
apply
the
must
use
attribute
to
a
function,
it's
sort
of
the
other
way
you
can
say
the
result
of
this
function
must
be
used,
even
though
its
type
would
not.
Ordinarily
have
indicated
that,
and
that
does
not.
You
can't
express
that
in
the
trade
system,
which
is
one
of
my
concerns
with
this
design.
B
B
A
must
use
that
doesn't
seem
like
an
issue
when
the
only
things
marked,
as
must
use
are
like
result,
for
example,
but
it
does
seem
like
an
issue
if,
if
we
declare
a
huge
swath
of
things
must
use
dynamically
based
on
trait,
we
may
well
run
into
cases
where
we
want
to
say
no
that
isn't
really
much
use.
C
So
I've
been
pondering
that,
in
from
a
like,
so
I'll
jump
back
for
a
second
I'm
sorry
conditional
behavior
into
the
attribute
doesn't
make
me
super
excited
it
feels
like
if
we
want
to
have
conditional
behavior
for
this
is
must
use
if
something
else
is
must
use
based
on
types.
C
The
trait
version
certainly
seems
the
obvious
syntax
for
doing
that,
but
at
the
same
time,
I
also
don't
think
I
really
want
to
ever
see
someone
bound
to
generic
by
the
fact
that
the
t
must
be
must
use
somehow,
because
that
feels
really
weird.
C
C
Must
use
which
makes
me
wonder
if
maybe
we
could
do
something
like
we
always
propagated
out,
but
there's
some
form
of
this
attribute
that,
where
you
can
say
no,
I
promise
I've
encapsulated
any
must
be,
if
you
do
have
this
case,
where,
like
your
random
custom,
struct
or
a
thing
that
has
a
phantom
data
of
d
in,
it
does
not
need
to
be,
must
use
just
because
of
holding.
It
must
use.
D
C
A
I
think
there's
a
big
difference
between
this
and
orbits,
which
is
that
are
auto
trades.
Is
that,
for
example,
I
would
not
think
that
this
struct
would
be
must
use.
A
Because
I
think
that
what
is
being
proposed
is
sort
of
specific
to
generic
types
like
if
I
wanted
foo
to
be
must
used,
I
would
make
food
must
use
here
where
I've
hardcoded
the
result.
But
in
contrast,
if
I
had
a
you
know,
bar
and
t
turns
out
to
be
a
result.
A
That's
not
how
auto
trades
behave
right,
and
so
that
seems
different
to
me.
I
this
is
exactly
I'm
not.
I
don't
actually
remember
exactly
what
the
proposal
was
that
we
kind
of
semi
pushed
back
on,
but
I
think
it
was
more
or
less
the
expansive
version
that
you're
naming
scott,
it
might
have
been
different,
and
I
remember
at
the
time
there
were
a
number
of
examples
of
what
seemed
like
pretty
clear,
false
positives,
or
at
least
potentially
false
positives.
I
think
our
conclusion
at
the
time
was
not
like
hard.
A
C
A
B
Think
that
it's
still
true
that,
if
we
want
somebody
to
do
this,
they're
going
to
need
to
write
it
up
and
handle
all
the
implications,
but
I
would
also
add
something
that
this
seems
really
elegant
in
that,
like
the
trait
system
feels
like
a
good
fit
for
this.
On
the
other
hand,
I'm
wondering
if
it
actually
is
a
good
fit
or
if
it's
just
the
closest
fit.
That
feels
like
what
we
have
in
our
type
system,
because
this
is
kind
of
an
infectious
property
that
shouldn't
really
affect
the
type
itself.
B
It's
almost
more
an
aspect
of
a
particular
instance
of
a
type
you
could
have
a
a
vec
of
something
that
isn't
must
use
an
event
of
something
that
is
must
use
even
if
they're
the
same
type,
and
they
just
naturally
convert
from
one
another
and
coerce
that
would
actually
allow
you
to
handle
the
case.
Where
calling
this
function
returns.
A
u64
that
is
must
use,
even
though
u64
in
general,
isn't
must
use.
A
You're
proposing
that,
if
you
did
this
josh
using
my
example
above
you
get
a
warning
because
the
vec
of
dual
sort
of
I
mean
I
don't
think
it
would
be.
I
don't
know
it
wouldn't
exactly
be
flow
state.
It
would
be
probably
that
there
I
don't
know
what
it
would
be
actually,
but
it's
sort
of
a
local
compression
property,
but.
B
I'm
not
suggesting
we
should
do
it.
The
reason
I
brought
that
up
was
not
to
say:
let's
do
this.
The
reason
I
brought
this
up
was
to
say
I
think
this
might
be
more
complicated
than
just
the
trait
system
and,
if
somebody's
going
to
make
a
full
rfc
proposal
for
it,
they
should
actually
look
into
that
and
decide.
A
I
think
my
my
concern
is
when
you
wind
up
with
types
that
are
the
same
but
they're
not
the
same.
It
just
we're
wrestling
with
that
in
a
lot
of
it's
just
a
really
big
implementation
complexity.
So
that's
not
it's
not
to
say
that,
and
I
appreciate
you
weren't
necessarily
advocating
for
that.
Just
saying
I
wouldn't
go
that
direction,
but
there
might
be
a
way
to
nonetheless
make
this
worn.
It's
more
works
and
differently.
I
don't
know
if
it
should
or
shouldn't.
D
A
Or
you
know
it's
only
works
so
far
like
you.
Don't
have
to
necessarily
combine
in
that
way,
but
I
anyway,
I
sort
of
have
mixed
opinions.
I
I
definitely.
A
I
still
feel
like
the
trade
system
appears
to
be
a
good
fit,
but
it
isn't
when
you
look
more
closely
you're
like
do,
we
want
something,
that's
like
it's
must
use.
If
it's
debug,
I
don't
know,
maybe
I
guess
I
don't
know
why
to
forbid
it,
but
it
just
seems
like
it'll
be
confusing
to
people,
because
it's
such
a
sharp
tool
for
such
a
one
purpose.
C
The
other
thing
this
is
reminding
me
of
is
the
conversation
of
not
we
don't
want
people
to
have
to
put
must
use
on
every
single
function
because
be
able
to
guess
for
obvious
cases
whatever.
That
means
the
the
tracking
issue
for
must
use
is
talking
about.
No,
let's
not
go
and
put
this
on
the
95
of
methods
in
the
standard
library
that
take
a
that
take
a
ref
and
return
something
and
they
don't
have
any
side
effects,
but
we
don't
want
to
force.
People
to
write
must
use
on
all
of
those.
C
If
any
time
you
hold
a
generic,
it's
relatively
common
that
someone
will
say,
but
I
wanted
to
know.
If
I
put
a
result
in
there
that
I
should
use
it,
then
we
should
find
a
way
to
just
do
that
and
have
an
opt-out,
and
then
maybe
that
would
allow
us
to
do
the
same
thing
for
functions
that
we
could
have
that
simple
rule
that
look
you're
going
to
get
a
warning
for
not
using
the
result
of
a
function
if
it
takes
a
ref
to
something.
C
That's
freeze
and
you
know
if
it
doesn't
take
any
mutable
references
and
all
of
its
shared
references
are
to
freeze
things.
Then
it
in
some
sense
must
not
have
done
anything
and
if
you're
doing
something
super
weird,
you
can
opt
out
of
it
with.
I
don't
know,
strongmen
must
use
never
or
something,
but
then
we
could
do
the
same
thing
on
types
where
option,
because
it
has
the
generic
eric
as
sample
here
does
just
becomes,
must
use,
and
you
can
opt
out
of
that
if,
for
some
reason,
it's
inappropriate
for
your
type.
C
C
A
B
I
think
it
would
be
worth
moving
on
and
seeing
if
we
can
get
through
some
of
the
other
items
up
for
discussion.
B
So,
looking
at
the
nominated
issues,
a
quick
glance
through
that
one,
we
went
through
three
of
these
in
the
last
meeting
and
I
don't
think
something
has
changed
since
then
other
than
yes,
we'd
really
like
to
do
raw
pointers
to
solve
rubber
pack,
but
their
tracking
issue
for
config
version
got
nominated
for
discussion
and
it
sounds
like
we
actually
have
an
implementation
of
config
version.
That's
close
to
ready,
but
in
any
case
the
discussion
was
effectively
should
a
nightly
version
of
the
compiler
for
the
purposes
of
version
count.
B
As
that
version
of
the
compiler.
B
A
A
That
means
you
presumably
have
some
idea
how
feature
x
works,
but
there
are
many
many
nightlys
that
are
all
version
1.45,
which
may
all
have
incompatible
versions
of
feature
x
right.
So
if
I'm,
that
means
that
my
crate
will
only
compile
with
some
range
of
like
nightly's
after
the
point
where
it
reached
its
final
form
right.
B
Right
to
clarify
something
by
the
way
this
was
discussed
at
length
in
the
rfc,
and
we
did
come
to
the
conclusion
that
we
are
not
trying
to
deal
with
the
range
of
nightly's
pace.
So
this,
in
terms
of
this
is
not
something
we
think
people
should
be
able
to
distinguish
ranges
of
nightly
using
this
config
directive.
The
concern
is
more
robustness
when
it
comes
to
what,
if
you're,
trying
to
look
for
a
feature
that
will
be
released
in
145
at
one.
B
C
B
Right
that
would
be
the
concern
and
the
other
the
flip
side
of
that
is.
If
we
don't
do
this,
then
people
may
not
be
able
to
test
upcoming
versions
of
the
compiler
to
determine
okay.
I
think
this
is
the
version
I
can
use.
Let
me
start
compile
testing
my
code
against
nightly.
With
that
feature,
we
would
be
effectively
saying
you
don't
get
to
use
a
config
directive
for
the
feature
until
the
compiler
has
gone
to
at
least
beta,
if
not
stable.
C
A
D
C
I'm
just
thinking
so,
if
you're,
if
you're,
writing
this
against
something,
that's
on
nightly,
that's
about
to
go
stable,
you
have
this
using
your
nightly
flag
and
your
crate
is
working
fine
with
the
nightly
flag.
It's
just
a
matter
of.
When
do
you
switch
your
crate
over
to
looking
for
a
cfg
version
for
that
piece
of
cfg
code
instead
of
the
instead
of
the
cargo
feature
right.
B
Right
and
given
that
you
describe
it
that
way,
you
certainly
could
say
if
I'm
on
nightly
and
have
set
the
nightly
feature,
or
I
have
this
version
chat
which
would
allow
people
with
nightly
to
opt
in
to
just
break.
If
I
don't
seem
to
have
the
feature.
A
You
can
test
it,
but
you
need
a
config
flag
right,
so
you
can
always
make
your
own
config
flag
and
build
with
rust
flags
cfg
or
something
you
just
can't
like
get
it
onto
cargo
and
conveniently
access
it.
E
B
A
E
I
will
note
that
at
least
historically,
whenever
crates
do
version
detection
and
they
are
allowed
to
do
that
with
like
nightly.
We've
had
some
amount
of
trouble
with
bisection,
where,
if
you
go
back
over
the
past,
you
know
four
or
five
weeks
of
nightlys
and
they're
testing
for
the
current
nightly
a
lot
of
the
time.
Crates
won't
do
it
like
they
don't
actually
test
for
the
feature
they
say.
Oh
it's
nightly.
It
must
be
recent
and
that's
sort
of
similar
to
this,
where
you
would
be.
E
A
We
should
prioritize
the
idea
of
I
have
a
crate
that
builds
no
matter
what
compiler
you
use
it
with,
and
that
includes,
I
think,
nightly
compilers,
and
you
don't
get
that
with
this
feature
and
there's
a
number
of
workarounds
if
we
say
that
you're
testing,
the
stable
version
and
what
you
actually
want
is
to
try
out
some
stuff,
that's
on
nightly,
you
can
do
that
in
other
ways
by
either
having
a
feature
or
by
having
a
rust
flag.
You
kind
of
can't
get
this.
I
work
with
any
compiler.
You
throw
at
me
any
other
way.
A
B
So
let
me
ask
a
slight
logistical
question:
how
hard
will
it
be
for
us
to
implement
the
idea
that
theta
will
say
it's
a
new,
stable
but
nightly
it
will
say
it's
the
last
stable.
B
A
C
You
know
a
subtract
one
in
the
right
place,
or
this
nightly
it's
a
greater
than
instead
of
a
greater
than
or
equal
or
something
can.
E
B
Suppose
that's
true
location
perspective.
Okay,
then,
in
that
case,
do
we
have
consensus
on
the
notion
that
stable
and
beta
should
report
their
version
and
nightly
should
go
back
a
version
and
report
the
last
beta.
G
B
Right,
okay,
I
can
summarize
this
issue
and
proposal
then,
for
the
tracking
issue
thread.
It's.
B
So
at
least
one
person
complaining
on
the
issue
said
that
it
will
instead
just
cause
people
to
go
back
to
doing
version,
detection
and
build
scripts,
but
I
am
slightly
skeptical
of
that,
especially
I'm
hoping
that
in
the
common
case,
people
can
use
things
like
config.
Accessible
version
is
really
just
for.
We
added
this
feature
to
the
language
that
isn't
detectable
by
the
availability
of
a
symbol.
E
E
B
C
C
The
point
about
way
out
sure
is
interesting,
because
I
kind
of
want
to
block
that
from
there's
no
way
that
can
possibly
be
right,
but
that
also
would
prevent
this
from
being
useful
on
old
compilers.
So.
C
B
To
detect
new
compilers,
if
you
block
it,
because
the
leave
and
the
recording's.