►
From YouTube: 2021-02-16 Lang Team Triage
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
Okay,
it's
being
recorded
so
welcome
to
the
triage
meeting,
and
I
think
this
list
is
not
complete.
Oh
good,
there
you
go
scott.
I
think
there
are
more
names
too,
if
you
haven't
put
your
name
in
here,
put
your
name
in
here
and
let's
go
down
so
in
terms
of
action
items,
we're
actually
doing
pretty
good.
I
paired
this
list
down.
A
A
A
A
Okay,
well,
better,
even
better
all
right
awesome,
so
ad
hoc
project
updates.
So
I
this
is.
I
wanted
to
find
a
better
procedure
for
this,
but
we're
doing
our
like
main
check-ins
in
the
once
a
month
meeting,
but
just
like
you
can
nominate
issues.
If
groups
have
things
they
want
to
bring
up
ad
hoc,
I
think
that's
fine,
for
so
I
scraped
a
few
that
have
come
up.
One
thing
is:
there's
a
draft
rfc
for
the
declarative,
macro
repetition
count:
I've
read
it
over.
I
think
it
looks
pretty
good.
A
I'm
inclined
to
have
them
open
it
on
the
main
rfc
repo,
but
I
wanted
to
get
people's
temperature
if
they
want
to
take
a
look
first
or
something
else
before
I
suggest
it
that
they
do
that.
C
You
feel
like
it
is
ready
to
post
and
doesn't
need
any
further
direction
checks.
First,.
A
A
Anyone
have
a
concern
about
that:
okay,.
D
A
C
Previously
we
discussed
whether
this
was
ready
for
stabilization
and
I
checked
with
the
group.
There
is
a
comment
that
I
linked
in
the
document
that
gives
the
list
of
what
needs
to
happen
first,
and
it
gives
here
are
the
things
that
must
happen
before
stabilization,
and
here
are
things
we'd
like
to
fix
before
stabilization.
A
C
Is
right
plan
still
to
post
a
pr
for
each
proposed
length.
A
Yes,
I
think
those
pr's
are
mostly
posted,
but
I'm
not
sure
okay,
but
also,
I
think
I
guess
one
other
point
was
there
was
some
confusion
around
whether
we
would
include
all
future
compatibility
warnings
or
just
migrations,
and
my
my
opinion
is
that
future
compatibility
warnings
are
called
that
because
we're
we're
not
using
an
addition,
we're
breaking
like
we're,
we're
making
the
change
for
all
editions
and
so
they're
not
part
of
this
process.
A
We
should
probably
be
tracking
those
and
and
closing
them
out
on
a
timely
basis,
although
I
think
there
might
be
more
compiler
teams
job,
but,
although
I'm
not
sure,
but
it's
not
part
of
the
migration
like
it
does
at
least
not
by
default.
Maybe
we
might
pick
one
and
say
instead
of
doing
a
future
compatibility,
we
want
to
do
it
as
an
addition.
Change,
that's
fine!
A
You
know
there
might
be
some
value
in
like
making
on
the
addition
change
to
like
make
someone
be
hard
hardware
on
the
edition
change.
Just
avoid
you
know
further.
What
do
you
call
it
propagation
of
the
you
know.
I
mean.
C
A
Hard
error
everywhere,
if
we're
gonna
like
I,
I
would
be
okay
with
yeah.
I
think
the
default
should
be.
If
we're
making
it
a
future
compatibility
warning,
then
it
should
be
denied
by
default
everywhere
and
go
to
hard
error
if
we
want
to
do
it
on
an
addition.
Boundary
that's
okay
too,
but
it
would
be
more.
The
exceptional
case.
A
C
C
Because
I
think
the
term
future
compatibility
warning
is
used
more
broadly
than
that
and
people
talk
about.
Oh,
let's
add
a
future
compatibility
warning
for
xyz
when
it's
not
necessarily
a
soundness
thing
right.
So
we
could
clarify
that
if
it
is
in
regards
to
a
soundness-based
transition
of,
we
need
to
break
this,
but
we
need
to
give
people
time
then
by
all
means
I
do
think
we
should
fix
it
everywhere,
but
we
don't
want
to
imply
that
that's
true
for
everything
that
somebody
might
refer
to
as
a
future
compatibility
warning
yeah.
Maybe
we
should.
B
Sound
because
yeah,
like
name
resolution,
is
one
example.
Another
one
is
like
adding
trade
impulse
for,
like
the
like
by
value
arrays,
for
example,
implementing
like
into
iterator
like
things
like
that,
where
it's
like
we're,
gonna
break
a
lot
of
user
code
with
an
actual
change.
It's
not
directly
soundness
related,
but
it
is
something
that's
gonna
break
user
code
and
is
within
our
like
stability
allowances.
A
If,
like
stability
warning,
I
don't
know
well,
we
can,
let's,
let's
brainstorm
a
better
name
and
branding
off
off.
A
I
guess
I'm
still
not
quite
understanding
the
art.
Well,
we
can
talk
about
this
as
a
synchronous,
maybe
new
9
eco.
I
just
I'm
not
100,
convinced
that
if
there's
not
some
value
in
saying
look
edition,
boundary
is
a
place
where
you
know
this
is
new
code
in
some
sense,
either
some
migrating
old
code
or
just
literally
a
new
project
and
there's
to
me,
I
see
some
value
in
saying
for
new
code.
A
We
can
put
in
the
stricter
thing
that
we
that
we
want
anyway,
it's
only
because
of
this
backwards
compatibility
support
that
we
have
future
compatibility
warnings.
That's
to
me
that
to
me
is
the
argument
for
why
it
makes
some
sense
to
tie
a
phased
introduction,
a
phase
shift
with
the
addition
boundary.
C
A
We
might
understand
it
well
all
right,
let's
talk
about
it
after
I
I
see
your
point
felix
I
mean
I'm
thinking
about
like
how
we
phased
in
nll.
Certainly,
additions
are
sometimes
useful
as
a
way
to
yeah.
That's
a
that's
a
particular
special
case,
because
we
definitely
use
the
we
definitely
leveraged
the
edition
there.
For
various
reasons,
I
don't
know
if
it
quite
fits
in
all
their
cases,
even
though
I'd
love
to
claim
it
is
an
example
of
what
I'm
trying
to
argue
for
well
yeah.
A
Was
because
it
fixed
a
bunch
of
bugs
right
and
we
didn't
want
to
break
people's
code,
so
we
did.
I
think
we
also
leveraged
it,
in
my
opinion,
to
try
to
advertise
the
addition.
As
being
this
amazing
thing.
That'll,
let
you
do
this
awesome
new
thing.
It
was
a.
It
was
a
promotional
gimmick,
in
my
opinion
as
well.
Maybe
that's
not
fair,
yeah.
Okay,
I
don't
know.
A
A
True,
anyway,
yeah
enough
about
this
sorry,
we'll
keep
going
I'll
come
back
to
that,
then
we'll
talk
a
little
bit.
The
main
reason
I
bring
this
up
is
that
there
was
a
much
longer
list
if
we
include
all
future
compatibility
warnings,
but
so
all
right,
pending
proposals,
we've
been
talking
about
this
duref
patterns
thing
and
last
time
we
talked
about
it.
We
said
that
we
should
exclude
draft
pure.
A
There
was
a
comment
made
to
that
effect,
and
I
think
the
question
I
have
is,
or
first
off
the
people
in
the
thread
asked
how
we
feel
about
special
casing.
Particular
types,
in
other
words
like
the
compiler,
might
very
well
just
know
the
box
is
draft
pure,
which
is
how
the
borrow
checker
treats
it.
For
example,
I
think
it
seemed
like
there
was
still
interest
in
pursuing
some
work
here,
even
if
it
doesn't
work
with
all
pointer
types.
You
know
exhaustive
like
if
it
doesn't
integrate
with
exhaustiveness.
A
D
I
think,
to
some
extent
I
would
not
want
to
open
the
door
in
the
sense
that
I
think
that
there
is
complexity
that
doesn't
like
doing
it
at
all
adds
a
significant
amount
of
complexity
compared
to
not
doing
it,
regardless
of
what
types
are
allowed,
but
I
think
I
I
would
personally
be
interested
in
seeing
sort
of
how
much
complexity
there
is,
and
that
really
needs
a
proposal.
So.
E
It
seems
to
me
like
having
the
one
special
case
for
box
is
different
from
having
a
bunch
of
special
cases
in
the
standard
library,
because
at
that
point
it
feels
like
it's
getting
implemented.
It's
just
not
getting
stabilized.
A
Yeah
box
is
already
specialized
in
the
borrow
checker
too,
and
that's
unstable,
so
there's
a
good
argument
for
being
like
we're
already
committed
to
special
casing
box
or
we're
already
committed
to
box
either
always
being
special
case
or
having
some
rationalization
of
it.
But
if
we
add
additional
impulse,
it
gets
worse
well,.
A
For
standard,
though
right
like
don't,
we
allow
it
for
self
types
or
something
like
that.
I
think
some
of
the
pin
stuff
is
specific
too.
A
Yeah
also,
we
have
a
precedent
I
think
with
like
the
may
dangle
attribute
that
that's
only
available
instead,
but
it
definitely
adds
special
semantics,
for
you
know,
making
something
more
expressive
for
vec
and
other
collection
types.
So
yeah,
I
think
that's
you
know
this
sounds
similar
to
me.
E
A
A
Detail
at
that
point
right
agreed
there:
okay,
I'm
on
board
with
that.
The
main
thing
is:
if
we
say
that
rc
and
arc
get
this
like.
Basically,
you
would
be
adding
an
unstable
draft,
pure
that
is
not
designed
and
has
no
stabilization
path,
and
you
would
implement
it
for
rc
and
arc,
and
we
are
then
committed
to
that.
A
We,
you
know
either
that
it'll
persist
forever
or
that
we
come
up
with
some
like
some
rationalization
of
it,
which
I'm
kind
of
okay
with,
but
I
I
guess
I
think
in
the
long
run
it
doesn't
matter
if
if
we
do
box
rc
and
arc
or
just
box,
it's
about
the
same
complexity
either
way.
So
we
could
just
start.
D
A
A
A
I
think
that
would
just
work
in
the
sense
of
without
well,
I
mean
vec
would
be
something
that
could
implement
draft
pure.
That's
what
I
mean
that's
what
okay,
so
it
could
be
on
the
same
list
as
our
rc
arc.
The
same
way
yeah!
Okay,
yes,
but
that's
not!
We
wouldn't
necessarily
commit
to
that
right.
Now.
Okay,
it
seems
a
heck
of
a
lot
more
compelling
if
you
can
do
it
for
a
lot
of
types.
A
C
On
top
of
that,
part
of
the
point
of
this
original
proposal
was
to
reduce
the
degree
to
which
we
have
this
special
case
mechanism
for
box.
That
doesn't
seem
to
ever
be
on
a
path
to
stabilization
and
isn't
generalized
to
other
things.
A
I
mean
I'm
trying
to
look
what
are
the
alternatives
here?
Those
basically
limit
to
box-
and
what
taylor
is
pointing
out,
is
that
this
is
basically
the
box
pattern
right.
There's
some
form
of
draft
pure
of
perma
unstable
until
rfc'd,
the
ref,
pure
trait
or
attribute,
or
something
used
by
standard
library
types.
A
D
I
do
think
it
might
be
worth
noting
that
the
box
pattern,
at
least,
if
I
recall
correctly,
does
give
you
like
drift,
move
in
some
sense,
whereas
I
think
for
at
least
arc
and
rc,
it
seems
pretty
unlikely
that
we
would
want
that,
and
vec
at
least
also
seems
like
there
would
be
more
work.
We.
B
D
A
Yeah,
that's
correct,
so
I
kind
of
lean
towards.
If
we're
going
to
do
it,
I
think
we
should
do
some
sort
of
perma
unstable
draft
pure,
like
we
should
cut
out
the
attempt
to
design
that,
but
but
we
can
start
allow
it
as
an
implementation
detail.
C
You're
suggesting
that
you'd
be
able
to
do
dref
patterns
for
non-standard
library
traits,
but
that
you
would
then
have
to
have
an
underscore
or
similar,
because
you
can't
guarantee
exhaustiveness,
but
standard
library
types
would
be
able
to
opt
in
to
saying
no
really
I'm
exhausted.
I
can
do
exhaustive
patterns.
C
Yeah,
that
would
be
an
improvement
over
the
standard
library
types
being
the
only
ones
who
get
draft
patterns
at
all.
C
If
anyone
can
use
draft
patterns-
and
we
just
don't
yet
stabilize
the
mechanism
for
saying
I
am
sufficiently
pure-
that
you
can
de-ref
this
and
be
exhaustive,
that
would
be
better.
I
guess.
A
To
contra
me
that
adds
more
complication
in
the
sense
that
that's
sort
of
adding
more
precedent
for
random
code
running
during
pattern
matching
and
might
be
complex.
D
A
C
D
D
And
ultimately
it
feels
unclear
to
me
that
they
provide
enough
benefit
to
have
the
cost
of
allowing
sort
of
implicitly
supporting
the
idea
that
drf
pure
is
not
in
fact
pure.
A
I
agree
with
this
point,
though,
that
at
first
I
thought
I
didn't
quite
agree
because
I
thought
oh
from
an
implementation
perspective.
I
don't
think
it's
very
complex,
but
that's
not
the
point.
Both
it's
more
of
the
meant,
it's
more,
that
it
backs
up
the
idea
that
sort
of
makes
you
be
aware
that
draft
could
be
non-pure,
which
would
be
nice
if
you
don't
have
to
think
about,
and
it
also
does
introduce
this
sort
of
running
of
user
code
that
may
have
additional
complications.
D
A
Think
anyone's
going
to
want
to
use
it,
I
agree
it's
going
to
be
annoying.
It
seems
easy
to
explain
that
it
works
only
for
stuff
in
the
standard
library
yeah,
because.
D
D
And
I
guess
my
perspective
is
that
if
we
really
like
quote-unquote
need
an
underscore
pattern,
I
think
that
it
would
not
be
the
end
of
the
world
for
us
to.
You
know:
implementation
wise
if
you
implement
draft
pure
and
for
whatever
reason
we
realize
that
it's
not
to
either
just
say
that
that's
undefined
behavior
or
to
compile
to
like
a
you
know,
unreachable
instruction
or
whatever
that
just
aborts
your
program.
A
D
A
E
A
B
A
D
A
The
charter
issue:
okay,
let's
move
on
because
we're
taking
longer,
but
that
was
useful.
Oh,
let
me
put
an
action
item.
I
will
say
I
don't
mind
niko
to
post
this,
since
I
wrote
up
the
proposal
unless
someone
else
wants
to
scott,
were
you
interacting
with
this
group?
Actually
you
were
sucker.
A
But
I
think
I
think
I
could
do
this
nico
if
you
have,
if
you're
too
busy.
No,
I
I
I
don't
think
I'm
too
busy.
Sorry,
okay,
it's
not
I'm
not!
I
don't
think
it's
very
long.
Okay,
so
there's
there's
a
there's.
A
oh
right!
There's
a
nominated
rfc
here
add
const
ub
rfc.
I
don't
really
know
oops,
I'm
trying
not
to
do
that
anymore.
I
don't
really
know
why
it's
nominated,
probably
because
it's
at
some
point
I
asked
ali
about
it
on
on
zulip.
A
All
right,
let's
revisit
it
next
week,
we'll
just
leave
it
nominated
for
now.
A
Pink
felix
to
request
since
you've
volunteered
yourself
to
request
a
summary
of
why
this
is
nominated,
so
try
trait
version,
two
scott,
I
think
the
action
name
here
is
everyone
should
read.
This
is
that
right.
E
A
All
right,
let's
move
on
change,
visibility,
scoping
rules
so
right
so
there's
some
exploration
work
here
happening.
This
is
the
thing
about
introducing
pub
macro
rules.
I
think
the
biggest
unknown
is.
Can
we
target
this
edition
and
how
feasible
are
the
migrations?
There's
a
little
bit
of
exploration,
work
happening,
I'm
inclined
to
say
we
should
merge
the
rfc
and
leave
some
leave
that
as
an
unresolved
question.
A
Assuming
people
are,
you
know
in
favor,
I
don't
know
if
anyone
has
like
if
enough
people
have
read
it,
I
could
summarize
what
it
says.
I
could
make
an
rfc
bot
fcpd.
I
don't
know.
C
I
would
propose
that
you
fc
pro
that
you
use
rfc
bot
for
this.
I
would
be
in
favor
of
merging
this
exactly
as
is,
and
having
the
exact
transition
time
being
an
open
question
whose
primary
determining
factor
is:
how
quickly
can
we
get
this
in.
A
I
think
off
now
I'm
realizing
I'm
I'm
not
tell
me
if
you
think
I'm
wrong
josh,
I'm
99
sure
should
have
written
a
summary
from
the
text
that,
what's
proposed
here
is
add
pub
into
all
editions
applied
to
macro
rules
right.
This
makes
them
behave
like
regular
items
and
then
change
the
default
behavior.
A
With
no
pub
is
a
private
item
like
a
regular
item,
and
this
requires
migration
and
addition,
the
open
question
is
yeah.
What
is
addition
and
and
can
the
like?
How
well
does
the
migration
work?
A
There
are
a
few
there's,
a
few
weird
edge
cases,
but
there's
one
weird
edge
case
around
like
recursive
macros,
where
people
generate
macros
that
generate
helper
macros
and
then
rely
on
macro
shadowing
to
like
disambiguate,
which
helper
macro
they're.
Invoking,
because
they'll
be
multiple
with
the
same
name,
and
I
don't
know.
D
A
I
I
think
it's
quite
possible
that
that's
not
something
we
have
to
be
able
to
automatically
manage,
but
I
would
like
to
be
able
to
tell
them
what
to
do
sure,
and
I
don't
know
that
we
have
an
answer
and
that's
a
bit
of
a
problem.
A
C
A
A
And
the
pattern
might
be
something
like
making
a
sub
module
and
using
a
pub
use,
for
example,
I
don't
know
not
sure
if
that
actually
works,
but
it
might
work.
A
I
haven't
really
thought
about
it
anyway,
so
I
guess
the
question
is
given
this
summary
and
this
open
question:
is
it
okay?
If
I
propose
fcp
or
does
people
want
time
to
read
it
and
think
about
it?.
D
A
D
Yeah,
I
don't
care
about
a
migration.
I
think
I
care
about
either
a
we
say.
You
know,
maybe
there's
a
attribute
or
something
you
stick
on
macro
rules.
That
basically
says
I
opt
into
the
old
behavior
and
yes
shrug
or
you
know,
maybe
we
can
design
something
that
actually
does
work
with
the
new
semantics.
A
A
A
D
So
my
my
high
level
understand
there's.
Actually,
I
think
a
couple
issues
at
this
point
that
are
similarly
titled
is
that
there
are
some
c
compilers
that
have
different
rules
for
what
structs
and
unions
and
enums
and
whatnot
like
what
their
layout
is,
and
so
in
theory,
if
you
attack
something
repress
c
and
rust,
and
then
you
use
that
c
compiler,
they
will
disagree
and
you
know
that
potentially
causes
sort
of
unsoundness.
D
D
Right,
yeah
or
potentially,
my
understanding
is
that
even
the
c
compilers
don't
agree
so
like
msc
versus
newer,
msc
and
clang,
don't
necessarily
agree
on
all
sort
of
esoteric
definitions
of
structs
and
unions.
So.
A
D
It
msvcc
yeah.
I
guess
that's
true.
I
think
one
thing
that
I
was
not
clear
on
based
on
the
thread
is
whether
there
is
potentially,
obviously
if
we
change
things
or
stability
implications,
I'm
not
clear
to
the
extent
to
which
we
sort
of
know
whether
people
are
actually
using
this
sort
of
thing
or
if
it's
you
know,
someone
accidentally
discovered
it
while
reading
the
c-spec
or
something.
A
Does
it
seem
like
this
is
the
domain
of
the
compiler
team
to
resolve
this
in
terms
of
the
target
between
the
target
triple
issue
or
the
compiler
flag?
Being
the
right
answer
here,
I
think
this
is
really
a
compiler
team,
so.
C
There
is
a
one
specific
aspect
that
I
think
is
important
for
t
lang
to
chime
in
on,
and
then
we
could
absolutely
punt
the
rest
of
it
over
to
this
is
a
bug
in
the
compiler.
Please
address
it.
The
item
that
the
lang
team
needs
to
address
and
definitively
state
is
what
we
intend
the
behavior
of
rapper
c
to
be
the
debate
in
the
comments
and,
let's
not
get
into
the
degree
to
which
that
debate
has
turned
rapidly
or
sour.
C
But
the
debate
is
effectively
is
rapper,
see
a
defined
layout
that
applies
everywhere
or
is
represent
defined
to
be
compatible
with
the
target
use
of
the
c
compiler
for
that
target,
and
I
believe
the
definition
has
always
been.
The
latter
represent
operates
with
the
default
c
compiler
abi
on
the
target,
and
that
is
not
quite
what
the
rust
reference
says,
or
at
least
the
rest.
Reference
could
be
interpreted
differently
because
it's
trying
to
define
what
represent
does
without
just
punting
to
the
target,
and
it
is
doing
so
incorrectly.
E
So
I
think
it's
interesting
that
there's
stable
standard
library
apis
whose
documentation
describes
representable.
E
Sorry
in
the
thread
they're
talking
about
repper
stable
being
the
version
of
what
layout
extend
for
example,
says
that,
in
order
to
match
the
representation,
you
should
call
pad
to
a
line
after
blah
blah
blah
blah
blah,
because
it's
just
the
having
something
that
doesn't
change
between
rust
versions.
A
C
Wondering
it's
not
interoperable
between
targets
already
today
and
that
can't
really
change
just
because
how
it
lays
out
a
structure
will
depend
on
the
alignment
requirements
of
types
on
that
platform
and,
for
example,
there
are
platforms
that
say
that
the
alignment
requirement
for
a
64-bit
value
is
64-bits
and
platforms.
That
say
that
the
alignment
requirement
for
a
64-bit
value
is
32-bits.
A
A
Yeah,
I
guess
what
I'm
saying
is
that
that
seems
like
what
I
expected.
What
I'm
wondering
is
is
what
are
the
things
where
this
feels
like
the
kind
of
decision
where
you
you
make
it,
and
then
you
you
find
out
later
that
there
were
other
places
where
you
were
assuming
the
former,
and
I
guess
one
example
would
be
the
standard
lib
documentation.
I'm
wondering
if
there
have
been
other
examples
of
like
oh
turns
out.
Sometimes
I
meant
a
like
turns
out.
C
C
C
The
latest
c
standard,
but
I
don't
know.
C
There
is
actually
one
other
question
that
has
come
up
that
isn't
just
rep
c.
There
is
also
some
issue
of
enum
sizes
and
whether
those
enum
should
grow
to
fit
or
whether
you
have
to
specify
exactly
what
size
they
are
and
should
match.
C
A
C
A
C
C
would
do
well.
I
think
there
may
be
two
answers
on
this.
One,
for
what
c
would
do
c
may
potentially
error
on
this
or
it
may
just
overflow,
depending
on
the
compiler.
You
may
get
a
warning
if
you
are
building
an
enum
with
too
large
of
a
discriminant,
but
in
this
case
it
sounds
like
it
would
just
silently
get
bigger.
A
I
remember
like
we,
we
put
a
lot
of
back
in
the
day.
This
was
a
hot
design
topic
and
I
remember
us
yeah
like
that.
Anyway,
I'm
sure
we
didn't
investigate
every
compiler,
but
many
of
them
grew
and
that's
why
we
had
an
explicit
option
to
to
say
the
size,
or
else
it
was
like
big
enough
to
fit
or
whatever,
but.
D
C
A
A
D
Yeah
and
it
doesn't
necessarily
have
to
be
like
super
exhaustive,
but
I
guess
my
worry
is
that
if
you
know
we
hand
down
in
some
sense
this
decision,
I
think
a
reasonable
question
is
like
who
decides
right
like
for
some
targets,
it's
in
the
name,
but
in
some
others
it's
not
and
potentially
there's.
You
know
open
questions.
D
Some
arm
targets,
you
know,
maybe
there's
a
proprietary
tool
chain
that
does
one
thing
and
ninety
percent
of
people
who
use
that
target,
use
that
tool
chain
and
then
there's
clang
and
plane
does
a
different
thing.
Sure
for
whatever
reason
and
sort
of
it
comes
down
to
us
or
someone
right
to
say,
you
know
either
we're
going
with
clang
or
with
that
proprietary
compiler,
potentially.
A
And
that
josh
that
reminds
me
of
the
trc
which
side
note.
But
okay,
who
wants
to.
C
So
unless
anybody
has
objections,
then
the
summary
I
was
going
to
make
was
repper
c
is
intended
to
match
the
default
cabi.
If
it
doesn't,
then
that's
a
bug
and
should
be
fixed,
and
if
the
reference
describes
it
differently,
the
reference
should
be
fixed
and
that
we
would
like
to
see
documentation
for
rep
c,
linking
to
appropriate
definitions
for
c
structure.
Layout,
avis,
okay,.
C
E
E
Okay,
would
we
this
is
sort
of
the
same
as
what
you
just
said,
but
would
we
be
interested
in
a
api
that
is
defined
like
the
layout
type
in
the
standard
library
is
defining
it
be
like?
It
only
looks
at
the
size
and
the
alignment
of
the
fields
and
lays
them
out,
in
definition,
order
as
a
predictable
layout.
E
So
I'm
trying
to
figure
out
if
some
of
these
people
wanted
a
wrapper
that
gives
them
a
offsets
that
they
can
predict
or
if
they
all
wanted
exactly
matches
c.
C
Yeah
that
would
need
an
rfc
it's
an
interesting
idea,
but
it
would
also
need
use
cases
for
why
do
you
need
something
that
matches
right?
I
mean
so
to
clarify
that.
That's
something
that
if
we
were
going
to
go
that
far,
we
might
ask
is
the
purpose
to
build
something
that
has
the
same
abi
on
all
platforms.
C
For
example,
whether
u64
has
four
byte
or
eight
byte
alignment.
We
lay
out
the
structure
always
the
same
way
so
that
you
can
serialize
and
deserialize
it
to
a
file
across
platforms.
C
A
All
right
sounds
good,
I
think
in
terms
of
the
reference,
I
guess
it
seems
like
the
documentation
can
just
be
slightly
weakened
or
something
but
all
right,
let's
see
if
we
can
get
through.
I
didn't
get
to
summarizing
all
these
we've
only
got
a
few
minutes
left,
but
there
was
a
proposal
to
deprecate
weird
nesting
of
items
hyper
like
meaning
things
impulse
inside
functions
and
so
forth
around
the
edition.
A
I
basically
think
we
should
just
add
a
warning
at
some
point
and
we
don't
have
to
tie
this
to
the
edition.
I
don't
want
to
put
a
lot
of
energy
into
into
this.
E
A
A
I
do
think
there's.
I
guess
I
guess
I
would
say
we
could
add
a
warning.
I
wouldn't
mind
having
a
rfc
like
either
an
rfc
or
at
least
an
fcp
on
whether
to
do
so,
because
it
is
kind
of
a
useful
pattern
that
is
widely
used.
I
think
not
super
widely,
but
widely
in
maybe
the
right
words
not
widely
but
deeply
like
some
people
use
it
a
lot.
E
Like
the
weirdest
ones
of
an
inherent
impul
for
a
struct
defined,
not
inside
a
function,
but
the
inherent
impul
is
inside
a
function.
A
E
Taylor
had
a
good
point
about
like
it's
sort
of
coherence
at
scopes
or
something.
B
A
Enough,
what
about
that
offline,
okay,
unsafe
up,
there's
no
action
item
here!
This
is
in
fcp.
I
think
also
there
was
there's
no
action
item
here.
This
just
needs
to
be
unnominated.
Maybe
I
already
did
it.
This
is
the
we
all
we
already
agreed.
We
want
unsafety
checking
to
work
lexically
and
we're
just
working
on
the
implementation,
allow
qualified
paths
and
struck
construction
or
pr8
0,
80,
880.
Sorry,.
A
D
Ryan
types
up
the
summary
we
were
asking
for
like
three
weeks
or
more
ago
now
and
then
I
got
lost
for
a
while.
I
can
there's
a
comment
on
january
14th.
I
can
paste
the
link
to
it.
I
guess:
okay,
you
got
it.
A
D
Yeah
it,
it
seems
pretty
unambiguous
to
me
in
terms
of
what
is
being
asked
for
that
this
seems
desirable,
but
I
don't
know
I
guess.
Maybe
we
should
just
have
fcp
martial.
A
It's
allow
specifying
a
line
alignment
for
functions.
What
happened
with
this?
We
talked
about
this
another
time.
A
C
Now
I
was
gonna
say:
do
we
feel
comfortable
that
it
will
not
just
kind
of
stagnate
because
we
haven't
given
a
definitive
answer?
If
we
don't
fcp.
C
A
A
Unstable
right,
oh
yeah,
it'll
immediately
start
right.
Sure
it
just
seems
right.
I
think
we
should
have
a
formal
decision
before
we
add
random
features,
update
we're
gonna,
stop.
We
almost
got
all
the
way
pretty
cool
next
time.
We'll
surely
do
it
thanks,
y'all
see
you
next
time.
Oh
yeah
yeah
see
you
tomorrow.
Perhaps
I
sent
out
some
notes
about
discussion
agenda,
but
there
you
have
it.