Alternate syntax idea for Return Type Notation

[zyansheep]

Tracking Issue: #109417

Hi, I'm new so let me know if this is not the right forum for this :), the tracking issue noted that it was not for discussion and that people should open up a separate issue.

I had an idea for a more consistent syntax for Return Type Notation. My thought process is as follows:

Given that we already have traits that auto-implement for all functions (FnOnce, Fn, FnMut), which all contain the associated type FnOnce::Output, why not just allow the ability to impose constraints on that associated type as a way to name the output of a function?
For Example:

// Current syntax
trait It {
  fn iter(&self) -> impl Iterator<Item = u32>;
}
fn twice<I: It<iter(): Clone>>(i: I) {}

// new syntax idea:
fn twice<I: It>(i: I)
where
  <I::iter as Fn>::Output: Clone
{}
// could even be shortened further:
fn twice<I: It<iter::Output: Clone>>(i: I) {}

Came up with this idea while watching Jon Gjengset's lecture about impl Traits, so I don't quite understand all the minutiae of the feature, only that this is a problem and it seems to require syntax changes. Is this idea semantically inconsistent? decent but needs modification? totally awesome? What you all think?

[Jules-Bertholet]

@rustbot label C-discussion F-return_type_notation T-lang -needs-triage

[marmeladema]

Been discussed a few times already, like here https://rust-lang.zulipchat.com/#narrow/stream/187312-wg-async/topic/Return-type.20notation.20alternatives

Not sure if this was really ever a potential usable solution because of issues with generics, lifetimes etc but from a syntax perspective, I agree that this looks less surprising / disruptive than the newly introduced RTN.

[zyansheep]

For anyone who stumbles across this issue: Seems like there is already a proposal for something that would allow directly naming the outputs of a function, i.e. named function types :)
https://rust-lang.github.io/impl-trait-initiative/RFCs/named-function-types.html

[oli-obk]

The rust-lang/rust issues are usually not used for feature design discussions. I'm going to close this issue, as related topics have been linked and I'm not sure what we'd use this issue for from now on