[impl Trait] Should we allow `impl Trait` after `->` in `fn` types or parentheses sugar?

[nikomatsakis]

RFC 1951 disallowed uses of impl Trait within Fn trait sugar or higher-ranked bounds. For example, the following is disallowed:

fn foo(f: impl Fn(impl SomeTrait) -> impl OtherTrait)
fn bar() -> (impl Fn(impl SomeTrait) -> impl OtherTrait)

This tracking issue exists to discuss -- if we were to allow them -- what semantics they ought to have. Some known concerns around the syntax are:

• Should the () switch from existential to universal quantification and back?
  • I think the general feeling here is now "no", basically because "too complex".
• If HRTB were introduced, where would we (e.g.) want impl OtherTrait to be bound?

For consistency, we are disallow fn(impl SomeTrait) -> impl OtherTrait and dyn Fn(impl SomeTrait) -> impl OtherTrait as well. When considering the questions, one should also consider what the meaning would be in those contexts.

[est31]

Should we allow impl Trait after -> in fn types or parentheses sugar?

fn(impl SomeTrait) -> impl OtherTrait

How is impl Trait meant to work in function pointers? Do you mean Fn instead of fn?

[nikomatsakis]

@est31

How is impl Trait meant to work in function pointers? Do you mean Fn instead of fn?

I meant fn -- this basically gets at the heart of the question, which is the scoping of impl Trait. In particular, one might expect that

fn foo(x: fn(impl Trait))

would desugar to

fn foo<T: Trait>(x: fn(T))

Of course -- as you righly point out -- if the T were going to be scoped to x -- sort of like for<T: Trait> fn(T) -- we couldn't actually compile that with monomorphization (though we could do it with Fn traits, potentially).

[est31]

@nikomatsakis I see, thanks for the clarification!