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

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

[petrochenkov]

I’ve looked through the token list and selected tokens that can be more or less usable for other-crate-relative paths without ambiguities (including “inline” non-use paths).

Most of tokens were thrown away immediately because they can be used as binary/unary operators and they can be used freely with paths in expressions. I tried to not introduce new tokens for this, but in principle ~ can be used regardless of syntax details because it’s unused at the moment, or the backslash token (\) can be added to the language (can’t say I’m a fan though).

There are roughly three groups of possible syntaxes:

a INFIX b::c
OPEN_DELIM a CLOSE_DELIM b::c
PREFIX a::b::c

INFIX variants look universally bad, IMO, mostly because they break the path into separate parts.

a _ b::c
a::_::b::c
a crate b::c
a:\b::c // Windows drive letters!
a#b::c
a#::b::c
// etc

OPEN_DELIM a CLOSE_DELIM variants look better.

[a]::b::c
(a)::b::c
{a}::b::c
// but not <a>::b::c, it's already taken

PREFIX a::b::c (1) keywords. From all keywords only crate, extern and in looks somehow relevant.

// Less noise
extern a::b::c
crate a::b::c
in a::b::c
// More noise
extern::a::b::c
crate::a::b::c
in::a::b::c

PREFIX a::b::c (2) sigils, look kinda random.

_ a::b::c
_::a::b::c
#a::b::c
#::a::b::c
~a::b::c
~::a::b::c

Aaaand… ta-da!

@a::b::c

is not actually ambiguous!11

@ can currently be used only in patterns like this ref? mut? IDENT @ PATTERN and IDENT PATH is never a valid token sequence, so ident @a::b::c is unambiguously a pattern (ident @ a::b::c == IDENT @ PATTERN) and not ident @a::b::c == IDENT PATH, because the latter is not a valid syntax.

[petrochenkov]

Basically, the three most viable syntaxes were already discussed in various threads:

// The least noisy syntax, and well fitting because `@` has "location" semantics.
@a::b::c

// Slightly more noisy syntax, and memorable because `[ ### ]` is a *crate*.
[a]::b::c

// The "no sigils" variant, good if `use extern a;` will be used roughly like
// `extern crate a;` is used now, with "inline" uses being rare. Probably too
// wordy if used more often (e.g. in every `use` import).
extern a::b::c

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.