|
| 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