Revisiting modules -- `[other_crate]::path` syntax

[petrochenkov]

Should the above be necessary to work with paths starting with [other_crate]::?

No.
Being usable inline in paths without any separate introduction is exactly the point of [crate] syntax, compared to alternatives like from crate and status quo extern crate.

Should the above allow paths in the form other_crate::path?

Yes, because that’s what imports do.
use PATH; creates an item in its module, which can be used by scope-relative paths from the same module and module-relative paths from everywhere (modulo privacy).
It doesn’t matter if PATH contains bracketed segment in it or not.

EDIT: If extern crate is suddenly deprecated, the simplest migration strategy would be to replace extern crate c;s with use [c]; without touching any remaining sources.
This can even be done under #[cfg] is support for a wide range of compiler versions is required.
If use [c]; doesn’t work like extern crate c; (doesn’t bring names in scope, doesn’t define an item in module) then such a painless migration is not possible.

[elahn]

Should the above be necessary to work with paths starting with [other_crate]::?

Absolutely not!

Should the above allow paths in the form other_crate::path?

It would, but I personally would not do it. If you’re asking if we should disallow use [other_crate];? I don’t have a strong opinion either way.

[le-jzr]

This is required for backwards-compatibility, but I’d prefer to deprecate this syntax in favour of [other_crate]::path.

I don’t think backwards compatibility is a concern. extern crate would be deprecated, but it would still work same as today. It doesn’t make difference for automatic migration either, since rewriting all paths in a module is not that much more trouble, and guiding future language design based on the implementation complexity of one-time transition tools seems misplaced to me.

[kornel]

The syntax is non-obvious. Has similarities to arrays and computed keys.

In ES6 {foo:bar} uses "foo" key, and {[foo]:bar} uses key from variable foo. With that as my intuition the first thing I think of is:

const other_crate: &str = "var_crate";
use [other_crate]::path;  // Same as `use var_crate::path`

Even without that, I’d rather not add more syntax noise to use std::foo, and special-casing std is not great either.

I’d prefer:

• use foo::bar to look for either crate or module
• if both exist, pick the module
• if both exist and you want crate, use use extern crate_name::path;

[josh]

Should the above be necessary to work with paths starting with [other_crate]::?

The alternative is to allow external crates to be accessed freely without any advance declaration, and there was some pushback against that idea in the “Automatically Usable External Crates” RFC, so I’d like to know if those concerns extend here as well.

I don’t think it should be necessary. [crate]::foo should Just Work.

I’ve seen two objections to that RFC.

One involves mixing the names into the namespace without any declaration doing so, which [crate] addresses.

The other involves potentially wanting to use the crate names exclusively in a submodule but not elsewhere. For that, I would observe that you can always write extern crate cratename; in another module and use the names there, too, so this doesn’t seem substantially different than that. Either way, you have to apply some discipline to only use the names within a particular submodule. You could even get a tool to enforce that, or introduce a mechanism to declare that.

[KalitaAlexey]

Are we going to remove extern crate ...?

If we are, are going to use use [...] instead?

If we aren’t, is there any way (or will there any way) to compile some file without using cargo?

I mean in C I could do gcc -lmylib main.cpp -o main

Is that possible in Rust?

[le-jzr]

Are we going to remove extern crate ...?

It’s likely.

If we are, are going to use use [...] instead?

That’s one possibility among many.

If we aren’t, is there any way (or will there any way) to compile some file without using cargo?

I mean in C I could do gcc -lmylib main.cpp -o main

Is that possible in Rust?

cargo just automates calls to rustc. That is not going to change. You can run cargo in verbose mode to see what exactly it’s doing.

[arielb1]

I have two questions for everyone, about the particular case of

use [other_crate];

My assumption it that this would do the same as today’s

extern crate other_crate;

i.e., it would link against the other crate, and afterwards you would have an item named other_crate in the current module, which you could then use like usual, such as in

use [other_crate];
use self::other_crate::whatever;

About the std multiple-options: if we deprecate unprefixed paths in use statements but retain the std import in the root module for back-compat, then we would have

use std::fmt; // DEPRECATED
use [std]::fmt; // New style
use ::std::fmt; // Also works, maybe deprecate the implicit `std` import?

[troplin]

Doesn’t that syntax somehow conflict with slice syntax? Is [int] a module or a slice of ints?

[le-jzr]

Doesn’t that syntax somehow conflict with slice syntax? Is [int] a module or a slice of ints?

[int] as a path would never appear standalone. It’s either in use [int];, or followed by separator as [int]::. Everything else is an array, so there’s no ambiguity.

Additionally, in majority of code arrays are either sized (e.g. [u8;64]), or slices (e.g. &[u8]).

I admit there is a small possibility of newcomer confusion with things like

let x: &[bignum]::Value;

but I think people would get used to this quickly, and alternatives, in my personal opinion, are worse.

[steven099]

Note that if you use a slice type as a path today, it needs to appear in angle brackets:

let slice: &[i32] = ...;
let length = <[i32]>::len(slice);

[troplin]

Note that if you use a slice type as a path today, it needs to appear in angle brackets

I wasn’t aware of that, thanks.

EDIT:

Now that I think about this: Why is that the case and does the same reason not apply to the proposed syntax?

[le-jzr]

Note that if you use a slice type as a path today, it needs to appear in angle brackets:

I admit I didn’t even consider the possibility of slice types having associated functions. I mean, I knew they are there, just never saw them being called that way. Thanks for that clarification.

[withoutboats]

In an expression context this is currently treated as an array initialization. In a type context it is currently treated as a slice type. While these ambiguities could be resolved with sufficient lookahead I am not enthusiastic about making our grammar more complicated for this purpose & I’d rather see another solution.

[steven099]

Now that I think about this: Why is that the case and does the same reason not apply to the proposed syntax?

The fully specified syntax for accessing type/trait members is:

<Type as Trait>::member

This works for all types, including literal types. For inherent members, or where the trait can be inferred, you can write <Type>::member, which still admits literal types. The syntax Type::member is only available for named types (you can use the turbo fish syntax Type::<i32>::member to specify any type parameters in that case). In all cases, you could substitute path::to::Type as the Type.

Since the [crate] syntax has nothing to do with type/trait member access, the angle bracket syntax wouldn’t apply to it, except to the extent that the angle bracket syntax was chosen to avoid complicating parsing.

[troplin]

The syntax Type::member is only available for named types (you can use the turbo fish syntax Type::<i32>::member to specify any type parameters in that case).

I don’t pretend that I understand why that’s the case but ok. The turbo fish is surely one of the ugliest syntax constructs in Rust.

[steven099]

For only allowing named types in Type::member, the reason is because you can have a literal type like &Type::member(). Is that borrowing Type::member() or is it calling member on &Type? And as withoutboats mentioned, you’d have to have more lookahead to distinguish an array value [something] from accessing a slice type member [something]::....

As for turbo fish, the reason is that otherwise the syntax is ambiguous. How do you parse (a < b , c > ::f(d))? Is this just calling a member of type a<b, c> named f with argument d, or is it a tuple composed from comparing a to b and c to ::f(d), where f is a function in the crate root? Since types and values inhabit separate namespaces, both interpretations could be correct, so even resolving identifiers while parsing wouldn’t help.

[arielb1]

In an expression context this is currently treated as an array initialization. In a type context it is currently treated as a slice type. While these ambiguities could be resolved with sufficient lookahead I am not enthusiastic about making our grammar more complicated for this purpose & I’d rather see another solution.

The idea is that a loose "[" IDENT "]" would not be a valid type or expression path, but would still be a valid module path. We already maintain a grammar distinction between the 3 (type paths have parameters without a turbofish, expression paths have parameters with a turbofish, module paths can’t take parameters).

[RalfJung]

The idea is that a loose “[” IDENT “]” would not be a valid type or expression path, but would still be a valid module path. We already maintain a grammar distinction between the 3 (type paths have parameters without a turbofish, expression paths have parameters with a turbofish, module paths can’t take parameters).

But then one couldn’t actually write the following, right?

fn foo<T: [std]::io:Write>(x: T) -> [std]::vec::Vec<T> { ... }

[petrochenkov]

In an expression context this is currently treated as an array initialization. In a type context it is currently treated as a slice type. While these ambiguities could be resolved with sufficient lookahead I am not enthusiastic about making our grammar more complicated for this purpose & I’d rather see another solution.

It’s a minor thing and there is a number of similar situations already.
There are probably few bigger fans of simple grammar than me, and I’m still okay with this! The disambiguation costs maybe three extra lines in the parser.
EDIT: #39318, for example, was much worse and much less useful.

Now that I think about this: Why is that the case and does the same reason not apply to the proposed syntax?

<TYPE>::a::b::c needs to be usable with any possible TYPE and type grammar is too diverse to make types usable as path segments in general (there are pointers, references, lots of other ambiguous stuff). So, only identifiers (+ optional generic arguments following them) are allowed in paths, everything else has to be put in angle brackets <...>. This was a conservative decision.
[IDENT] is a very limited grammar and it can be accepted as a path segment, unlike a general TYPE.