document difference between T:: and <T>:: in paths

[tlyu]

Background: this is something that I stumbled across while researching #24.

The Paths section has distinct syntax for PathInExpression and QualifiedPathInExpression. What isn't clear is the semantic difference between, say, T::func and <T>::func where T is a type.

I think T in <T>::func is not subject to inference, and therefore all of its generic type arguments must be explicitly specified, or defaulted. I'm not quite able to conclusively show it to my satisfaction, though.

It is clear that <Trait>::func isn't valid, and possibly this should be documented (even though it's implied by the production names).

#[derive(Debug)]
struct S(u8);
trait Tr {
    fn foo() -> Self;
}
impl Tr for S {
    fn foo() -> Self { Self(1) }
}
fn main() {
    // The following is an error, because Tr is a trait, not a type.
    // let x: S = <Tr>::foo();

    let x: S = Tr::foo();
    println!("{:?}", x);
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=c7f60a975096972761bcaaa58f692379

[tlyu]

Still working on all the details, but it seems that the key difference is type context vs expression context. In type context (type annotations for let, or QualifiedTypeInPath syntax like <T>::), omitted type parameters are only allowed if they are defaulted. In expression context, omitted type parameters are set to inferred. Defaulted type parameters may be explicitly set to inferred in type context, and this can lead to the same inference failures with default types that others have observed.

From RFC 213

This section specifies how to interpret a reference to a generic type. Rather than writing out a rather tedious (and hard to understand) description of the algorithm, the rules are instead specified by a series of examples. The high-level idea of the rules is as follows:

• Users must always provide some value for non-defaulted type parameters. Defaulted type parameters may be omitted.
  • The _ notation can always be used to explicitly omit the value of a type parameter:
  • Inside a fn body, any type parameter may be omitted. Inference is used.
  • Outside a fn body, only defaulted type parameters may be omitted. The default value is used.

Motivation: This is consistent with Rust tradition, which generally requires explicit types or a mechanical defaulting process outside of fn bodies.

This text seems mostly accurate, but replace "inside a fn body" with "in expression context", etc.

[tlyu]

Hopefully this example shows some more useful detail. Generic types in in type context must specify all non-defaulted type arguments, but they can be the inferred type _.

#[derive(Default)]
struct S<T, U=u8>(T, U);
fn main() {
    // Type context for let, so one type argument is required
    let x: S<_> = S::default();

    // Without the type annotation, S::default() is equivalent to S<_,_>::default
    // leading to inference failure.
    // let x = S::default();

    // This lets x infer u8 for the type T
    let S(y, z): S<u8, _> = x;
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=75e9cd41dea73a4ed00cd0e34195449e

[tlyu]

#2263 might fix this, but we might also want to add some more detail.