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.