Document fully-qualified syntax in as' keyword doc

[fpdotmonkey]

No description provided.

[rustbot]

r? @ibraheemdev

rustbot has assigned @ibraheemdev.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Are there any other std traits where this is commonly needed? A small downside with this example is that this is something that should just be written u32::from(my_thing) 🙂

[fpdotmonkey]

It could be a thing with Debug vs Display::fmt. That said, <Self as fmt::Debug>::fmt(self, f) is semantically identical, longer, and weirder than fmt::Debug::fmt(self, f). io::Write::write_fmt and fmt::Write::write_fmt have the same problem.

Into<T> is nice since it's reasonably likely that users will encounter a message from rustc that they should use the fully-qualified path as in these docs (though by all rights, it should suggest that you should use T::from(self)).

An other option would be to make a contrived exampled like is done in the Rust book. E.g.,

struct Person;

trait MetalHead {
    fn head_bang();
}
trait SalaryWorker {
    fn head_bang();
}
impl MetalHead for Person { ... }
impl SalaryWorker for Person { ... }

// 9 to 5
<Person as SalaryWorker>::head_bang();
// 5 to 9
<Person as MetalHead>::head_bang();

But of course coming up with a more useful example is hard since associated items don't usually overlap and there's usually sufficient type information to remove the ambiguity this doc is trying to highlight. The optimal example would be either a pair of trait methods that return a generic type like Into::<T>::into, or a pair of static trait methods. Short of what's here already, I can't find anything like that.

[fpdotmonkey]

I've changed it so there's a footnote saying that it'd be better to use T::from(my_thing) and that the example is imperfect.

[ibraheemdev]

Just a small nit.

Suggested change

	/// _fully qualified path_, a means of clarifying ambiguous method calls, constants, and types.
	/// If you have a type which implements two traits with identical method names (e.g.
	/// _fully qualified path_, a means of clarifying ambiguous associated items. For example,
	/// if you have a type which implements two traits with identical method names (e.g.

[fpdotmonkey]

Happy to make this change, but isn't this a bit less useful? As it was, it tells you exactly which syntactic objects this syntax can be used with, whereas the change demands that you know about the associated item abstraction. Realistically, if I'm someone who's reading the keyword docs, I'm probably a rust beginner and probably not familiar with this abstraction.

Perhaps "a means of clarifying ambiguous associated items, i.e. methods, constants, and types. For example," would be a good compromise?

[fmease]

(I'm not the primary reviewer) if you end up listing the three kinds of associated item, please substitute method with function or with function (includes methods). Methods are only a subset of associated functions.

[ibraheemdev]

r=me after the nit.

[ibraheemdev]

@bors r+ rollup

[bors]

📌 Commit 15f73ab has been approved by ibraheemdev

It is now in the queue for this repository.

[fmease]

@bors r-

[ibraheemdev]

r? fmease

[rustbot]

fmease is currently at their maximum review capacity.
They may take a while to respond.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[fmease]

@bors r=ibraheemdev,fmease

[bors]

📌 Commit 1485e78 has been approved by ibraheemdev,fmease

It is now in the queue for this repository.