Strange usage of keyword "as" in rust docs


Have a silly question, but what is a strange use of "as" keyword in rust docs for str::parse method - str::parse

<F as FromStr>::Err

Associated source code link is clean and has expected bound format.

Is it something doc specific or where is it described?

Neither A - Keywords - The Rust Programming Language nor Trait and lifetime bounds - The Rust Reference has such example. Failed to find it in doc books either :confused:

Thanks in advance

<F as FromStr>::Err

This expresses that:

  • Type F implements trait FromStr
  • FromStr has an associated type Err
  • Finally, as a whole, it is referring to the associated type specified by impl FromStr for F.

This could also be expressed as F::Err, but the longer form is generally used to prevent the possibility of ambiguity. That could arise if e.g. F implemented a second trait Derp that also has an associated type Err.

I'm not entirely sure what the syntax is officially called, but it seems to share some DNA with UFCS.


It was mostly called UFCS but I guess fully qualified syntax is the term now.


@quinedot @jjpe Tnx for explanation!

Like the phrase:

it seems to share some DNA with UFCS.

cause it is strange to see this at function declaration side instead of call expression, but seem this is it. Mb some kind of rust doc generation rule.

It has nothing to do with rustdoc; this is 100% valid Rust that is used inside real, executable code as-is for accessing specific associated types.

Then I'm confused again =(

Can you give a hint why the docs signature(str - Rust)

pub fn parse<F>(&self) -> Result<F, <F as FromStr>::Err> where
    F: FromStr, 

not the same as in sources ( - source):

 pub fn parse<F: FromStr>(&self) -> Result<F, F::Err> {

Because apparently rustdoc automatically emits fully-qualified syntax, presumably for increased clarity. (As you can observe, it also replaced the inline bound with a where-clause.)

If you spelled out the fully-qualified syntax in actual Rust source code, it would work too.


I believe this falls under "disambiguate the specific trait containing an item" in the description of as in the keyword appendix.

In the reference, what you are looking at there is not a trait bound but a Type, which can be a QualifiedPathInType, which covers this syntax.


Never made an accent on that, now will take into account, reading docs :+1:

Now its 100% clear. Tnx for clarification and example(tbh I tried to made it myself before asking but seems mistyped somewhere cause got compiler claiming "as" misuse)