►
From YouTube: Lang Team Meeting 2019-07-11
Description
Topics covered
- never type
- coherence soundness problem
- unwinding and FFI
Minutes
https://paper.dropbox.com/doc/T-Lang-Meeting-2019.07.11--Agsvu03FSbAtkpN1VlKNgKd~Ag-hWybfJJYYpBkLF83aMAsi
A
No,
it
knows
who
I
am
alright
cool
meeting
recording
started.
Let
me
share
that
window
again.
There
we
go
so
we
had
a.
We
did
some
pre
triage
here,
so
we
were
gonna,
go
down,
I!
Guess
we'll
go
briefly
through
these
things,
the
ones
that
are
most
important.
This
item
we're
gonna
cover
at
the
end
red.
B
A
For
async/await
the
current
status,
there
was
a
some
question
around
a
synchronization
event,
but
I
think
we've
resolved
that
we
do
intend
to
stabilize
the
current
behavior.
If
you
didn't
follow
along
you
can
do
so.
We
need
the
basic
I
think
at
this
point.
Most
of
the
blockers
are
down,
but
we
want
to
improve
the
test
suite
and.
B
A
B
A
A
A
C
A
B
A
Right
so
there's
two
problems
with
never
type,
but
the
one
we
wanted
to
focus
on
stabilization.
But
one
thing
we
wanted
to
focus
on
was
we
said
at
some
point.
We
should
try
to
be
forwards
compatible
with
the
fact
that
there
doesn't
exist,
some
imple
or
other
and
I
don't
remember.
Maybe
somebody
wants
to
talk
about
yeah.
E
E
Right
so
there
was
some
conversation
around
like
my
sort
of
preferred
option,
for
this
is
that
we
just
stabilize
what
we
have
today
and
that
since
we
know
that
any
from
our
into
in
pole
that
takes
the
never
type
as
an
argument,
it
must
be
equivalent
since
they're
all
uninhabited.
We
can
just
accept
them
all,
but
obviously
that's
like
not
and
like
uncontroversial
or
like
obvious
language
change
right.
So
can
you
repeat.
E
Any
any
implementation
of
from
our
into
for
bangs,
so,
for
instance,
I'll,
actually
I,
should
back
up
a
little
bit
and
explain
why
this
is
important.
So
the
the
feature
compatibility
hazard
here
right,
someone
could
write
an
imple
of
from
some
specific
type
40
right
and
that
that
would
conflict
and
in
fact
we
want
people
to
do
so
for
their
air
types
right
and
that
that
would
conflict
with
the
imple
of
from
bang
for
any
type
right.
E
The
sort
of
trick
here,
which
is
the
thing
that
I
was
suggesting,
is
that,
since
from
bang,
has
the
imple
has
one
associated
item
which
is
a
function
and
that
function
takes
as
an
argument,
an
uninhabited
type.
You
know
that
all
implementations
of
from
bang
or
for
any
type
of
must
be
equivalent
because
they're,
all
just
the
those
function
bodies
are
all
unreachable
and
uninhabited.
But
obviously
that's
like
not
obvious,
or
maybe
not.
Obviously,
that's,
not
obvious,
and
so
I
think
there's
like
reasonable
cause
for
objection
to
just
doing
this.
E
C
D
F
C
F
B
A
B
It's
a
temporary
I
mean.
B
A
F
E
B
E
E
E
C
E
Them
the
most
common
thing
that
you
want
to
do
with
never
type
is
say
that
it's
something
else
right.
So
a
common
example
is,
if
you
have
like
a
a
result
that
returns
a
type
that
returns
a
function
that
returns
results
where
the
error
type
is
bang.
You
want
to
be
able
to
use
question
mark
on
that
and
have
it
like.
Did
the
error
type
just
disappear
and
that
only
works
if
the
any
error
type
that
your
function
could
have
is
convertible
to
from
bang?
Oh
I
see
where
the
very
type.
C
E
F
E
That's
not
actually
enough
and
the
reason
and
I
and
I
can
go
into
the
specifics
of
why
that
doesn't
work
out,
but
but
basically
a
lot
of
the
types
that
you're
talking
about
here
like
or
wind
up
in
generic
context,
where
they're
working
with
a
type
that
is
like
specifically
something
that
can
be
converted
into
a
stood
I/o
error
or
something
like
that
or
a
type
that
can
be
converted
into
you,
know
some
other
specific
air
type.
When.
F
B
B
A
F
F
G
F
E
So,
actually,
actually
Scott.
That's
a
good
thing
to
point
out
is
that
technically
today,
if
somebody
did
have
this,
if
somebody
was
doing
this
negative
reasoning
to
see
that
core
convert
infallible
with
oh,
but
they
can't
because
core
convert
infallible
is
defined
inside
the
standard
library,
and
so
they
can't
have
that
negative
reasoning
about
it,
because
somebody
might
add
that
from
a
mental
I,
never
I
take
it
back
with.
A
F
They're,
not
you
don't
not
if
they
have
to
assume
that
this
not
a
fancy
backward
before
competitive,
like
is.
This
were
compatible
with
adding
from
like
I
wrote
from
bang
for
my
effort,
then
that's
the
kind
of
code
I'll
be
broken
by
adding
from
bang
for
ki,
accept
modulus,
visualization,
cetera
well,.
A
A
E
Yeah
I,
don't
know,
saw
but
I
just
wrote
some
code
about
the
core
convert
and
Val
infallible
case.
Where,
like
like
you,
you
can
do
the
same
thing
with
court
convert
and
rot
infallible
today.
So
if
anyone
is
doing
that
and
then
we
made
core
convert
infallible
equivalent
to
bang,
we
would
be
breaking
that
code.
I,
don't
know
how
many
people
have
actually
done
negative
reasoning
based
on
the
fact
that,
like
yeah.
F
E
A
F
A
E
A
E
A
B
E
F
What
is
sort
of
the
like
thing
that
does
work
that,
like
maybe
people,
have
to
write
a
from
banging
pool
for
the
error
if
they
want
to
convert
a
bang
into
their
error
type
like
instead,
we're
like
talking
about
adding
hacks
and
like
delaying
everything
right
now,
it's
been
years,
and
it
just
feels
like
the
alternative,
is
the
absolute
worst
case.
I
agree
with
I
hear
you.
C
One
of
the
concerns
like
as
I
understand
it.
There
is
if
people
write
the
from
imple
themselves
and
then
we
figure
out
a
generic
way
to
say
you
can
always
convert
Bank
to
anything.
Do
those
two
things
conflict
yeah
way
to
make
them
not
conflict?
Then
we
could
go
ahead
and
release
now,
while
we
sort
out
how
to
make
that
generic
implementation,
but
if
we're
not
confident.
E
E
F
We're
only
blocking
the
negative
reasoning
and
you
can
still
implement
from
bang
for
your
own
types
and
I.
Think
that's
fine,
I,
don't
think
this,
like
I'm
an
optimist
whatever
having
a
specialization
I
mean.
E
E
F
E
E
B
E
B
A
B
A
That's
fine
I'm,
happy
with
that
yeah,
but
I
yeah,
okay,
I'm
happy
with
that,
but
I
feel
like
I
would
probably
be
happier
with
the
funding.
So
I'm
wondering
the
last
question
I'm
asked
is:
what
would
it
take
to
make
us
feel
sufficiently
confident
that
we
would
have
some
like
is
a
route
to
getting
this
central
that
we,
the
only
route,
is
that
we
have
a
stable
path
or
we
feel
like
there's
something
with
sufficient
probability
that
we'll
have
a
path
to
justify
it.
Non-Food.
B
E
A
C
E
F
A
B
E
B
A
A
Right
I
mean
the
the
short
version
is
that
we
can
have
we.
We
have
a
rule.
We
say
that
din
Phu
Phu
and
we
have
a
rule
that
sort
of
prevents
you
from
writing
very
simple
impulse
like
this.
However,
that
rule
is
not
especially
smart
and
you
can
create
more
complex
impulse
that
will
kind
of
bypass
it,
for
example
this
and
in
fact
we're
kind
of
relying
on
this
and
the
compiler
I
found
on
there
anyway
do
some
more,
but
it's
annoying
so
this
would
be
like
now.
The
problem
is
this:
in
pull.
A
B
A
B
D
E
A
E
F
D
F
A
C
A
D
A
You
kind
of
you're
saying
here:
Ariel
is
basically
like
abandoning
gay,
essentially
there's
two
varieties
of
you
can
write
an
input
by
hand
for
your
tintype
if
you
like
otherwise
like
so
that's
how
I
understand
that
you
could
write
the
simple
by
hand
if
you
like
or
indirectly
and
you're
allowed
to
do
that.
But
if
you
do
it,
then
you
don't
get
the
automatic
involve.
Essentially
it.
B
I
am
I
also
live
in
detail.
The
able
fire
to
gain,
but
so
the
one
thing
I
think
would
be
good,
is
that
we
like
to
test
out
intuitions,
since
there
seem
to
be
different
solutions
that
are
workable
and
find
out
how
much
we
break
and
how
much
it
would
affect
lines
and
stuff
so
because
otherwise,
it's
so
hard
to
decide.
But
now,
which
is
better.
B
A
One
thing
I
might
apply,
am
I
am
I,
correct.
I.
Think
I
could
correct
to
say
that
if
you
had
an
Impala
in
pull
of
foo
for
didn't
you
for
all
possible
instantiations
or
even
not
for
all
possible,
actually,
then
in
a
sense
that
that
could
make
the
treat
object
safe,
even
if
it
wouldn't
otherwise
be
like
this
might
replace
the
wear.
Self.Size
tack,
the
idea
would
be
essentially
I
write.
A
B
F
F
But
I
think
well
I
think
that
what
you're
describing
where
you
could
not
have
to
wear
self
sighs
things
seems
obviously
awesome,
but
that's
narrowing
to
like
what
you
want
to
dispatch
the
like
sabi,
safe
methods,
or
at
least
the
probably
the
unprovided
methods,
at
least
to
the
me
table.
It's.
A
That's
the
thing
you
have
to
add
back,
or
else
you
can't
do
it
that
you
have
to
have
some.
It
makes
the
language
you
could
be
done
as
a
future
step.
I,
don't
know
if
it's
a
good
idea
or
not,
but
I'm,
not
crazy
about
the
worst
self
sighs
time.
You
basically
have
another
kind
of
call.
You
know
it's
not
a
right
now,
we're
out
the
vtable
method,
sort
of
through
a
special
magic
imple.
This
would
be
that
you
want
to
route
them
through
a
special
there's.
Just
like
their
like
an
inherent
method.
F
D
B
A
B
F
F
A
A
E
Alright,
it
seems
like
sometimes
zoom
just
decides
that
I
don't
get
to
be
hurt.
I
was
just
gonna,
say,
I
kind
of
want
to
push
back
against
the
idea
that
we
want
to
make
fewer
things
object
safe
or
that
we
like
would
get
rid
of
object
safety
somehow
and
make
it
always
manual.
I
feel
like
there's
already
enough
sort
of
punishing
that
we
do
have
rust
users
trying
to
use
a
dynamic
dispatch
and
I
feel
like
adding
more
things
to
that
list
would
be
bad.
F
C
B
C
B
C
C
A
B
A
A
D
A
D
A
A
Maybe
I
mean
there's
a
lot
of
context
to
supply
I
think
we
don't
think
we're
there
yet,
since
you
should
probably
investigate
first
her
but
like
you
should
at
least
doing
some
of
the
groundwork
yeah,
let's
ping
skill
exam
tomorrow
or
later
today,
and
see
what
they,
what
they
think
I
think
what
needs
to
be
done
right
now
is
to
write
up
in
more
detail.
What's
been
said
here,.
B
C
B
B
A
A
C
C
There
is
an
issue
where
certain
C
libraries
have
error
handlers
that
are
effectively.
We
call
abort.
If
you
return
from
this
error
handler
and
the
expectation
was
always
Oh
print
some
messages,
you
can
either
print
some
messages
and
then
abort
or
you
can
long
jump
up
past
the
library
code
back
into
your
own
code
and
that's
how
you
get
to
keep
going
if
they're
sales.
C
One
of
the
examples
of
this
is
loop
jpg,
for
example,
where,
if
you
have
an
error,
parsing
a
jpg,
then
you
get
to
long
jump
out
of
JPEG
in
order
to
not
crush
your
whole
save
browser
window
because
you
failed
to
parse
an
image.
This
is
a
lovely
historical
artifact
of
see,
error
handling
it
that
we
said
we
have
to
cope
with
and
in
rust
people
handled
this
by
using
panic
as
effectively
long
jump,
they
would
do
a
panic
inside
their
error
handler.
Allow
that
to
unwind
BC
code.
C
In
live
JPEG
and
then
catch
that
panic
in
the
rust
code
that
called
live
JPEG
and
they
didn't
make
any
assumptions
that
live.
Jpeg
was
still
usable
in
that
context
or
that
it
didn't
have
a
bunch
of
screw
age
inside
its
internal
state,
but
then
they
could
unwind
it.
That
does
require
you
to
carefully
build,
live
JPEG
with
unwind
it
hooks
and
similar
with
the
right
compiler
options,
but
it
can
be
made
to
work.
The
problem
with
this
is
that
LLVM
has
a
flag,
no
unlined.
C
It,
which
is
I
promise
not
to
unwind
past
dysfunction,
and
we
currently
declare
all
extern
C
functions
with
that
flag,
which
means
they
can
be
Mis
optimized
as
assuming
that
they
will
never
have
a
panic
propagate
past
them.
At
one
point,
we
actually
tried
to
fix
this
by
making
it
so
that,
if
you
unlined
past
a
an
extern
c
function,
we
would
abort
rather
than
unwinding,
and
this
ran
headlong
into
this
broke.
People
likely
web
users
of
jim
live
jpeg.
C
Everybody
involved
understands
that
there
was
undefined
behavior
here
and
that
there
is
a
problem
and
that
the
last
time
people
tried
to
push
this.
It
got
reverted,
but
there
was
a
feeling,
like
nobody
made
any
forward
progress
on
it.
So
this
time
around
that
we
effectively
said,
let's
revert
it
again,
but
let's
put
a
12-week
deadline
on
making
some
kind
of
forward
progress
to
actually
solving
the
problem,
and
if
we
don't
make
any
forward
progress,
then
we'll
just
declare
it
as
we're,
not
reverting
it
again
and
deal
with
it
fix
it.
C
Nobody
set
forward
to
fix
the
problem
so
that
had
the
intended
effect,
people
stepped
forward
to
try
to
fix
the
problem
and
to
write
a
real
RFC.
That
is
here's
how
to
make
a
function
not
get
marked
as
no
unlined
it.
Here's
how
to
deal
with
panics
that
has
currently
got
caught
up
in
a
fair
bit
of
detail
about.
Well,
what
does
it
mean
to
unwind?
What
about
different
panic
runs
and
what
about
exceptions?
C
How
does
this
interact
with
C++
exceptions
and
running
destructors
on
the
way
out,
if
Emily,
making
the
gold
armor-plated
solution
that
solves
every
use
case,
and
it
has
gotten
somewhat
distracted
from
the
problem
of?
We
need
to
not
put
no
unwind
on
these
functions
or
we
have
undefined
behavior
so
we're
trying
to
get
that
back
on
track.
There's
a
lot
of
discussion
of
what
is
the
minimum
needed
to
solve
the
problem
and
fix
the
undefined
behavior,
but
in
the
meantime
the
deadline
came
up
and
there
is
some
desire
to
just
say:
well
the
deadline
passed.
C
So,
let's
reapply
the
change
and
or
rather
the
change
was
only
ever
done
and
reverted
in
beta,
and
so,
if
do
nothing,
then
we
go
back
to
aborting.
If
you
try
to
unwind
through
FFI
and
existing
code
breaks,
and
if
we
merge
this
6
to
5
in
beta,
then
we
defer
it
another
six
week
release
and
allow
time
for
the
RFC
to
find
its
way
through
the
process
and
figure
out
what
it's
doing.
I
personally
would
recommend
that
we
merge
this
because
forward
progress
is
being
made.
C
C
B
B
C
That
I
think
the
pressure
had
the
intended
effect
of.
We
need
to
actually
make
forward
progress
and
I
think
now
that
there
is
a
live
RFC
that
is
being
actively
worked
on
then
until
that
gets
dropped.
Unless
that
gets
dropped
on
the
floor,
I
think
we
have
forward
progress
going
on
and
the
pressure
is
now
more
generating
stress
in
trying
to
actually
work
on
the
RFC.
So.
B
A
C
C
Could
we
just
add
the
simplest
possible
attribute
that
turns
off
lob
M's,
no
unwind
on
a
function
and
then
follow
the
whole?
How
does
panic
interact
with
other
things
later
and
for
now
leave
it
with
if
you're
doing
this
you'd
better
know
what
you're
doing
with
respect
to
building
your
C
code,
with
the
ability
to
be
unwound,
some
undefined
behavior,
but
I'm
wondering
if
that
might
make
people
a
little
bit
less
stressed
about
the
fact
that
we
are
kicking
this
down
the
road
another
six
weeks.
It's.