Allow `impl Trait` in more contexts

[spinda]

Currently impl Trait is only allowed as the return type of a free-standing functions and inherent methods. I would like to see it opened to a few more positions.

Local variable signatures

let x: impl Foo = bar();

can already be simulated by:

fn wrapper<T: Foo>(x: T) -> impl Foo { x }
let x = wrapper(bar());

Also,

let x: Option<impl Foo> = bar();

If bar returns Option<Baz>, Baz would be checked for an implementation of Foo.

Parameters of free-standing functions and methods

fn bar(x: impl Foo) { }

can be equivalent to:

fn bar<T: Foo>(x: T) { }

Furthermore,

fn bar(x: Option<impl Foo>) { }

can be equivalent to:

fn bar<T: Foo>(x: Option<T>) { }

This cuts down a bit on boilerplate.

Other positions in return types of free-standing functions and methods

fn bar() -> Option<impl Foo> { }

[eddyb]

cc #105 #1522 #1738 rust-lang/rust#34511

[archshift]

For local variables, is there a use-case for using impl Trait versus a (re)borrow?

let x: &Foo = &bar();

[spinda]

What if I want to move my value into `x`, instead of borrowing it?

[KalitaAlexey]

@spinda,
You can just omit the type.
Why can't you?

[spinda]

I may want to provide an explicit type annotation to clear up some ambiguity, for example, a type parameter that can't be inferred.

Really, I would like to remove as much special-casing of where impl Trait can be used as possible, excluding the ban on using it in trait definitions to avoid unintentionally introducing HKT.

[eddyb]

@spinda Keep in mind the semantics can differ a lot between those positions. And this always worked:

fn bar() -> Option<impl Foo> { }

[spinda]

@eddyb So it does, thanks. I was under the impression that only fn bar() -> impl Foo was allowed.

[oli-obk]

Couldn't all locations that so far are compilation failures due to Sized bounds simply act like impl Trait. So impl would only be required for the given semantics in ?Sized situations. This would allow fn bar() -> Foo and let x: Foo = ... and so on, but be backwards compatible, since Box<Foo> would still be dynamic, and Box<impl Foo> could be used to differentiate.

[burdges]

As an alternative, one could use an associated output type for functions, ala f::Output, although certainly that's less ergonomic in some cases.

I'm nervous about taking fn bar(x: Option<impl Foo>) { } to be equivalent to fn bar<T: Foo>(x: Option<T>) { }. Would you want to do that for closures too? In other contexts, I read impl Trait as being more _::Output where the compiler must infer the fn name _ so that _::Output matches the trait bounds.

That said, there are certainly situations where you can simplify presentation using that interpretation. In particular, you can make users view your tiers of type parameters in a two tiered way, as happens with several HashMap methods, ala

fn meow<K: Hash+Eq>(q: impl Borrow<K>) -> ...

[Ixrec]

My understanding of impl Trait was that it has fundamentally different semantics from type parameters, namely: the concrete type that a type parameter represents is determined by the function's call site, while the concrete type that an impl Trait represents is decided by the function's implementation. Given that, it seems nonsensical to put "impl Trait" in all of these other parts of the grammar as if it was merely syntactic sugar for ordinary type parameters.

For instance, under this RFC, would the desugaring of fn foo(x: Option<impl Foo>) -> impl Foo { } be a function with one type parameter or two? And which of those concrete types would be determined by the call site versus determined by the implementation? (it doesn't make sense for the concrete type of a function's arguments to be unknowable at any of its call sites, right?)

[burdges]

I suppose your let x: impl Foo = y.bar(); actually comes into play if we have y satisfying Bar<u64>+Bar<usize> along with

trait Foo { .. }

trait Bar<R> {
    type Res;
    fn bar(self) -> Res;
}

impl Bar<u64> for SomeType {
    type Res = RealType;
    fn bar(self) -> RealType { .. }
}

impl Bar<usize> for SomeType {
    type Res = impl Foo; 
    fn bar(self) -> impl Foo { .. }
}

because now the impl Foo disambiguates which impl's bar method.

I imagine this type Res = impl Foo; is "concrete" enough not to be equivalent to HTKs in the sense that you only know its an impl Foo after specifying that you're using SomeType, but maybe this makes type inference tricky somehow. Yup see rust-lang/rust#34511 (comment)

[torkleyy]

impl Trait for local variable

I think there definitely are some use cases and I also think this should be implemented.

impl Trait for function parameters

I agree, it removes some boiler plate; however, I don't think this should be implemented.

I think that having

fn foo<T: Bar>(value: T) {
}

makes it pretty obvious that this function will have a separate implementation for every type T it is called with, whereas in

fn foo(value: impl Bar) {
}

this isn't really obvious. Additionally, it has many limitations:

• You can not have a where (like where Option<T>: Debug)
• This also means your function parameters are getting pretty long and not as clear (I see that it is somehow also easier to read because you do not have to look up T in the where clause to see what it is bound on)
• It may be harder for the compiler to talk about certain types when giving you an error message
• You cannot use this type
  • For a return type
  • For multiple parameters: Are the types of x and y the same in fn foo(x: impl Bar, y: impl Bar) or are can they be different?

Also, this usage is very different from impl Trait as return type:

fn foo() -> impl Foo {}

means that foo will return an implementation of the trait Foo and it also means that it will always be the same concrete type but the implementer didn't want to or can't write out the exact type (because a closure was used for example).

But using impl Trait as a parameter type now is completely different from that. It means that any type that matches Trait is allowed, so that the type can be different for the next call of that function.

So in the end impl Trait as a parameter type and impl Trait as return type have different semantics which would be pretty confusing. Plus it isn't really much shorter than writing out the type parameter and it also means that you don't have the type named.

That's why I only agree with implementing it for local variables but not for function parameters.

[burdges]

I think fn foo(value: impl Bar) being sugar for fn foo<T: Bar>(value: T) sounds premature because :

If I understand, impl Trait is currently an "existentially quantified" type, meaning the details are hidden but the type compiler find the real type that works, while T is a universally quantified type in fn foo<T: Bar>(value: T). Any argument for this sugar approach must claim that existentially quantified do not make sense as function arguments. That sounds quite strong.

In particular, anything you'd do with impl Trait in argument position is likely to correspond with what you'd do in struct/enum member position. At minimum I could imagine using impl Trait as a form of cheap associated type for struct/enum or something.

[burdges]

We could use type .. = impl Trait as a lightweight type inference powered wrapper type, like say:

pub type HasherUsedHere = impl Hasher;
fn foo(..) -> HasherUsedHere, ..) { ... }
fn bar(&mut HasherUsedHere, ..) { ... }