►
Description
RustConf 2016 - RFC: In Order to Form a More Perfect `union` by Josh Triplet
Users of Rust for systems programming rely heavily on its exceptional support for FFI. Many systems APIs involve unions, and macros and transmute produced unmaintainable solutions. 16 months, 3 RFCs, and a half-dozen possible syntaxes later, RFC1444 added union to the Rust language, ready for implementation.
This talk will present unions as a case study of the Rust RFC process, show the kinds of iterative refinements that take place, review corner cases and interactions that arise when attempting to extend Rust, and discuss the next steps forward for union implementation.
A
All
right,
thank
you
very
much
so
I
wanted
to
talk
today
about
not
just
the
specific
RFC
that
I'd
worked
on
of
providing
unions
into
the
language,
but
the
general
RFC
process
and
how
it
got
me
into
rust.
So
naturally,
I
want
to
start
with
talking
about
the
most
related
possible
topic
to
those
things
which
is
virtual
machines.
A
A
Yes,
that
is
a
scary
and
really
amusingly
useful
thing
to
do
as
long
as
you
remember,
the
snapshot
and
the
big
advantage
of
a
virtual
machine
is,
it
gives
you
containment,
okay,
I'll,
keep
going
and
we'll
see
how
things
go,
so,
yes,
containment
and
isolation,
which
would
be
useful
in
audio
systems
as
well.
So.
A
So
this
provides
a
form
of
sandboxing
and
you
can
use
it
for
a
variety
of
things.
You
can
use
that
to
not
just
sandbox
a
whole
system
in
a
box,
but
an
application
sandbox,
just
your
application,
running
alone
in
a
virtual
machine
or
an
arbitrary
piece
of
code.
So
virtual
machines
are
a
key
part
of
what
people
called
the
cloud
and
which
would
not
exist
without
a
very
robust
virtual
machine
infrastructure.
A
So
the
most
popular
thing
people
tend
to
run
for
virtual
machines
is
based
off
of
QEMU,
but
in
practice,
what
people
use
is
a
mode
of
QEMU
called
KVM
or
kernel
virtual
machine,
which
provides
hardware
acceleration.
So
this
allows
you
to
run
near
native
speed
virtual
machines,
there's
various
other
tools
based
off
of
this
things
like
KBM
tool,
which
is
more
of
a
sample
virtual
machine.
That's
easier
to
reason
about,
and
much
smaller
to,
work
with.
A
These
are
all
based
off
of
a
common
API
called
the
Linux
kernel,
virtual
machine
API,
or
sometimes
just
called
Deb
KVM,
because
that's
the
device
used
to
access
it.
So,
when
you're
building
a
virtual
machine,
you
provide
various
things
like
virtual
hardware,
and
the
problem
with
virtual
hardware
is
that
it's
a
very
large,
very
complex
attack,
surface
area.
So,
to
give
an
example
of
this,
you
know
how
many
people
have
used
one
of
these
awesome.
A
So
there
was
a
vulnerability
in
the
QEMU
virtual
machine
based
off
of
floppies,
and
even
if
you
didn't
have
a
actual
floppy
being
emulated,
the
floppy
drive
was
there
and
there
was
a
buffer
overflow
in
it,
and
this
was
a
major
impact
to
hosting
providers
where
they
had
to
go.
Rework
and
you
know
reboot.
All
of
these
VMs
upgrade
deal
with
this
problem
and
at
the
time
they
figured
ok,
let's
take
out
all
the
hardware
we're
not
actually
using.
A
So
you
know
no
way,
you'll
have
a
problem
in
the
popular
stuff
like
say,
graphics,
which
had
a
problem
with
yeah
so
that
one
turned
out
to
be
an
out
of
bounds.
Memory
access,
let's
access
this
buffer
full
of
bytes
using
a
UN,
32
pointer
and
go
4
times
later
than
you're
supposed
to
so
I,
don't
want
to
pick
on
QEMU
here,
it's
the
most
popular.
A
So
that's
why
I'm
mentioning
cases
it
has
had
been
affected
by,
but
there
have
been
major
security
vulnerabilities
in
all
virtual
machines
and
they
all
tend
to
lead
all
the
worst
ones
tend
to
be
arbitrary
code
execution.
These
are
often
caused
by
buffer
overflows
by
use
after
free
vulnerabilities
or
by
double
free
issues.
So,
just
to
emphasize
this
for
a
moment
we
first
started.
You
know
the
initial
discussion
of
what
a
buffer
overflow
was
happened
in
1972
in
1988.
The
very
first
exploit
of
a
buffer
overflow
occurred.
A
It's
2016
and
we're
still
dealing
with
this,
so
you
can
probably
see
where
this
is
going
and
the
reason
I
want
to
try
using
rust
for
this
is
that
it
prevents
these
whole
classes
of
bugs.
But
in
addition
to
that,
it's
also
a
pretty
good
fit
for
virtual
machines.
For
other
reasons,
it's
a
great
systems,
programming,
language,
there's
no
runtime
or
garbage
collector
to
get
in
the
way
of
doing
that.
Low-Level
programming,
and
it's
honestly,
the
first
language
I've
seen
that's
a
credible
replacement
for
C
and
C++
anywhere.
A
You
could
use
them
so
I'm,
not
gonna,
go
into
great
detail
about
the
KBM
API
here,
I've,
actually
written
an
article
for
lwn
on
the
details
of
the
API,
along
with
a
sample
virtual
machine.
That's
very
minimal,
but
one
thing
I
want
to
look
at
is
there's
a
structure
in
it
called
struct
KVM
run,
which
is
the
state
of
one
virtual
CPU,
and
it
has
all
sorts
of
things
in
it
related
to
that
state.
A
So
that
structure
looks
a
little
bit
like
this
and
the
most
common
things
it's
used
for
is
you
call
into
the
kernel
saying,
run
the
VM
for
a
while,
and
it
returns
after
a
while
saying:
okay
I
can't
proceed
until
the
virtual
machine.
Monitor
does
something
for
me:
here's
why
I
exited
and
it
might
be
I,
don't
know
why
the
hardware
just
seems
to
do
something
weird
it
could
be.
You
did
an
I/o
port
operation.
A
Here's
the
details,
but
the
thing
I
want
to
point
out
here
is
that
this
is
a
struct
with
a
Union
in
it
with
a
bunch
of
structs
inside
that
and
that's
actually
a
really
common
pattern
in
Linux
and
windows.
Api's
here
is
some
discriminant
and
he
is
the
details
of
all
the
variations.
So
it's
common
in
FFI,
it's
common
in
Linux
and
windows,
api's
I,
haven't
used
in
a
lot,
but
I
would
be
surprised
if
it
doesn't
show
up
reasonably
often
in
systems
level.
A
Programming
as
well
there
and
the
problem
here
is
Rus,
doesn't
actually
know
what
a
union
is
or
didn't
actually
know
what
a
union
is
so
Rus.
You
know.
So
let's
talk
a
bit
about
a
union
for
just
a
bit
of
background.
If
you
haven't
seen
one
before
it's
a
structure
that
has
multiple
storage
variants,
different
types
for
each
variant
and
overlapping
storage
for
each
of
those.
So
if
you
have
10
things
in
a
union,
it
uses
the
space
of
the
biggest
one,
not
the
space
of
all
of
them
at
once.
A
So
rest
says:
oh
I
know
what
you're
talking
about
you
mean
an
enum
right.
So
an
enum
is
a
safe,
tagged
union
and
when
you're
writing
native
rest
code,
it's
almost
always
the
thing
you
want
to
be
using,
but
a
union
a
union
from
a
low
level
systems
programming.
Point
of
view
when
you're
writing
C
code
is
an
unsafe,
untagged
Union.
You
have
to
know
by
some
application
specific
way
what
the
details
of
what
you
need
to
access
are.
So
you
can
do
this
in
rust.
A
Without
any
native
support,
you
can
call
functions
like
standard
mem,
transmute
and
pointer
offset
the
existence
of
which,
in
your
code
tends
to
mean
you're
having
a
bad
day.
They
tend
to
be
kind
of
awkward
and,
most
importantly,
they
lose
just
about
all
the
interesting
safety
properties
that
I
wanted
to
get
out
of
writing
a
virtual
machine
in
rust.
So
how
do
I
fix
this?
So
obviously
I
looked
into
this
trying
to
figure
out
what
do
I
do
about
this
I
found
the
request
for
comments
process
in
rust.
A
So
I
want
to
compare
this
for
a
moment
to
the
C
and
C++
standards
process.
I,
know
people
who
work
on
this
process.
So
you
know,
I've
talked
with
people
who
actually
make
changes
to
the
C
and
C++
standards,
and
the
main
thing
is:
it
tends
to
be
very
MTG,
driven
and
I
mean
very
in-person
meeting,
driven,
let's
all
get
together
and
talk
about
the
language,
it's
very
opaque.
It
tends
to
only
really
produce
results
when
it
has
something
to
show
and
not
all
the
intermediate
bits,
and
it's
pretty
much
an
expert's
only
club.
A
You
need
to
already
be
an
expert
and
then
go
say:
I
really
want
to
change
the
language
and
here's
all
my
myriad
reasons
why
to
compare
that
to
the
rest,
RFC
process
rusty
it
like
many
things
in
rust,
it's
extremely
welcoming
it's
open
and
transparent,
and
it's
extremely
inclusive.
So
in
particular,
rust
has
a
community
process
around
RFC's,
it's
very
lightweight,
but
it's
not
too
light
and
I
want
to
emphasize
that
a
lot
of
people
think
oh
well.
If
you
want
to
make
something
more
approachable,
you
need
less
process
so
that
it's
less
impenetrable.
A
That
kind
of
thing,
but
there
are
cases
where
you
actually
want
a
process
to
be
more
friendly.
For
example,
rust
has
a
shepherd
for
an
RFC
somebody
in
the
core
team
who's
saying
I'll,
keep
an
eye
on
this
and
help
move
it
through
the
steps
and
the
actual
decision
ends
up
being
made
by
one
of
the
rest
core
teams,
so
that
avoids
problems
like
diffusion
of
responsibility.
A
If
you
send
a
mail
to
a
mailing
list
with
a
thousand
people
on
it,
you
might
get
no
answer,
not
because
nobody
knows
the
answer,
because
because
everybody
figures,
it's
somebody
else's
problem
and
nobody
does
it.
So
the
in
particular
I
looked
around
for
details
of
what
I
could
do
with
unions.
It
turns
out
there
was
an
RFC
already
for
this
in
January
of
last
year,
RFC
724
for
unsafe
enum.
A
So
this
was,
let's
have
an
enum
without
a
discriminant
that
makes
sense,
unfortunately,
that
actually
got
closed
without
being
adopted,
but
there
was
some
interest
in
reviving
it
based
off
of
renewed
interest
in
the
FFI
layer,
and
there
was
a
thread
on
the
discourse
forum
talking
about
here.
Is
you
know
reasons
why
we
still
need
this
reasons?
Why
this
is
important?
Here's
the
approach
we
could
take
to
solving
this
problem,
so
I
started
poking
at
this
and
trying
to
come
up
with
okay.
A
What's
a
new
approach
to
this,
that
might
have
more
interest
and
more
ability
to
get
adopted.
So
the
first
problem
I
ran
into
was
keywords.
Things
like
struct
and
enum
are
keywords
in
the
rest
language.
So
if
you
try
to
write
something
like,
let
me
make
a
function
named,
struct
or
a
variable
named
email,
the
compiler
will
say:
no.
You
can't
do
that
and
everybody
I
know
has
that
same
cartoon
image
from
this
morning
in
their
heads
now
so
Union.
A
On
the
other
hand,
if
you
wanted
to
write
Union,
something-or-other
and
define
the
fields
you'd
want
you'd
first
thought
would
be:
let's
make
that
a
keyword,
so
it
turns
out
there's
our
it.
Not
only
would
that
prevent
you
from
using
functions
or
variables
named
Union.
There
are
already
functions
like
that
in
the
standard
library.
Let's
take
two
sets
and
get
the
union
of
them
so
can't
clearly
can't
use
that.
So,
let's
take
some
other
approach,
so
I
looked
around
and
thought
well,
you
can
have
a
wrapper
on
a
struct
that
says
well.
A
This
struct
has
the
representation
of
C
that
has
the
same
layout
as
C
on
the
native
platform,
or
it
can
be
a
packed
struct
that
is
doesn't
include
any
padding
for
natural
alignment
of
types,
so
maybe
Union
could
be
the
representation
of
a
struct.
This
struct
has
the
representation
of
overlapping
all
its
fields,
so
that
would
have
looked
like
this
and
yeah.
It's
not
the
prettiest
thing
in
the
world,
but
if
you're
only
gonna
use
it
in
fi
its
functional,
it
gets
the
job
done.
So
that
was
enough.
A
I
sent
a
mail
to
that
thread
called
a
pre
RFC,
saying:
hey
I'm,
thinking
of
filing
an
RFC
on
this
here's,
the
approach
I
would
use.
So
this
produced
a
bunch
of
responses,
the
most
notable
of
which
tended
to
be
well
you're
using
the
struct
keyword
but
you're,
giving
it
completely
different
semantics,
see
impact
or
just
ways
of
laying
out
a
struct
but
Union
actually
completely
changes
the
semantics
and
oh
by
the
way,
accessing
the
fields
is
now
unsafe.
So
that
seems
a
little
bit
strange.
A
So
what
if
we
just
pick
a
keyword
instead
that
doesn't
conflict
with
much
of
anything
in
the
standard
library.
So
how
about?
Let's
make
it
a
little
longer
and
say:
oh,
it's
an
untagged
Union.
Oh,
it's
still
a
keyword,
so
it
could
potentially
break
things
if
somebody
happened
to
have
a
local
variable
called
a
de
untagged
Union,
but
it's
an
improvement
and
there
ways
to
find
out
would
I
actually
break
anything
in
practice.
So
there's
a
beautiful
process
in
rust.
A
That's
often
used
as
part
of
the
RFC
and
other
language
changes
called
crater
and
crater
takes
age,
proposed
change
to
the
language
and
builds
the
entire
cargo
ecosystem
against
it
to
say
would
anything
we
know
about
break.
So
that's
really
handy
if
you
want
to
test
drive
something
with
the
entire
corpus
of
available
rest
code.
A
There
were
a
bunch
of
other
interesting
proposals
and
the
one
that
ended
up
grabbing
the
most
attention
was
Niko
I
believe
provide,
provided
the
idea
of
what
about
a
contextual
keyword,
something
that's
a
keyword
in
the
right
context,
but
it's
not
reserved
for
other
places.
So
that
would
let
us
actually
write
the
thing
we
really
want
to
write
to
begin
with,
which
is
Union,
but
then
you
can
also
write
this
and
it
doesn't
break
so
it's
a
little
quirky,
but
it
doesn't
really
cause
much
of
a
problem
in
practice.
A
So
that's
what
we
ended
up
going
with
and
I
mention
this
not
by
way
of
demonstrating
bike
shed
painting,
but
rather
to
say
this
is
the
kind
of
improvement
that
happens
through
the
RFC
process.
Here's
a
bunch
of
people
with
a
bunch
of
ideas
on
how
to
do
this
better
and
we
ended
up
with
something
much
better
than
what
we
would
have
done
without
that
process.
A
So
another
aspect
of
this
that
I
had
to
deal
with
when
writing
these
rfcs
was
unions
interact
with
everything
and
the
RFC
needs
to
discuss
all
those
language
interactions.
So
the
result
of
that
is
that
the
RFC
was
about
20%,
the
definition
of
unions
and
80%,
how
it
touches
absolutely
everything
else
and
what
happens
when
you
mix
the
two?
So
it's
vs.
the
obvious
things
like:
how
do
you
initialize
a
union?
How
do
you
read
and
write
fields
of
a
union?
How
do
you
pattern
match
one?
A
How
do
you
borrow
from
it,
but
it's
getting
increasingly,
let's
touch
a
bunch
of
other
features
of
rust.
What
about
visibility
annotations?
How
do
those
work?
Well,
hopefully
they
work
in
the
obvious
way,
but
what's
the
obvious
way,
let's
talk
about
it?
What
about
traits
can
you
define
traits
on
a
union
sure,
okay,
here's
how
they
work.
Can
you
have
generic
unions
with
a
parameterised
type?
How
does
it
interact
with
drop,
which
ended
up
having
a
bunch
of
additional
discussion
on?
Well?
A
So
controversy
did
not
expect
that
so
one
of
the
things
that
helped
a
great
deal
and
that
people
were
marked
on
later
as
being
ok
that
monitor
went
away,
but
that's
still
working,
that's
good,
so
was
to
have
summary
posts
in
the
thread.
That
said,
hey
there's
been,
you
know
several
hundred
messages,
but
here's
what
I
see
is
the
major
open
issues
for
us
to
move
forward.
A
We've
been
talking
about
this
and
here's
the
alternatives
we've
been
talking
about
that
and
here's
the
alternatives,
here's
the
points
of
disagreement,
and
even
if
people
had
different
opinions,
they
could
agree
yeah,
that's
the
set
of
open
issues
and
here's
where
I
fall
on
those.
The
other
aspect
of
it
is
an
RFC
should
really
be
self-contained.
So
all
that
history,
all
those
alternatives,
all
those
forum
threads
and
discussions-
should
end
up
in
the
RFC
in
summarized
form.
So,
even
though
the
union's
RFC
just
says
this
is
how
we're
going
to
do
it.
A
It
also
says
here's
the
eight
other
ways
we
could
have
done
it
in
the
advantages
and
disadvantages
in
a
fair
representation
and
fair
way,
so
that
anybody
looking
at
the
RFC
doesn't
have
to
say
well,
if
I
want
to
know
what
it
could
have
been
or
what
the
trade-offs
are.
Let
me
go:
read:
350
github
posts
and
a
discourse
thread.
A
So,
given
that,
how
does
this
progress
through
the
process?
How
do
you
make
an
RFC
move
forward?
So
there's
a
bunch
of
discussion
and
when
the
core
team
feels
like
it's
ready
to
say
yes
or
no,
we've
picked
a
reasonable
alternative.
Let's
say:
is
that
what
we're
gonna
do?
It
goes
into
final
comment
period
or
FCP.
That
says,
okay
last
call,
if
you
have
any
objections,
please
speak
now.
A
This
typically
gets
announced
in
this
week
in
rust,
which,
if
you're
not
already
reading,
I
highly,
recommend
it
and
that's
a
good
opportunity
to
see
hey
here's
something
that's
coming
up
in
the
language.
It
shows
when
an
RFC
is
first
posted
and
then
when
it
hits
final
comment
period.
So
what
is
the
status
of
Union?
The
RFC
was
actually
accepted
in
April
2016
yay,
and
it's.
A
Thank
you.
So
this
is
actually
part
of
the
rest
language
now
rust
includes
unions,
but
the
RFC
process
does
not
include
implementation.
The
work
on
implementation
can
run
in
parallel
if
it
wants
to
be
speculative,
but
in
general
the
implementation
doesn't
tend
to
happen
as
part
of
the
RFC
process.
So
as
part
of
the
RFC,
when
a
new
RFC
is
accepted
into
the
language,
there's
a
tracking
issue
opened
the
RFC
czar.
In
a
separate
repository,
the
tracking
issue
is
opened
on
the
main
rustling
slash
rust
repository
to
say.
A
Okay,
we've
decided
to
implement
this
here's
the
issue
where
we
track
this
implementation
status.
That
issue
is
still
ongoing.
It
is
being
but
the
details
in
particular
petro
chenkov.
I
hope
I'm
pronouncing
that
correctly
implemented
this
as
of
last
week,
so
it's
actually
available
in
nightly
rust.
Right
now,.
A
A
Then
what
I
want
to
do
with
this
is
I
was
running
a
very
simple
test
program.
So
I
wanted
to
run
a
little
bit
of
16-bit
assembly
inside
this
virtual
machine.
The
details
aren't
particularly
important.
So
don't
worry
if
you
don't
know
x86
machine
code,
that's
fine,
but
the
key
detail
here
is:
let's
write
out.
Let's
add
two
plus
two
which
are
in
the
registers
I
get
when
I
start
up.
Let's
turn
that
into
ASCII
by
adding
it
to
zero.
A
Let's
write
that
out
to
the
serial
court
and
then
write
a
new
line
to
the
serial
port.
So
if
all
goes
well,
this
should
add
two
plus
two
right,
two
new
line
and
then
halt
the
machine.
So
then,
on
top
of
that,
I'm
gonna
create
a
virtual
machine
with
one
virtual
CPU,
a
bunch
of
eye
octal
calls
to
KVM
api's
maps,
some
memory
containing
that
one
bit
of
code
set
up
the
initial
registers
point
the
instruction
pointer
to
that
code.
A
A
A
A
Without
having
to
name
field
is
gets
the
value
of
field
field,
two
gets
the
value
of
field
two,
so
you
can
define
local
variables
equal
to
the
field
names
and
then
just
bind
those
all
in
two
values
really
convenient
when
you've
got
27
fields
with
descriptive
names
and
you
don't
run
a
write,
X
gets
X,
Y
gets
Y,
Z
get
Z
and
so
on.
So
the
first
question
that
came
up
here
is
a
very
reasonable
question
that
just
about
every
RFC
is
going
to
get
asked.
Could
you
do
this
with
a
macro?
Instead?
A
What
would
a
native
implementation
give
you
over
this?
So
we
did
have
an
answer
for
that.
You
know
brevity,
simplicity,
some
better
compiler
checking
that
kind
of
thing.
There
were
reasons
for
that
and
so
far
it's
relatively
favorable,
but
the
discussion
leading
to
this
RFC
is
kind
of
interesting.
So
you
know
I
had
some
conversations
about
this
on.
A
You
know
a
private
chat
server
talking
about
hey
here's,
some
interesting
ideas
that
somebody
said
hey
has
anybody
heard
of
a
variation
of
this
for
us
somebody,
you
know,
may
have
suggested
it,
but
I
haven't
seen
anything
like
it.
So
we
talked
about
it
for
a
while
and
we
said
well,
hey
you
want
to
write
the
RFC.
Maybe
I
can
help
with
this.
Let's
try
it.
You
know
it
probably
won't
interact
with
too
many
language
features,
so
that
should
make
it
simpler
much
simpler
than
the
unions
RFC
right
and
a
few
hours
later
we
ended.
A
A
So
yeah
much
discussion
in
several
revisions
ensued,
but
it's
making
good
progress
and
seems
relatively
positive.
So
you
know,
let's
go
up
one
meta
level
here
and
say:
what's
the
state
of
the
RFC
process
itself,
alright,
so
the
RFC
process
is
actually
about
to
go
through
some
minor
renovations
and
refinements.
There's
been
some
discussion
about
pulling
in
some
process
improvements
learned
through
various
RFC's,
including
the
1444
for
unions.
One
of
the
big
ones
was
to
standardize
on
a
process
for
tracking
these
periodic
summaries
of
complex
RFC's
there's.
A
Also,
several
of
the
teams
have
already
moved
to
asynchronous
review.
Instead
of
saying.
Let's
talk
about
this
in
our
weekly
meeting
they're
saying
well
check
the
box.
If
you
agree,
we
should
move
forward
to
final
comment
period.
That
kind
of
thing
so
that
helps
to
make
more,
provide
more
responsiveness
to
various
RFC's
in
various
teams
and
the
rest
of
the
teams
are
kind
of
moving
over
at
incrementally.
A
A
So
if
there's
any
artists
in
the
community,
that
would
I'd
love
to
talk
to
you,
but
I'm
working
with
the
the
rust
style
team
on
this,
the
less
the
thought
I
want
to
leave
you
with
is
you
know
you
might
look
at
this
process
and
say
well:
I
have
to
be
an
expert
to
write
an
RFC
and
to
change
rust,
and
probably
the
single
most
important
thing
in
this
talk
that
I
want
to
point
out.
I
wasn't
give
it
a
shot.
A
A
First
of
all,
definitely
start
with
a
pre
RFC
discussion
started
discourse
thread.
Hey
I
was
thinking
of
proposing
something
like
this.
Does
this
sound
reasonable
you'll
get
a
lot
of
ideas
before
you
start?
The
formal
process
definitely
seek
advocates.
Seek
people
with
use
cases
other
than
your
own.
Find
collaborators
who
want
to
work
on
this
with
you?
It
doesn't
need
to
be
a
solo
process,
don't
break
compatibility
with
existing
code.
A
If
you
can
help
it,
crater
helps,
but
it's
even
better
to
say
this
can't
possibly
break
anything,
definitely
consider
and
discuss
all
the
language
features
that
might
interact
with.
If
you
don't
necessarily
know
about
all
those
language
features,
somebody
in
the
discussion
will
and
you'll
want
to
document
how
they
work.
You'll
want
to
document
all
the
history,
all
the
alternatives,
all
the
trade-offs
in
the
RFC
and
not
just
point
to
the
discussion
for
them
and
give
them
a
fair
evaluation
as
well.
That
really
seriously
consider
the
alternatives
and
the
suggestions,
the
response
to
an
alternative.
A
Isn't:
let's
write
that
down
as
a
thing
we
could
have
done
it's.
Maybe
this
is
better
than
what
we
were
proposing.
Maybe
we
should
go
with
that.
Instead,
what
could
we
learn?
Is
there
a
synthesis
of
both?
Then
you
should
seriously
consider
the
null
alternative
as
well
or
a
macro
implementation.
Is
there
a
better
way
to
do
this
that
doesn't
require
changing
the
language?
Could
it
be
a
library
thing?
Instead?
Could
we
keep
the
surface
area
of
rust
more
minimal?
A
Does
this
need
changes
to
the
language
and
definitely
make
summaries
as
you
go
if
you've
had
dozens
and
hundreds
of
messages
over
months,
not
everybody's
gonna
want
to
read
the
whole
status.
Summary
messages
linked
from
the
start
of
the
RFC
help
people
catch
up,
so
they
feel
like
they
can
participate
without
first
reading,
200
mails
or
duplicating
things
so
I
want
to
specifically
acknowledge
a
few
people
who
were
hugely
helpful
in
this
process.
A
Peter
was:
is
the
primary
author
of
a
lot
of
the
windows,
support
and
Windows
API
support
for
rust,
and
he
had
a
huge
need
for
unions,
and
so
we
talked
a
great
deal
about
the
use
cases
there.
You
be
Sam,
provided
a
lot
of
feedback
on
approaches
and
pushed
for
better
alternatives,
better
approaches
to
make
this
more
semantically,
sensible,
Nico,
provided
the
help
of
saying
hey
the
parser
can
actually
do
this
contextual
keyword
thing
so
that
we
could
actually
ship
it
that
way
and
then
Petra
chenkov
did
the
actual
implementation.
A
A
lot
of
other
contributors
to
RFC,
1444
and
a
the
rest
community
is
just
incredible.
So
the
thought
I'd
like
to
leave
you
with
is
you
know,
I
titled.
This
talk
in
order
to
form
a
more
perfect
union,
partly
because
I
mean
who
can
pass
up
that
kind
of
pun,
but
it's
also
RFC
is
the
process
by
which
we
form
a
more
perfect
rust
and
the
process
by
which
we
form
a
more
perfect
community.