Skip to content

Commit 4484680

Browse files
committed
RFC: Convention: do no prefix exports with the module's name
1 parent 8995a3a commit 4484680

File tree

1 file changed

+68
-0
lines changed

1 file changed

+68
-0
lines changed

active/0000-no-module-prefixes.md

Lines changed: 68 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,68 @@
1+
- Start Date: (fill me in with today's date, 2014-10-05)
2+
- RFC PR: (leave this empty)
3+
- Rust Issue: (leave this empty)
4+
5+
# Summary
6+
7+
This is a conventions RFC that proposes that the items exported from a module
8+
should *never* be prefixed with that module name. For example, we should have
9+
`io::Error`, not `io::IoError`.
10+
11+
(An alternative design is included that special-cases overlap with the
12+
`prelude`.)
13+
14+
# Motivation
15+
16+
Currently there is no clear prohibition around including the module's name as a
17+
prefix on an exported item, and it is sometimes done for type names that are
18+
feared to be "popular" (like `Error` and `Result` being `IoError` and
19+
`IoResult`) for clarity.
20+
21+
This RFC include two designs: one that entirely rules out such prefixes, and one
22+
that rules it out *except* for names that overlap with the prelude. Pros/cons
23+
are given for each.
24+
25+
# Detailed design
26+
27+
The main rule being proposed is very simple: the items exported from a module
28+
should never be prefixed with the module's name.
29+
30+
Rationale:
31+
32+
* Avoids needless stuttering like `io::IoError`.
33+
* Any ambiguity can be worked around:
34+
* Either qualify by the module, i.e. `io::Error`,
35+
* Or rename on import: `use io::Error as IoError`.
36+
* The rule is extremely simple and clear.
37+
38+
Downsides:
39+
40+
* The name may already exist in the module wanting to export it.
41+
* If that's due to explicit imports, those imports can be renamed or
42+
module-qualified (see above).
43+
* If that's due to a *prelude* conflict, however, confusion may arise due to
44+
the conventional *global* meaning of identifiers defined in the prelude
45+
(i.e., programmers do not expect prelude imports to be shadowed).
46+
47+
Overall, the RFC author believes that *if* this convention is adopted, confusion
48+
around redefining prelude names would gradually go away, because (at least for
49+
things like `Result`) we would come to expect it.
50+
51+
# Alternative design
52+
53+
An alternative rule would be to never prefix an exported item with the module's
54+
name, *except* for names that are also defined in the prelude, which *must* be
55+
prefixed by the module's name.
56+
57+
For example, we would have `io::Error` and `io::IoResult`.
58+
59+
Rationale:
60+
61+
* Largely the same as the above, but less decisively.
62+
* Avoids confusion around prelude-defined names.
63+
64+
Downsides:
65+
66+
* Retains stuttering for some important cases, e.g. custom `Result` types, which
67+
are likely to be fairly common.
68+
* Makes it even more problematic to expand the prelude in the future.

0 commit comments

Comments
 (0)