►
Description
RustConf 2019 - The Rust 2018 Module System by Josh Triplett
The Rust 2018 edition, as one of its flagship highlights, introduced a new module system, aimed to simplify the use of modules and crates for everyone. This talk will provide full documentation and exploration of the new module system, including motivations and mode of thinking, the practical impact of changes, and future enhancements in progress.
Whether you've had difficulties with modules in the past, or you're an experienced module user who wants to understand all the corners of the new system, come find out the present and future of modules in Rust!
A
Thanks
for
the
introduction,
all
right,
so
yeah
I'm
gonna
be
telling
you
a
little
bit
about
the
Russ
2018
module
system,
but
to
build
up
to
that.
I
want
to
give
a
little
bit
of
history
about
both
myself
and
how
I
came
to
be
giving
this
particular
talk
and
what
other
types
of
things
I
want
to
be
covering
with
it.
A
It
did
eventually
get
merged
and
released,
and
there
are
now
many
virtual
machines
based
on
rust,
which
I'm
incredibly
excited
enthusiastic
about,
but
that
talk
was
not
just
about
a
specific
language
feature
that
talk
was
also
about
how
we
build
a
more
perfect
rust
through
the
RFC
system.
It
was
a
case
study
on
the
RFC
process,
how
we
evolved
rust
and
how
we
interact
with
the
rust
community.
A
I
love
the
rest
community,
it's
incredibly
fun
incredibly
energizing
to
work
with
it
is
the
most
fun
open-source
community
I've
ever
worked
with,
and
as
a
result
of
that
talk
and
other
work
that
I'd
been
doing.
I
ended
up
getting
involved
with
the
rust
language
team
and
later
the
rust
cargo
team,
and
from
that
perspective,
I'd
like
to
tell
you
about
the
new
module
system
that
was
developed
for
the
rust
2018
edition.
But
as
before.
That's
not
the
only
thing.
A
This
talk
is
about
it's
really
about
how
the
language
team
works,
what
the
processes
are
behind
the
scenes,
what
it's
like
to
be
in
the
room
where
it
happens
and
the
so
I
want
to
go
into
some
more
detail
about
how
we
iterate
on
a
solution
and
how,
over
a
couple
of
years,
we
managed
to
develop
this
module
system
starting
from
I.
Think
there's
a
problem
here,
so
not
long
after
I
got
involved.
A
There
was
an
effort
called
the
ergonomics
initiative
that
was
aiming
to
try
to
provide
further
simplicity
for
the
language
as
well
as
a
measure
of
consistency.
How
can
we
not
just
add
things
to
the
language,
but
how
do
we
improve
what
we
have?
How
do
we
simplify
what
we
have
and
make
it
a
lot
more
usable
for
people,
so
in
January
2017
we
started
having
some
interesting
discussions
about
the
module
system.
One
of
the
members
of
the
language
team
made
a
blog
post
talking
about
the
usability
of
the
module
system.
A
A
So
the
other
piece
of
terminology
and
syntax
that
I
need
to
introduce,
if
you
haven't
seen
it
before,
is
that
rust
modules
can
correspond
precisely
to
a
file.
You
can
say
mod
example
semicolon
and
you
will
get
a
module
from
example
RS,
but
you
can
also
say
mod
example
and
then
put
curly
braces
and
you
can
inline
the
contents
of
a
module.
This
is
really
useful
if
you're,
just
using
them
as
a
local
organization
tool
within
a
large
file.
They're
also
really
useful.
A
If
you're
trying
to
give
examples
on
slides
and
don't
want
to
say
this
is
part
of
this
file,
and
this
is
part
of
this
file.
So
with
that
in
mind,
here's
what
normal
use
of
some
rust
dependencies
look
like
this
is
using
the
command
line.
Argument:
parser,
clap
in
cargo
Tamil,
which
is
this,
is
the
only
time
I'll
be
showing
this
part.
You
add
I
want
to
use
this
version
of
this
crate.
It
will
automatically
get
pulled
in
by
cargo
and
somewhere
in
your
main
program
or
your
main
library.
A
A
So
this
is
the
2015
module
system,
and
this
is
how
it
works
when
you're
in
the
top
level
module
main
dot,
RS
or
libbed
RS,
depending
on,
if
your
program
or
a
library
and
most
crates
start
with
just
one
module,
they
start
out.
Building
things
up
from
scratch:
they
do
some
interesting
stuff,
they
put
it
in
main,
they
put
it
in
Lib
and
everything
works
nice
and
simple,
and
the
problem
is
that
paths
for
crates
as
among
many
other
things
worked
differently.
A
Once
you
created
sub
modules,
which
made
it
harder
for
people
to
introduce
modularity
into
their
program,
they
start
building
something
with
a
single
module,
they
add
more
modules
and
suddenly
they
run
headlong
into
the
brick
wall
of
I.
Didn't
know
about
this
part
of
the
language.
So,
if
I
define
a
sub
module,
say
I
want
to
move
argument,
parsing
all
off
to
somewhere
else.
In
the
program,
then
use
looks
the
same.
I
still
use
clap,
:,
:
argh,
but
the
usage
suddenly
I
have
to
say
:
:,
clap,
:
:
app.
A
If
I
want
to
reference
it.
If
I
try,
if
I
leave
that
out,
I
get
a
compile-time
error,
saying
well,
I,
don't
know
what
clap
is.
Even
though
you
can
use
clap,
you
can't
reference
clap.
So
this
was
really
confusing
to
a
lot
of
people
and
it
was
especially
confusing
because
you
didn't
hit
it
until
you
introduced
sub
modules.
Another
problem
is
that
paths
for
sub
modules
themselves
also
worked
differently
in
sub
modules
when
you've
organized
your
program.
A
Referencing
pieces
of
that
program
from
other
pieces
of
your
program
works
differently,
depending
on
where
you're
doing
it
from
so.
Let's
say:
I
defined
this
module,
this
small
module
that
defines
a
few
public
structures,
s1
and
s2
I
can
go
use,
em
the
module,
:,
:,
s1
and
then
I
can
name
s1
anywhere
I
want
I
could
use
it
as
the
type
of
arg1
or
I
can
directly
name
something
if
I'm
only
going
to
reference
it
once,
for
example,
M
:
:
s2.
A
Now
let
me
move
that
into
a
sub-module
and
I
still
reference
arguments
by
saying:
M,
:
:
s
in
aargh
here,
but
notice
that
I
have
to
say
self
:,
:,
:,
:
s
1
by
the
end
of
this
talk.
:
is
probably
going
to
stop
sounding
like
an
English
word.
So
forgive
me
in
advance,
for
you
know
your
brain
for
the
following
hour.
A
The
the
problem
again
with
this
is
this
is
unexpected.
You
get
an
error,
saying
I,
don't
know
what
M
is
you
stare
at
it?
You're,
like
M,
is
that
thing
I
just
defined
and
told
you
about.
You
should
understand
this,
so
these
are
the
types
of
inconsistencies
that
we
saw
when
saying,
why
does
the
rust
2015
module
system
work
the
way
that
it
does,
and
these
introduced
big
surprises
when
you
add
modules
to
an
existing
one
file
project?
A
There
were
also
many
other
improvements
that
we
wanted
to
make
out
of
this
system
and
I'll
talk
about
some
of
those
later,
but
I
also
want
to
take
a
moment
here
and
say
this
is
not
yeah
not
just
to
talk
about
how
we
wanted
to
fix
the
module
system.
This
is
also
a
talk
about
development
and
consensus
processes
and
how
we
reach
to
the
successful
module
system.
So
let's
look
at
the
requirements
we
have
so
far.
First
of
all,
we
said
you
really
shouldn't
have
to
say:
extern
crate,
it's
a
little
redundant.
A
When
you
look
at
that
first
example,
you
had
define
it
in
cargo,
tamil
ad
extern
crate
and
then
use
it
or
reference
it.
That's
three
places
that
you
have
to
name
it
well,
one
of
those
is
actually
using
it,
and
one
of
those
is
saying
where
it's
version
is
so
those
are
clearly
required.
Extern
crate
just
feels
redundant
in
that
regard,
so
we
said
you
shouldn't
have
to
do
that.
We
also
said
that
you
should
have
the
same
syntax
in
the
top-level
module
and
in
sub
modules.
A
I
should
say:
I'm
glossing
a
little
bit
over
the
requirements
here
of
these
are
kind
of
what
we
eventually
figured
out.
The
requirements
were,
but
this
is
about
what
we
ended
up
at
that
these
are
the
most
important
things
we
wanted,
the
same
syntax,
whether
you
were
in
main
dot,
RS
or
two
levels
down
or
three
levels
down.
So
this
led
to
some
very
extensive
discussion
in
language
team
meetings.
Many
times
over,
we
have
regular
weekly
video
calls
with
all
of
the
members
of
the
language
team.
A
We
had
discussions
on
the
in
rust,
internals
forum,
which
is
a
discourse
instance.
We
had
discussions
on
discord,
the
chat
service
and
a
number
of
in-person
discussions
and
pretty
much
anywhere
else.
We
were
talking
about
things.
This
was
one
of
our
top
topics
to
go
through.
We
also
debated
things
like,
should
you
have
to
reference
external
crates,
especially
with
extern
:
:,
or
should
you
reference
your
own
crate,
specially?
A
We
were
trying
to
figure
out
what
is
the
unusual
case
and
what
is
the
common
case
and
we
kept
going
back
and
forth
because
it
felt
like
if
we're
going
to
be
consistent
about
paths.
One
of
these
would
have
to
be
qualified
somehow
and
one
of
them
wouldn't.
So
this
resulted
in
a
series
of
not
one,
not
two
but
three
separate
RFC's
trying
to
get
this
right.
The
first
two
were
closed.
The
third
one
had
eventually
reached
an
approach
that
we
all
had
a
rough
consensus
on.
A
So
the
approach
is
what
we
later
came
to
call
anchored
use
paths.
We
didn't
name
it
at
first
for
much
the
same
reason
that
rust,
2015
wasn't
originally
called
rust
2015
until
we
had
to
distinguish
it
from
rust
2018,
but
we
eventually
called
it
anchored
use
paths
and
the
idea
was
that
use
paths
always
had
to
start
with
something
that
referenced
a
crate
either
a
crate
name
like
clap,
:,
:
or
ray
on
:
:
or
your
own
current
crate,
in
which
case
they
would
be
crate,
:,
:
or
you
could
still
use
self.
A
If
you
wanted
to
use
relative
names,
but
you
didn't
have
to
or
you
could
use
super
to
reference,
the
parent
module
which
was
really
common.
When
writing
things
like
mod
tests,
let
me
pull
in
things
from
super
in
order
to
test
them,
so
we
finally
had
language
team
consensus
on
this
RFC
21:26
called
path,
clarity,
and
that's
exactly
what
it
was
trying
to
provide
is
clear
up
a
bunch
of
the
confusion
around.
How
do
you
reference
paths?
A
It
wasn't,
however,
not
fully
satisfying
exactly
it
had
a
fairly
mixed
community
reaction,
and
there
was
something
about
reading
through
it
and
dealing
with
it
that
felt
kind
of
okay.
This
technically
meets
all
the
requirements,
but
so
to
best
sum
up
what
we
later
realized.
The
issue
with
it
was
I
want
to
use
a
post
that
Aaron
Turan
used
to
describe
the
module
system
as
proposed.
He
said
these
situations,
meaning
dealing
with
sub
modules,
are
Achille
bad
in
Rus
2015,
because
the
code
works
without
self
:,
:,
a
top-level
module,
but
not
elsewhere.
A
The
rus
2018
s
current
design
helps
by
making
the
code
not
work
anywhere.
Ok,
technically,
that's
a
consistency.
It
also
would
have
required
changing
most
existing
rust
code
out
there
to
change
how
it
referenced
modules,
rust
fix,
would
have
potentially
helped
with
this,
and
it
would
have
been
essential
to
have
that
available.
But
none
of
us
were
wildly
excited
about
what
felt
like
it
would
be.
The
most
invasive
rust
2018
change.
A
Please
go
change
all
your
programs
to
use
this
new
module
system,
so
around
June,
ich
of
2018,
maybe
a
few
somewhere
in
those
months.
Aaron
and
I
had
a
discussion
on
discord
that
amounted
to
ok.
This
is
where
we
ended
up.
This
was
the
consensus
we
had.
Could
we
talk
about
how
we
got
there
and
why
we
couldn't
judge
it
was
one
of
those
like.
Are
we
really
here?
Is
this
really
what
we're
about
to
do
kinds
of
conversations
and
to
look
over
it?
A
So
if
you
can
write
a
:,
:
b,
:
:
C,
you
should
always
be
able
to
use
a
colon
:
b,
:,
:
c
and
then
just
write
c,
it's
a
very
nice
property
when
you're
used
to
like
IDE
refactoring
tools
and
similar,
you
feel
like
this
name,
should
look
the
same
as
this
name
and
then
I
just
shortened
this
name.
So
with
that
in
mind,
we
also
wanted
something
that
was
compatible
with
the
majority
of
rust
2015
code
out
there.
A
A
The
idea
was,
you
could
check
a
series
of
things
and
whenever
you
name
an
identifier
name
a
path,
you
would
first
check
whatever
was
in
the
local
scope
the
whole,
while
I
just
told
you
what
mod
iam
is
then
check
crates
that
you
have
available
and
check
the
pre
lewd,
which
is
where
we
put
things
that
are
automatically
in
scope,
that
you
can
always
name
like
option
and
result.
So
here
is
some
rust,
20:18
code
that
uses
that
as
an
example,
we
define
those
same
two
struts
in
a
sub
sub
module.
A
We
can
just
use
em,
:,
:,
sub
s1
and
it
works,
and
we
can
also
name
em
:
:
s2,
it's
the
same
syntax,
whether
you're
gonna
use
or
in
argument.
But
we
can
also
do
the
same
thing
for
crates.
We
can
use
clap
:
:
argh.
That
still
looks
for
a
crate
name
in
the
previous
proposal.
This
would
have
required
potentially
naming
it
explicitly
or
you
would
have
needed
something
to
reference.
A
The
previous
case,
one
or
the
other
case
would
have
had
to
have
been
decorated,
somehow
to
be
unambiguous,
and
you
can
also
reference
crate
names
in
expressions
like
this
clap,
:
:
app,
no
matter
where
you
are
in
the
program
that
will
always
work
if
you
have
clap
in
use.
So
this
does
introduce
a
kind
of
search
ambiguity.
It's
effectively,
saying
well
I'm
going
to
do
the
right
thing
when
I
see
a
name
like
clap.
A
I
can
still
write
crate,
:
:
to
reference
my
own
top-level
names,
I
can
still
use
self
to
reference.
My
own
module
level,
names
or
I
can
still
use
just
leading
:
:
to
say
no,
really,
it's
a
an
external
crate.
So
by
this
time
we
had
two
proposals
on
the
table.
We
had
this
solution
which
we
were
calling
uniform
paths
and
we
had
anchored
use
paths.
So
we
had
some
discussion
about
how
those
worked,
and
the
biggest
thing
we
found
was
that
there
was
some
reluctance
towards
a
new
round
of
debate
on
this.
A
We
had
gone
through
the
better
part
of
a
year
and
a
half
worth
of
talking
about
this,
and
we
had
found
something
where
everybody
seemed
more
or
less
happy
with
it.
It
was
not
exactly
satisfying,
but
it
was
kind
of
satisficing.
It
met
all
the
requirements,
and
so
people
were
not
excited
about
the
idea
of
wait.
We're
talking
about
this
again.
On
top
of
that,
there
was
some
very
reasonable
technical
considerations.
A
Everybody
who
had
touched
that
area
of
the
compiler
understood
very
well
that
it
was
very
subtle
and
when
you
messed
with
it,
it
would
mostly
work
and
then
you'd
have
corner
cases
after
corner
cases
after
corner
cases,
and
so
people
were
very
hesitant
to
adopt
a
solution
that
effectively
said
well,
if
we
just
made
the
compiler
smarter
and
finally,
there
were
actually
some
meaningful
differences
in
the
core
values
and
preferences
among
members
of
the
language
team.
I.
Don't
want
to
suggest
that
this
was
a
case
of
oh.
A
This
solution
was
obviously
better
and
it
just
had
technical
limitations,
and
maybe
we
didn't
want
to
reopen
old
wounds.
There
are
meaningful
differences
here.
Not
everybody
is
happy
with
the
idea
of
let's
figure
out
in
a
well-defined
order.
How
to
handle
ambiguity
where
this
might
mean
this,
or
it
might
mean
that
the
thought
was
well.
The
compiler
can
do
that.
What
if
the
programmer
wants
to
be
able
to
do
that
and
say
I
want
to
know.
A
Looking
at
a
path
what
it
is
unambiguously
all
the
time-
and
that
was
a
reasonable
request
and
it
was
a
different
request-
it
was
a
different
set
of
goals,
different
set
of
values
where
they
were
saying.
Well,
why
are
we
optimizing
for
writing
code?
Maybe
we
should
be
optimizing
for
a
reading
code
and
that's
a
reasonable
statement,
and
people
disagreed
on
how
to
implement
that.
So
all
that,
by
way
of
saying
this
was
one
of
our
and
the
language
team,
one
of
our
first
major
heavy
ideological
differences.
A
Heavy
bits
of
this
is
really
kind
of
stressful
to
debate
over.
How
do
we
reach
a
consensus?
It
seems
like
we're
deadlocked
that
kind
of
thing
there
have
been
in
the
past.
If
anybody
wants
to
look
at
the
history
of
the
question
mark
operator,
there's
a
long
and
storied
history
there,
and
that
one
was
also
heavily
like
community
consensus
and
whether
everybody
was
in
favor
of
it.
A
But
this
was
one
of
the
first
ones
where
the
language
team
itself
was
heavily
divided
and
debating
and
trying
to
figure
out
what
is
the
best
answer
for
rust
and
the
community.
So
as
part
of
moving
forward
on
this,
we
first
of
all
tried
to
make
sure.
Well,
can
we
actually
do
this,
and
so
I've
got
credits
at
the
end
in
detail,
but
a
couple
of
folks
sat
down
and
actually
wrote
a
prototype
implementation
of
this.
They
said.
Yes,
we
can
do
this,
here's
how
it
works.
A
Try
it
out
experiment
with
it,
see
how
it
feels.
So
there
was
a
successful
technical
implementation
of
the
new
proposal,
which
then
meant
hey.
You
can
sit
there
on
play
and
play
in
nightly
and
figure
out
what
we
want
it
to
look
like.
We
went
ahead
and
tried
it
out
on
nightly
and
said:
let's
see
how
these
implementations
work,
because
the
critical
point
is
which
one
do
we
choose
to
stabilize.
We
looked
for
feedback
from
the
community.
There
were
several
polls,
but,
more
importantly,
not
just
numeric
and
quantitative
questions,
but
more.
What
do
people
think?
A
What
are
other
people's
values?
What
are
other
people's
arguments
for
it?
It's
not
helpful
to
have
47
people
saying
they'd
like
this
and
43
saying
they'd
like
that.
It's
extremely
helpful
to
have
four
people
say:
here's.
Why
I
prefer
this
alternative
or
here's?
Why
my
code
would
look
better
with
this
alternative?
That
kind
of
thing
as
more
of
a
qualitative
helped
me
understand
what
your
preferences
are.
That's
the
kind
of
thing
that
was
extremely
helpful
to
see
when
we're
trying
to
figure
out
what
arguments
aren't
we
seeing
what
balance
aren't
we
seeing
beyond
that?
A
We
found
that
we
were
doing
a
lot
of
careful
discussion
and
introspection
on
what
these
core
values
that
we
had.
Are
that
there's
an
argument
or
tactic
where
you
can
say
all
right,
let's
step
back
for
a
moment,
let's
both
figure
out
what
our
values
are
that
are
causing
us
to
get
very
attached
to
what
our
solution
is.
Let's
figure
out
what
the
other
person's
values
are
well
enough,
that
we
can
explain
it
back
to
them
and
they're
like
yeah.
A
That's
what
we
believe
and
if
you
can't
get
at
least
that
far
then
you're
not
going
to
be
able
to
have
a
good,
clear
discussion
about
it,
you're
just
disagreeing,
and
so
we
had
a
lot
of
very
careful
conversations
like
that.
Where
we
wrote
up
documents,
we
wrote
up
a
Dropbox
paper
document
where
everyone
wrote
separately,
what
their
views
were,
but
then
went
through
everyone
else's,
and
we
discussed
what
those
were
and
trying
to
understand
where
work
where
each
other
are
coming
from
and
that
helped
hugely.
A
So
in
the
meantime,
we
went
ahead
and
released
1.31
and
rust
2018
with
a
compromise
solution.
We
said:
okay,
these
two
are
actually
very
similar
and
the
main
issue
they
have
is
when
you
have
ambiguity,
one
of
them
would
say
you
must
disambiguate
it
like
this,
and
the
other
would
say:
here's
how
we
resolve
it.
So
we
effectively
made
that
an
error
and
said
you
can't
hit
the
case
where
these
two
systems
differ.
A
You
have
to
use
something
that's
compatible
with
both
and
that
allowed
us
to
defer
a
little
bit
longer
figuring
out
what
the
correct
answer
was:
it's
again,
not
wildly
satisfying,
but
it's
worth
noting
that
even
critically
important
and
very
heavy
features
like
this
still
wait
for
the
next
train.
If
they're
not
ready
in
time,
there
is
no
pass
for
oh
you're
on
the
language
team,
so
we'll
sneak
something
in
in
time.
A
We
very
much
said:
let's
wait
a
release,
we're
not
ready
to
make
this
call
yet
so
I
mentioned,
we
collaboratively
wrote
a
document
about
both
alternatives.
We
explored
down
both
paths
very
extensively,
had
some
very
excellent
discussions
where
people
it
is
incredibly
rare
to
see
people
genuinely
change
their
mind
on
something
that
they
felt
very
strongly
about,
and
it
was
an
impressive
sight
to
see
on
several
counts,
so
we
ended
up
making
the
decision
shortly
thereafter
and
we
finished
up
the
uniform,
pads
implementation
in
132
and
that
discussion
had
wrapped
up
in
that
form.
A
But
it's
worth
noting
that
one
of
the
reasons
I'm
giving
this
talk
is
that
because
it
was
iterating
so
quickly
because
it
was
going
through
all
of
these
decision
processes.
The
final
version
of
this
implementation
is
not
exactly
what
was
documented
in
the
original
RFC
for
path.
Clarity
and
the
new
version
of
what
was
implemented
was
effectively
defined
by
the
compiler
for
132,
more
so
than
by
written
documentation.
A
And
then
we
went
back
and
wrote
some
more
of
the
documentation
later
and
so
part
of
the
point
of
this
talk
was
to
say,
here's
how
we
got
there
and
here's
what
we
ended
up
with
so
I
want
to
go
through
a
few
more
of
the
technical
details
that
I
had
skipped
past
earlier
to
make
sure
that
I
would
go
all
through
all
of
the
decision-making
process
and
values.
So
with
that
in
mind,
some
of
the
other
items
that
we
looked
at
were
how
to
handle
macros.
A
This
was
actually
handled
through
a
somewhat
separate
process
in
separate
RFC's,
but
it
was
part
of
the
same
unifying
theory
for
a
module
system
in
rust,
2015
there's
a
whole
separate
way
to
export
and
then
use
macros.
So
if
you
want
to
use
one
of
these
macros,
like
crate
name
or
crate
authors
from
Clapp,
then
you
use
macro
use,
extern,
crate,
clap,
which
will
import
effectively
import
star
from
clap.
A
A
You
can
actually
use
a
macro
exactly
like
any
other
name,
if
you're
using
it
from
an
external
crate,
there's
some
corner
cases
that
I
won't
go
into
involving
local
modules
in
your
own
crate
and
we're
hoping
to
fix
those
someday.
But
in
the
meantime
you
could
just
use
clap
colon
colon
crate
name
and
then
use
crate
name
as
a
macro,
just
like
crate
name
was
any
other
kind
of
name.
You
could
also
just
reference
a
macro
with
a
scoped
name
in
case
you
didn't
want
to
pull
it
in
by
name.
A
You
just
wanted
to
use
it
where
it
was
so
macro
pads,
now
work
more
or
less
like
function,
pads
and
again,
unification
and
simplification.
We
added
something
new
to
the
language,
but
we
did
so
in
a
way
to
make
the
language
as
orthogonal
as
possible
so
that
it
worked
the
same
way
and
you
didn't
need
to
learn
the
rule
for
functions
and
then
the
learn
the
rule
for
macros,
just
like
you,
didn't,
have
to
learn
the
rule
for
use
statements
and
then
the
rule
for
expressions.
A
The
couple
other
changes
you
can
now
have
food
RS
and
a
sub-module
foo,
slash
bar
dot
RS.
You
no
longer
have
to
write
foo
slash
mod
RS,
mod
RS
was
similar
to
dunder
and
net
dot
pie
if
you're
familiar
with
that
in
Python
or
otherwise.
This
is
the
module
that
represents
the
parent
module.
Previously,
there
were
some
ambiguities
here
and
you
had
to
always
use
mod
dot
RS.
A
If
you
had
sub
modules,
which
meant
with
you
want
to
add
a
sub-module,
you
have
to
move
food
RS,
and
people
also
observed
that
if
you
had
it
open
in
an
editor,
you'd
have
a
lot
of
files
named
mod
RS
and
you'd
have
to
see
where
they
were.
So
this
is
a
little
cleanup
that
is
just
quality
of
life
improvements.
A
One
other
item
was
we
started
seeing
well.
Why
else
are
people
using
X
turn
crate?
We
wanted
to
deal
with
macros,
so
we
needed
a
way
to
substitute
for
macro
use.
We
also
needed
to
deal
with
crate
renaming
people
could
do
extern,
crate
foo
as
bar
and
then
reference
the
crate
as
bar
everywhere
else.
So
we
ended
up
with
a
new
feature
in
cargo
that
allowed
you
to
say:
hey
I'm,
using
the
crate
bar
but
I'm
sorry
I'm,
using
the
name
bar,
but
it's
really.
A
The
package
named
foo
so
go
get
the
package
foo
with
this
version
and
then
name
it
bar
in
my
program
throughout.
So
this
was
the
replacement
for
extern
crate
foo
as
bar,
and
that
was
kind
of
the
last.
You
have
to
use
extern
crate
other
than
if
you're,
using
no
standard
or
no
core.
Then
there
are
some
cases
where
you
need
to
reference
standard
or
core
with
extern
crate,
but
because
those
are
a
lot
less
common.
Those
didn't
get
addressed
quite
yet,
but
this
effectively
meant
the
normal
most.
A
Normal
programs
did
not
need
to
use
extra
and
crate.
So
a
few
other
bits
of
future
work
that
come
from
the
nature
of
let's
pull
things
out
and
do
the
minimal
step
that
we
can
in
order
to
bypass
controversy
and
avoid
bundling
27
different
things
into
an
amalgam
that
will
never
pass.
We
talked
about
what
cost
so
possible
future
work
were
a
lot
of
people
really
don't
like
having
to
write
mod
statements.
A
A
As
well
as
anything
you
don't
mark
as
pub
is
private,
the
one
that
people
don't
often
know
about
is
you
can
write
pub,
parenthesis
crate,
and
this
is
effectively
protected
inside
my
crate,
but
and
outside
the
module.
You
can
use
this,
but
I
can't
use
it
outside
the
crate.
So
there
was
a
proposal
to
make
this
easier
to
use
by
defining
a
new
visibility
named
crate,
rather
than
pub
crate.
You
could
just
write
crate
you're,
saying
instead
of
a
pub
type,
this
is
a
crate
type,
so
it
had
a
kind
of
logical
flow
to
it.
A
It
was
separated
out
due
to
a
bunch
of
dude,
primarily
to
one
corner
case,
that
we'd
seen
where
it's
a
little
ambiguous
and
we
weren't
very
satisfied
making
the
call
there
were
some
other
reasons
as
well,
but
the
biggest
one
was
this:
if
I
write
a
struct,
a
parenthesis,
tuple
struct
that
has
crate
colon
colon
T,
does
that
mean
the
type
T
that
is
at
the
top
level
of
my
crate?
We're
crate
is
a
scope,
or
does
that
mean
a
type
colon
colon
T
that
is
named
elsewhere?
That
has
visibility
crate.
A
So
this
was
a
delightful
little
ambiguity
that
resolving
this
would
have
required
either
defining
one
or
the
other
to
be
what
happens
or
having
a
rule.
That
says
you
must
disambiguate
and
we
won't
allow
either
one
of
them,
but
again
there
is
still
interest
in
simplifying
the
use
of
the
pub
crate
visibility,
and
so
what
form
that
will
take
in
the
future
I
don't
know
so
I
wanted
to
take
this
time
to
kind
of
reflect
on
difficult
decisions.
A
This
was
one
of
the
first
major
ideological
disagree,
so
we
had
to
work
our
way
through,
but
they're
going
to
be
and
have
been
many
more
overtime,
I'm
going
to
very
briefly
mention
async/await,
for
example,
where
there
was
a
lot
of
controversy
on
what
the
right
syntax
was.
Many
many
people
said
we
definitely
need
this
feature.
We
need
to
settle
on
some
syntax
for
this
feature.
There
were
in
fact,
almost
three
camps
here
of
people
who
wanted
prefix
people
who
wanted
postfix
and
people
who
want
something
real
soon.
A
Now,
please
and
I'm,
not
joking,
those
were
the
three
camps,
and
so
there
was
a
lot
of
discussion
about
this.
It
did
finally
get
stabilized
for
139
very
recently
in
the
last
few
days,
in
fact,
so
that
is
awesome
I'm,
so
glad
to
see
yesterday,
people
actively
using
the
new
async/await
syntax
from
nightly
in
a
training
class
about
async/await.
So
that's
incredibly
exciting.
But
again,
this
is
the
kind
of
thing
that
took
a
lot
of
discussion,
a
lot
of
very
careful
working
through
of
well.
What
is
it
about
this
Intex
to
you
that
you
like?
A
What
is
it
about
the
syntax
that
you
like
everybody's,
trying
to
build
a
good
language
nobody's
trying
to
sabotage
a
language
and
remembering
that
and
moving
forward
and
saying?
How
do
we
get
to
the
best
solution,
ended
up
allowing
us
to
reach
something
that
everybody
was
either
thrilled
with
happy
with
or
could
otherwise
live
with
moving
forward
with,
without
causing
any
of
the
problems
that
people
were
concerned
about
with
other
syntaxes?
So
I
want
to
sum
this
up
with
a
few
different
points.
A
First
of
all,
I
would
encourage
people
to
beware
of
satisficing
solutions
cases
where
yes,
you've
technically
met
all
the
requirements.
You've
technically
done
everything
you
need
to
do,
but
nobody's
really
happy
with
it,
and
so
when
this
happens,
sometimes
it
really
is
something
where
you're
balancing
so
many
conflicting
values.
You
just
cannot
make
everybody
happy.
A
At
the
same
time,
there
was
a
degree
to
which
the
module
system
was
in
that
state,
and
then
we
ended
up
coming
up
with
a
new
solution
that
made
the
vast
majority
of
people
much
happier
than
anything
we'd
seen
yet
so
far.
So
a
satisficing
solution
might
be
a
sign
that
you
need
to
look
more
closely
for
other
potential
Avenues.
A
Another
is
to
raise
issues
very
early,
no
matter
how
much
you
declare
something
is
interim
or
experimental
people
will
get
attached
to
it.
Some
people
got
attached
to
a
weight,
bang
the
macro
like
syntax
and
said:
oh
I
thought
that
was
what
we
were
stabilizing
and
the
same
thing
goes
for
a
lot
for
many
other
cases
where
once
you've
gotten
something
down
the
path
to
it
looks
like
this
is
what
I
can
use
in
nightly.
Then
people
will
get
attached
to
it,
I
always
introspect
on
what
values
your
opinion
is
based
on.
A
If
you
have
disagreements-
and
it's
worth
going
one
level
lower
and
saying
what
is
it
that
makes
you
attach
to
this,
what
is
it
that
makes
it
important
to
you?
Why
do
you
consider
the
solution
bad,
and
can
you
define
what
bad
means-
and
that
includes
your
own
values,
which
this
is
a
challenging
thing
to
do
to
realize?
Ok,
I
feel
really
strongly
about
this.
Why
do
I
feel
really
strongly
about?
This?
A
A
He
wrote
several
really
good
blog
posts
on
consensus
and
decision,
making,
Eddie
B,
Kramer,
TJ
and
Petra
chenkov,
as
well
as
a
host
of
other
people,
were
critical
in
making
the
new
module
system
work.
Getting
it
implemented,
debugging
at
all
sorts
of
other
issues
and
I
am
probably
forgetting
some
people,
as
well
as
the
entire
rust
language
team,
which
has
been
extraordinary
to
work
with
and
again
the
incredible
rest
community.
So
with
that,
thank
you,
I'm
available
by
email
and
on
Twitter,
and
it's
been
wonderful
talking
to
you.