Closed
Description
I want to be able to write this:
let xs: HashSet<_> = iter.collect();
rather than:
let xs: HashSet<SomeLongType<A, B>> = iter.collect();
I really don't like the idea of having special cases like to_owned_vec
in std::iter
to work around this issue:
fn to_owned_vec(&mut self) -> ~[A] {
self.collect()
}
It doesn't fix the pain in the general case, and encourages using a specific container we special case rather than the right container for the use case. I think this problem will come up frequently with generic code, and the _
syntax would feel right at home with the usage elsewhere.
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
nikomatsakis commentedon Sep 30, 2013
This seems useful and like it would not be too hard to implement -- we just have to be sure to disallow such hints in places where they are not legal. Would we permit you to omit the list of type parameters altogether? (i.e.,
HashSet
or do we requireHashSet<_>
?) Should we extend this to lifetime namesFoo<'_>
? The latter looks really ugly to me :)thestinger commentedon Oct 26, 2013
@nikomatsakis: I think it would probably make sense to start with the minimal feature (individual parameters) and enhance it if compelling use cases come up.
nikomatsakis commentedon Oct 28, 2013
I have had some thoughts in the meantime as part of my work on #4846 and have a larger proposal to make that would encompass this issue.
nikomatsakis commentedon Oct 29, 2013
See proposal for #5121 described here: http://smallcultfollowing.com/babysteps/blog/2013/10/29/intermingled-parameter-lists/
metajack commentedon Dec 22, 2013
+1. I recent ran into some code in Servo that would benefit from this.
Foo<_>
). #12764Kimundi commentedon Mar 14, 2014
This is supported now.
alexcrichton commentedon Mar 14, 2014
Closed by #12764, thanks @Kimundi!