Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

support partial type hints #9508

Closed
thestinger opened this issue Sep 26, 2013 · 7 comments
Closed

support partial type hints #9508

thestinger opened this issue Sep 26, 2013 · 7 comments
Labels
A-typesystem Area: The type system

Comments

@thestinger
Copy link
Contributor

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.

@nikomatsakis
Copy link
Contributor

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 require HashSet<_>?) Should we extend this to lifetime names Foo<'_>? The latter looks really ugly to me :)

@thestinger
Copy link
Contributor Author

@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
Copy link
Contributor

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
Copy link
Contributor

@metajack
Copy link
Contributor

+1. I recent ran into some code in Servo that would benefit from this.

bors added a commit that referenced this issue Mar 14, 2014
# Summary

This patch introduces the `_` token into the type grammar, with the meaning "infer this type".
With this change, the following two lines become equivalent:
```
let x = foo();
let x: _ = foo();
```
But due to its composability, it enables partial type hints like this:
```
let x: Bar<_> = baz();
```

Using it on the item level is explicitly forbidden, as the Rust language does not enable global type inference by design.

This implements the feature requested in #9508.

# Things requiring clarification

- The change to enable it is very small, but I have only limited understanding of the related code, so the approach here might be wrong.
  - In particular, while this patch works, it does so in a way not originally intended according to the code comments.
- This probably needs more tests, or rather feedback for which tests are still missing.
- I'm unsure how this interacts with lifetime parameters, and whether it is correct in regard to them.
- Partial type hints on the right side of `as` like `&foo as *_` work in both a normal function contexts and in constexprs like `static foo: *int = &'static 123 as *_`. The question is whether this should be allowed in general.

# Todo for this PR

- The manual and tutorial still needs updating.

# Bugs I'm unsure how to fix

- Requesting inference for the top level of the right hand side of a `as` fails to infer correctly, even if all possible hints are given:

  ```
.../type_hole_1.rs:35:18: 35:22 error: the type of this value must be known in this context
.../type_hole_1.rs:35     let a: int = 1u32 as _;
                                           ^~~~
```
@Kimundi
Copy link
Member

Kimundi commented Mar 14, 2014

This is supported now.

@alexcrichton
Copy link
Member

Closed by #12764, thanks @Kimundi!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

5 participants