Un-greppability of impls

[alexcrichton]

I just realized that while rust source code is traditionally very greppable, finding implementations of a trait or struct is a diffcult thing to do.

In theory, I want to do grep "impl Type" to see what implements it, but type parameters throw a wrench into this by having lots of intermediate characters.

I realized this while reading over some rustdoc headers, and for example it's actually still a little difficult to see what traits a HashMap implements: http://static.rust-lang.org/doc/master/std/hashmap/struct.HashMap.html. There's a lot of noise going on there with the declaration of all the type parameters.

I was thinking of changing rustdoc to do something like impl Trait for Type where <Type, Parameters> which isn't the worst syntax, but it certainly loses our left-to-right readability.

I'm nominating this not because I think it's incredibly urgent to fix, but this does seem like a little bit of a wart which is only fixable before 1.0. I also may be the only one who finds this odd!

[catamorphism]

+1 -- Maybe this could be accomplished without changing syntax, by making rustdoc add in a "see all impls of this trait" link as an annotation on traits?

[catamorphism]

See http://www.haskell.org/ghc/docs/latest/html/libraries/base-4.6.0.1/Control-Monad.html for one way to present this info. The Haskell library docs have a list of known instances, with links to them, after every type class.

[alexcrichton]

Rustdoc actually currently has a list of implementors of a trait down at the bottom of the page for each trait, so I'm not too worried about that. And it's certainly the case that rustdoc can adopt whatever syntax it wants for displaying traits, but there is something to say for it being the same as the rust source that implements the trait.

[jfager]

So, for instance,

impl<K: Hash + Eq, V> Map<K, V> for HashMap<K, V> 

would become

impl Map<K, V> for HashMap<K, V> where <K: Hash + Eq, V>

?

[alexcrichton]

What I would want to strive for is to be able to run git grep "impl Map" to find all implementations of the Map trait, I don't think my suggestion for a syntax is really all that good.

[jfager]

Possibly dumb question, but is there a reason for not just

impl Map<K, V> for HashMap<K: Hash + Eq, V>

? Plain impls could be similar:

impl HashMap<K: Hash + Eq, V>

Edit: n/m, it is a dumb question. Ambiguous between placeholder name and actual type name.

[bill-myers]

One can just use
grep 'impl.*Trait.*for'

Alternatively, I'd suggest something like:

with<T> impl Trait<Foo<T>> for Map<Bar<T>>
{
}

And this syntax could also support a block with many impls:

with<T:Clone>
{
impl Trait<T> for Struct<T>
{
}

impl Trait2<T> for Struct<T>
{
}
}

[catamorphism]

No milestone, low priority

[pnkfelix]

I agree with @bill-myers : One can just grep for impl.* Trait .*for. I don't think the changes that I've seen here pay for themselves.

[nikomatsakis]

I think marking this bug as "no milestone, low priority" is kind of pointless, since it's a "now or never" sort of change. If we're not going to mark this as a 1.0 bug, I think we'd be better off just to close. (I personally am not inclined to change the syntax, which seems consistent with other declarations)

[SiegeLord]

Rust's grammar is not regular, so it will never be greppable in the general case. You're going to be finding things inside comments, strings, type bounds etc. The rustdoc issue seems to me a problem that can be solved stylistically and/or with better code highlighting.

For example, you could alter the coding style to place the impl on a separate line from the rest of the declaration:

impl<A: ToStr + Hash + Eq, B: ToStr>
ToStr for HashMap<A, B>

Or you could emphasize the <>'s to visually subdivide the declaration (can't convey this using Markdown), or emphasize the type and trait. I think there is a lot of room for improvement from a visual presentation side of things. I don't think the difficulty in reading the current CSS/HTML should be a guiding principle behind syntax changes.

[alexcrichton]

Closing, this isn't going to change.