# Implicit generics

**URL:** <https://internals.rust-lang.org/t/implicit-generics/21311>\
**Category:** language design\
**Created:** [August 3, 2024, 12:58pm UTC](https://internals.rust-lang.org/t/implicit-generics/21311 "2024-08-03T12:58:12Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\
**Post date:** [August 3, 2024, 8:22pm UTC](https://internals.rust-lang.org/t/implicit-generics/21311/4 "2024-08-03T20:22:33Z")

</div>

Metaprogramming like frunk does is sort of a special case; most code won't use extra type inference variables the way that frunk does. But also, at least in theory, the example signature there _could_ also be written as

```rust
fn print_height<'a, A>(obj: &'a A) -> String
where
    &'a A: PathTraverser<Path!(dimensions.height), impl Sized, TargetValue = &'a usize>
        + PathTraverser<Path!(dimensions.unit), impl Sized, TargetValue = &'a SizeUnit>,

```

except that `impl Trait` isn't permitted in this position because it's very unclear whether this is a "universal" type variable (chosen by the caller, implementation must work for any possible choice) or an "existential" type variable (chosen by the implementation, caller must work for any\[1\] possible choice).

The more specific case of your example

```rust
fn foo(foo: impl Foo<impl Sized>)

```

which is "nested `impl Trait`" rather than "`impl Trait` in bounds" might be made permissable in the future, since it's less unclear which direction the `impl` will make opaque, but that's still a good ways off. IIRC, a main question is handling `impl Fn() -> impl Trait`, as it _isn't_ clear how return position inside argument position impl trait ("RPIAPIT" 🙃) should behave\[1:1\], and to the type system that's just an associated type equality bound (i.e. `impl Fn<(), Output=impl Trait>`).

There's also [a different thread](https://internals.rust-lang.org/t/allow-in-impl-blocks-when-the-generic-arugment-doesnt-matter/21300) currently open about using `_` as a kind of minimally bound type hole in a signature, which could be somewhat related to the desire here.

* * *

1. The answer is probably that it should be an associated type trait bound (e.g. perhaps `impl Fn<(), Output: Trait>`) rather than an equality bound, but defining a composable definition of _why_ that's the desugar is far from straightforward.

---

_[View the full topic](https://internals.rust-lang.org/t/implicit-generics/21311)._