-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Allow less than all the generic parameters to be specified #1989
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
Comments
It seems to me that that was decided against due to type defaults? has anything else happened with those? |
Would implementing support for this be enough? fn foo<T, U>(u: U) -> T
where T: From<U>
{
From::from(u)
}
fn main() {
println!("{}", foo::<u16, ..>(0u16));
} This would signal at the call site "more generic params to come" but also allow longer chains of generic parameters to be omitted. (it would allow you to have a function |
It seems like this would only work if you only need to specify a prefix of the list of types, right? If you only wanted to specify foo::<_, u16>(0u16) Perhaps a more flexible (and more dangerous) option would be to make the behavior "hey, compiler, if you get stuck solving for a type, take this as a hint"... I don't know how this would work in general, though... |
Haven't type parameter defaults been phased out for functions? As a motivation, I would like this for cases where I have one 'important' type parameter that may not be elided and a bunch that can be: fn request<TDocument TIndex, TId>(index: TIndex, id: TId) -> RequestBuilder<TDocument>
where TIndex: Into<Index>,
TId: Into<Id>
{
}
let req = request::<MyDocument>("some_index", "some_type"); In the above case I don't mind only being able to elide parameters on the right of ones that are explicitly specified. |
@KodrAus right, that's what I'm talking about. The whole |
As we closed #2176 pending more investigation, I'm also closing this in the interest of having fewer open issues. (This does not mean that we do / don't want this feature). |
I want the second one to work (and to be equivalent to the third). There's no real reason for it not to, and it does work in C++.
The text was updated successfully, but these errors were encountered: