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

language design
31

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.

2 Likes