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

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

[steven099]

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

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

[std] is being used as a module path in each of those instances, denoting the root module of crate std. It always appears in the construction module-path "::" ident, which is unambiguous once the parser encounters the “::”.

[RalfJung]

[std] is being used as a module path in each of those instances, denoting the root module of crate std. It always appears in the construction module-path “::” ident, which is unambiguous once the parser encounters the “::”.

AH, and as you said above you can’t use plain brackets to put a slice into a path, you need extra angle brackets. Good

[le-jzr]

Revisiting modules, take 3

This actually would be a special case – the [std]:: prefix roots the path, but so far I have not seen as [std] as being an item on its own.

So you’re saying it would make more sense to treat this exclusively as path prefix, and not allowing use [std]; at all, same as we don’t allow e.g. use super;?

I think I agree with that. It’s the one thing that is making me subtly uncomfortable about this syntax. I edited the original post to add this view.

[arielb1]

[std] is being used as a module path in each of those instances, denoting the root module of crate std. It always appears in the construction module-path "::" ident, which is unambiguous once the parser encounters the “::”.

Nit: that’s not entirely true. You can have the expression-path [std]::vec::Vec::<T>::clone. The construction is more like

expr-path <- expr-segment
expr-path <- expr-path-or-crate "::" expr-path
expr-path-or-crate <- expr-path
expr-path-or-crate <- crate-bracket
crate-bracket <- "[" IDENT "]"
// ^ means `[std]::<u32>` is *syntactically* illegal, which I think
// is ok.

[steven099]

Sure, my intent was just to distinguish between a path and a path prefix, so I fudged the details a bit. Maybe a bit more than strictly necessary.

[troplin]

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

But you can also have such ambiguities in ordinary expressions and there you have precedence rules and you can use parentheses for disambiguation. E.e. *value.member is not the same a (*value).member.

The same could also apply to paths.

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.

Yes it’s very conservative and I imagine that the rule could be relaxed to only require brackets if strictly necessary (like parentheses). I think this would even be backwards compatible.

This new syntax would probably prohibit such a generalization.

[dpc]

I think [cratename] is confusing if it’s going to be used inline, and not only in use statements. Originally I wanted the qualifier on the use itself:

use extern cratename

or

use extern cratename::something

I don’t think the possibility of code using impl [std]::fmt::Write for Smth is great for the readability, especially if it’s mixed with arrays etc.

As much as I dislike Go, I think that having every external symbol prefixed by it’s module name/import name was an interesting idea. So in Rust it would mean that only modules (and not symbols itself) can be imported with use (with a possibility of rename to avoid collisions), and then used with a prefix they were imported with, so always:

use extern std::thread;

fn ... {

    thread::sprawn()
}

and use std:;thread::spawn is impossible.

I’m not sure if’s best idea for Rust, but it sure helps with certain things.