Allow type placeholders in trait impls

[cuviper]

Could we allow _ type placeholders in fn signatures of trait impls?

I understand that type inference is not desired on fn signatures in general, but for a trait impl there is no ambiguity. The types must match the trait declaration exactly, but sometimes this can be annoying to actually write out.

For a small example, this is the real BitAnd for HashSet:

impl<'a, 'b, T, S> BitAnd<&'b HashSet<T, S>> for &'a HashSet<T, S>
    where T: Eq + Hash + Clone,
          S: BuildHasher + Default
{
    type Output = HashSet<T, S>;

    fn bitand(self, rhs: &HashSet<T, S>) -> HashSet<T, S> {
        self.intersection(rhs).cloned().collect()
    }
}

I would usually write -> Self::Output for consistency, even though that’s a little longer in this case. There’s no way that I know to do similar for the RHS type parameter though. But my idea is that perhaps we could let these be implicit:

    fn bitand(self, rhs: _) -> _

There’s no ambiguity here for the compiler, since it must match the BitAnd trait anyway. It’s left up to the programmer whether this pseudo-inference is clear, just like choosing whether to use type annotations in let bindings.

Maybe that example is too simple, but I’ve definitely felt at times that I’m needlessly repeating myself with complex types in trait impls.

[cuviper]

I suppose the same could apply to associated const.

[scottmcm]

See also this RFC, postponed as probably needing experimentation: https://github.com/rust-lang/rfcs/pull/2063

[cuviper]

@Mark Twain

There is no such thing as a new idea. It is impossible.

Well, if @dobkeratops is not already experimenting with it, perhaps I shall!

[dobkeratops]

interesting idea from the OP I haven’t experimented sorry; I had a break from rust for a while… I tend to dabble for a bit then frustration accumulates and I revert to other things. I’m back into it now

I think my ‘infer function signatures’ got considered for experimental implementation in the nightly compiler … but that was eventually rejected… it seems the idea is reasonably popular, but not popular enough to make the mainstream.

I’d like to think that actually implementing it would push it along, but consensus is the barrier rather than implementation surely… if they wanted this , it would have worked that way from the outset. Haskell is there as a demonstration of this feature working.

one of the counter arguments was “the IDE can just fill it in for you!” … but an IDE could also show the types in tooltips (useful with other inference), or (even better) ensure the original trait is visible in some navigation panel (I personally usually want the trait itself for reference, i.e. to see how the functions fit together). As for users , they see the original trait more than the impl’s surely.

I think the rust community has a strong majority of “explicit-ists” (i.e on the explicit vs concision scale)

[scottmcm]

Note that the RFC as closed as postponed, not closed.

My understanding of the situation is that there wasn’t willingness to say “yup, this is something we want in all situations”, but that there was some level of interest in how this could simplify things in some situations. Thus the thought was that an implementation in the compiler would allow experimenting with targeted feature gates to see if there were particular situations where eliding the types would simplify and shorten things without compromising on clarity, sortof like were found with lifetime elision.