Tracking issue for explicit_generic_args_with_impl_trait

[XAMPPRocky]

This is a tracking issue for the explicit_generic_args_with_impl_trait feature gate.
There has not been an RFC for this.

Steps

• Implement (Implement a explicit_generic_args_with_impl_trait feature gate #86176)
• Adjust documentation (Add a note to the turbofish section about impl Trait reference#1212) (see instructions on rustc-dev-guide)
• Stabilization PR (Stabilize explicit_generic_args_with_impl_trait #96868) (see instructions on rustc-dev-guide)

Unresolved Questions

• We should add a bit extra info when there are extra generic args and impl Trait (see Implement a explicit_generic_args_with_impl_trait feature gate #86176 (comment))

Implementation history

• Initital implementation in Implement a explicit_generic_args_with_impl_trait feature gate #86176

---

Background

Currently you cannot specify explicit generic arguments if a function uses impl Trait anywhere its arguments. This is pretty annoying because it heavily restricts what kind of code you can write with functions that use impl Trait compared to what is possible with explicit generics.

This difference between impl Trait and explicit is in my opinion very unintuitive, it feels like you should be able to use them together. It is even mentioned as something in the original tracking issue for impl Trait (#44721) that this would be desirable behaviour, but that there was a decision to hold off for the time being. That issue has been closed for long time, and there hasn't been any follow up as far as I can tell. So I'm opening up a new issue to discuss the feature and hopefully track adding it to the rust compiler.

Examples

#![feature(explicit_generic_args_with_impl_trait)]

fn find_from<I>(iter: impl IntoIterator<Item=impl Into<I>>, is_match: impl Fn(&I) -> bool) -> Option<I> {
    for i in iter {
        let i = i.into();
        if (is_match)(&i) {
            return Some(i)
        }
    }
    
    None
}

fn main () {
    matches!(find_from::<u32>(vec![2u8, 3, 4, 5,], |&x| x == 5), Some(5u32));
}

Related Issues

• Cannot mix impl Trait and explicit generic arguments #71869

[alexxbb]

It's unfortunate that it's not possible, I just hit this issue and it stops me from having a nice API. Here's my use case:

impl Parameter {
    pub fn set<T: ParmType>(&self, value: impl AsRef<[<T as ParmType>::Type]>) -> Result<()> {
        T::set(self.node, &self.info, value)
    }
}

// 
let parm: Parameter;
parm.set::<i32>([1,2,3]);

[jhpratt]

With the only unresolved question listed being diagnostics, is there anything holding up stabilization? Other than a stabilization report of course.

[nbdd0121]

It's still too recent. I only implemented this in June (and merged in August), and I doubt it has been widely used or tested in the ecosystem. This also needs a lang team FCP or RFC.

[jhpratt]

FCP was a given. Time-wise makes sense, though.

[XAMPPRocky]

@nbdd0121 Thanks for implementing this! I've updated the example to use the new feature so there's now at least one use in the wild. 🙂

[WaffleLapkin]

@nbdd0121 What is the path towards stabilization of this feature? Is it old enough yet? 👀

[Wopple]

For anyone afflicted by this, the workaround I found was to specify the type parameters in the value you're binding to. For example:

// instead of this:
let v = f::<u64>();

// do this:
let v: F<u64> = f();

[c410-f3r]

Is there anything left holding up stabilization? I guess enough public testing is not a concern anymore

[nbdd0121]

There is a discussion on Zulip about this: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Stabilization.20of.20.60explicit_generic_args_with_impl_trait.60

[Xiretza]

Can someone link #96868 in the issue description?