Decision: Separator choice

[Manishearth]

Related: #2

The current RFC lists slashes as the separator choice. They have some drawbacks

So far slashes as a "separator" have not existed in Rust. There may be dissonance with having another identifier character allowed on crates.io but not in Rust code. Dashes are already confusing for new users. Some of this can be remediated with appropriate diagnostics on when / is encountered at the head of a path.

Furthermore, slashes are ambiguous in feature specifiers:

[dependencies]
"foo" = "1"
"foo/std" = { version = "1", optional = true }

[features]
# Does this enable crate "foo/std", or feature "std" of crate "foo"?
default = ["foo/std"]

There are many other alternatives we could pick:

We could perhaps have foo-* get autoreserved if you publish foo, as outlined in https://internals.rust-lang.org/t/pre-rfc-hyper-minimalist-namespaces-on-crates-io/13041 . I find that this can lead to unfortunate situations where a namespace traditionally used by one project (e.g. async-*) is suddenly given over to a different project (the async crate). Furthermore, users cannot trust foo-bar to be owned by foo because the vast number of grandfathered crates we will have.

Another separator idea would be to use ::, e.g. foo::bar. This looks great in Rust code, provided that the parent crate is empty and does not also have a bar module. See the section above for more info.

Triple colons could work. People might find it confusing, but foo:::bar evokes Rust paths without being ambiguous.

We could use ~ which enables Rust code to directly name namespaced packages (as ~ is no longer used in any valid Rust syntax). It looks extremely weird, however.

We could use dots (foo.bar). This does evoke some similarity with Rust syntax, however there are ambiguities: foo.bar in Rust code could either mean "the field bar of local/static foo" or it may mean "the crate foo.bar".

Note that unquoted dots have semantic meaning in TOML, and allowing for unquoted dots would freeze the list of dependency subfields allowed (to version, git, branch, features, etc).

[carols10cents]

Ugh. No great choices here. I'm currently leaning toward something new and weird to avoid ambiguities with existing code; we'll get used to the way it looks. But I'm open to being convinced otherwise, especially by people on the Cargo, compiler, and lang teams.

[Manishearth]

@carols10cents an important point brought up by @withoutboats was that something that "converts to an underscore" would not require rustc changes, and they prefer a solution that is self contained in cargo/crates.

[pksunkara]

From your example:

[package]
name = "using-foo"

[dependencies]
"foo" = "1"
"foo/std" = { version = "1", optional = true }

[features]
# Does this enable crate "foo/std", or feature "std" of crate "foo"?
default = ["foo/std"]

What features does using-foo have? It would have foo/std, which means if I am using this crate as a dep, I might do something like below:

[dependencies]
"using-foo" = { version = "1", no-default-features = true }

[features]
# Does this enable feature "foo/std" of crate "using-foo", or feature "std" of crate "foo" of "using-foo"?
default = ["using-foo/foo/std"]

As you can see, this will quickly blow up and will be a bit inefficient for cargo to resolve.

---

Recently namespace features in cargo added syntax as crate:serde in feature strings. We could try to adopt it.

[package]
name = "using-foo"

[dependencies]
"foo" = "1"
"foo:std" = { version = "1", optional = true }
"foo:bar" = { version = "1", optional = true }

[features]
# This enables crate "foo:std" & feature "std" of crate "foo" & "foo:bar"
default = ["foo:std", "foo/std", "crate:foo:bar"]
baz = []

Now the using-foo will have features foo:std and baz.

[dependencies]
"using-foo" = { version = "1", no-default-features = true }

[features]
# enable feature "foo:std" of crate "using-foo"
default = ["using-foo/foo:std"]
# enable feature "std" of crate "foo" of "using-foo"
zzz = ["using-foo/foo/std"]

[Manishearth]

@pksunkara I don't see how this will "quickly blow up" since at worst there are never more than two options.

Discussions about feature syntax should go in #4 , I've proposed some fixes there.

[pksunkara]

Since we were discussing separator choice, I was arguing against / by showing the problem of #4.

To clarify, what I meant by my previous comment is proposing the separator to be changed to : and how it fixes #4.

[Manishearth]

Ah, I see.

Would we map : to - in rust code, or would we do use foo:bar::baz? (that seems weird, and there are also potential ambiguities)

[pksunkara]

We would map and that is being discussed in #2, right? I wanted to keep the context here to just the separator.

[Manishearth]

Correct, but it's important to note if you want it to have a mapping in the first place or be in-source.

[JWorthe]

One issue that might come up with slashes which I haven't seen mentioned elsewhere is that it's commonly used as a path separator. This could specifically make it more difficult for CLI tools to know what people are trying to do.

An interesting example is cargo new, since it also handles paths that might contain slashes and infers the crate name you want.
cargo new foo/bar will create ./foo/bar/Cargo.toml with the crate name bar.
In this case, you can resolve the ambiguity by being explicit about the name you want, for example cargo new foo/bar --name foo/bar