Rewrite RFC

* Allow hyphens in the package name (but not the crate)

* De-quotify crate renaming syntax

Author: lambda-fairy

text/0000-hyphens-considered-harmful.md

@@ -5,110 +5,77 @@
 
 # Summary
 
-Disallow hyphens in package and crate names. Propose a clear transition path for existing packages.
+Disallow hyphens in Rust crate names, but continue allowing them in Cargo packages.
 
 # Motivation
 
-Currently, Cargo packages and Rust crates both allow hyphens in their names. This is not good, for two reasons:
+This RFC aims to reconcile two conflicting points of view.
 
-1.  **Usability**: Since hyphens are not allowed in identifiers, anyone who uses such a crate must rename it on import:
+First: hyphens in crate names are awkward to use, and inconsistent with the rest of the language. Anyone who uses such a crate must rename it on import:
 
-    ```rust
-    extern crate "rustc-serialize" as rustc_serialize;
-    ```
-
-    This boilerplate confers no additional meaning, and is a common source of confusion for beginners.
-
-2.  **Consistency**: Nowhere else do we allow hyphens in names, so having them in crates is inconsistent with the rest of the language.
-
-For these reasons, we should work to remove this feature before the beta.
-
-However, as of January 2015 there are 589 packages with hyphens on crates.io. It is unlikely that simply removing hyphens from the syntax will work, given all the code that depends on them. In particular, we need a plan that:
+```rust
+extern crate "rustc-serialize" as rustc_serialize;
+```
 
-* Is easy to implement and understand;
+An earlier version of this RFC aimed to solve this issue by removing hyphens entirely.
 
-* Accounts for the existing packages on crates.io; and
+However, there is a large amount of precedent for keeping `-` in package names. Systems as varied as GitHub, npm, RubyGems and Debian all have an established convention of using hyphens. Disallowing them would go against this precedent, causing friction with the wider community.
 
-* Gives as much time as possible for users to fix their code.
+Fortunately, Cargo presents us with a solution. It already separates the concepts of *package name* (used by Cargo and crates.io) and *crate name* (used by rustc and `extern crate`). We can disallow hyphens in the crate name only, while still accepting them in the outer package. This solves the usability problem, while keeping with the broader convention.
 
 # Detailed design
 
-1. On **crates.io**:
-
-    + Reject all further uploads for hyphenated names. Packages with hyphenated *dependencies* will still be allowed though.
-
-    + On the server, migrate all existing hyphenated packages to underscored names. Keep the old packages around for compatibility, but hide them from search. To keep things simple, only the `name` field will change; dependencies will stay as they are.
-
-2. In **Cargo**:
+## Disallow hyphens in crates (only)
 
-    + Continue allowing hyphens in package names, but treat them as having underscores internally. Warn the user when this happens.
+In **Cargo**, continue allowing hyphens in package names. But unless the `Cargo.toml` says otherwise, the inner crate name will have all hyphens replaced with underscores.
 
-      This applies to both the package itself and its dependencies. For example, imagine we have an `apple-fritter` package that depends on `rustc-serialize`. When Cargo builds this package, it will instead fetch `rustc_serialize` and build `apple_fritter`.
+For example, if I had a package named `apple-fritter`, its crate will be named `apple_fritter` instead.
 
-3. In **rustc**:
+In **rustc**, enforce that all crate names are valid identifiers. With the changes in Cargo, existing hyphenated packages should continue to build unchanged.
 
-    + As with Cargo, continue allowing hyphens in `extern crate`, but rewrite them to underscores in the parser. Warn the user when this happens.
+## Identify `-` and `_` on crates.io
 
-    + Do *not* allow hyphens in other contexts, such as the `#[crate_name]` attribute or `--crate-name` and `--extern` options.
+Right now, crates.io compares package names case-insensitively. This means, for example, you cannot upload a new package named `RUSTC-SERIALIZE` because `rustc-serialize` already exists.
 
-      > Rationale: These options are usually provided by external tools, which would break in strange ways if rustc chooses a different name.
+Under this proposal, we will extend this logic to identify `-` and `_` as well.
 
-4. Announce the change on the users forum and /r/rust. Tell users to update to the latest Cargo and rustc, and to begin transitioning their packages to the new system. Party.
+## Remove the quotes from `extern crate`
 
-5. Some time between the beta and 1.0 release, remove support for hyphens from Cargo and rustc.
+Change the syntax of `extern crate` so that the crate name is no longer in quotes (e.g. `extern crate photo_finish as photo;`). This is viable now that all crate names are valid identifiers.
 
-## C dependency (`*-sys`) packages
-
-[RFC 403] introduced a `*-sys` convention for wrappers around C libraries. Under this proposal, we will use `*_sys` instead.
-
-[RFC 403]: https://github.com/rust-lang/rfcs/blob/master/text/0403-cargo-build-command.md
+To ease the transition, keep the old `extern crate` syntax around, transparently mapping any hyphens to underscores. For example, `extern crate "silver-spoon" as spoon;` will be desugared to `extern crate silver_spoon as spoon;`. This syntax will be deprecated, and removed before 1.0.
 
 # Drawbacks
 
-## Code churn
+## Inconsistency between packages and crates
 
-While most code should not break from these changes, there will be much churn as maintainers fix their packages. However, the work should not amount to more than a simple find/replace. Also, because old packages are migrated automatically, maintainers can delay fixing their code until they need to publish a new version.
+This proposal makes package and crate names inconsistent: the former will accept hyphens while the latter will not.
 
-## Loss of hyphens
+However, this drawback may not be an issue in practice. As hinted in the motivation, most other platforms have different syntaxes for packages and crates/modules anyway. Since the package system is orthogonal to the language itself, there is no need for consistency between the two.
 
-There are two advantages to keeping hyphens around:
+## Inconsistency between `-` and `_`
 
-* Aesthetics: Hyphens do look nicer than underscores.
+Quoth @P1start:
 
-* Namespacing: Hyphens are often used for pseudo-namespaces. For example in Python, the Django web framework has a wealth of addon packages, all prefixed with `django-`.
+> ... it's also annoying to have to choose between `-` and `_` when choosing a crate name, and to remember which of `-` and `_` a particular crate uses.
 
-The author believes the disadvantages of hyphens outweigh these benefits.
+I believe, like other naming issues, this problem can be addressed by conventions.
 
 # Alternatives
 
 ## Do nothing
 
 As with any proposal, we can choose to do nothing. But given the reasons outlined above, the author believes it is important that we address the problem before the beta release.
 
-## Disallow hyphens in crates, but allow them in packages
-
-What we often call "crate name" is actually two separate concepts: the *package name* as seen by Cargo and crates.io, and the *crate name* used by rustc and `extern crate`. While the two names are usually equal, Cargo lets us set them separately.
-
-For example, if we have a package named `lily-valley`, we can rename the inner crate to `lily_valley` as follows:
-
-```toml
-[package]
-name = "lily-valley"  # Package name
-# ...
-
-[lib]
-name = "lily_valley"  # Crate name
-```
-
-This will let us import the crate as `extern crate lily_valley` while keeping the hyphenated name in Cargo.
+## Disallow hyphens in package names as well
 
-But while this solution solves the usability problem, it still leaves the package and crate names inconsistent. Given the few use cases for hyphens, it is unclear whether this solution is better than just disallowing them altogether.
+An earlier version of this RFC proposed to disallow hyphens in packages as well. The drawbacks of this idea are covered in the motivation.
 
 ## Make `extern crate` match fuzzily
 
-Alternatively, we can have the compiler consider hyphens and underscores as equal while looking up a crate. In other words, the crate `flim-flam` would match both `extern crate flim_flam` and `extern crate "flim-flam" as flim_flam`. This will let us keep the hyphenated names, without having to rename them on import.
+Alternatively, we can have the compiler consider hyphens and underscores as equal while looking up a crate. In other words, the crate `flim-flam` would match both `extern crate flim_flam` and `extern crate "flim-flam" as flim_flam`.
 
-The drawback to this solution is complexity. We will need to add this special case to the compiler, guard against conflicting packages on crates.io, and explain this behavior to newcomers. That's too much work to support a marginal use case.
+This involves much more magic than the original proposal, and it is not clear what advantages it has over it.
 
 ## Repurpose hyphens as namespace separators
 
@@ -131,7 +98,7 @@ mod hoity {
 }
 ```
 
-However, on prototyping this proposal, the author found it too complex and fraught with edge cases. Banning hyphens outright would be much easier to implement and understand.
+However, on prototyping this proposal, the author found it too complex and fraught with edge cases. For these reasons the author chose not to push this solution.
 
 # Unresolved questions