Tracking Issue for return type notation #109417

compiler-errors · 2023-03-20T23:18:30Z

This is a tracking issue for the feature return type notation specified in rust-lang/rfcs#3654.
The feature gate for the issue is #![feature(return_type_notation)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps

Implement the feature
- Support RTN in associated type bounds (Initial support for return type notation (RTN) #109010)
- Support RTN with (un-)qualified path syntax (e.g. where T::method(): Send) Implement Return Type Notation (RTN)'s path form in where clauses #129629
Author RFC: RFC: Return Type Notation rfcs#3654
Adjust documentation (see instructions on rustc-dev-guide)
Stabilization PR (see instructions on rustc-dev-guide)

Unresolved questions

Does stabilizing T::foo(..) notation as a standalone type create a confusing inconsistency with -> () shorthand?

Experimental results

Part of the goal of the experimental process is to identify benefits but also concerns that need to be addressed in the RFC.

Alternative: typeof syntax.
Concerns raised by lcnr

Implementation history

Initial support for return type notation (RTN) #109010

The text was updated successfully, but these errors were encountered:

Limited syntactic support for experimental return type notations. rust-lang/rust#109417

Limited syntax support for return type notations (RTN) Experimental RTN bound support was recently merged into rustc (rust-lang/rust#109417), the goal of this PR is to allow experimentation without syntax errors everywhere. The parsing implemented currently aligns with the state of the tracking issue, it only supports the form `T<foo(..): Bounds>`. The parser always checks for the presence of `..` to disambiguate from `Fn*()` types, this is not ideal but I didn't want to spend too much time as it is an experimental feature.

VictorBulba · 2023-09-07T17:43:53Z

hey

Is there a way to use this the following way?

#![feature(async_fn_in_trait)]
#![feature(return_type_notation)]

use std::future::Future;

trait Inner: Send + Sync {
    async fn do_async(&self);
}

trait Outer {
    type In: Inner<do_async(): Send>;
} 

fn foo<T>(inner: T::In) -> impl Future + Send
where
    T: Outer,
{
    async move {
        inner.do_async().await;
    }
}

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=d69310a05735ec25356754d4b8bdd708

programmerjake · 2024-07-01T22:25:43Z

somewhat related: we may want to change async functions to return impl IntoFuture instead of impl Future so we can eventually replace Pin with !Move as outlined here -- having Send bounds everywhere on the direct return type which would be impl IntoFuture with that change but not the Future type makes that edition change much more difficult, so imo we should consider alternatives, one of which is somehow making Trait::my_async_fn(..): Send also imply the Future is Send either by adding that bound as a desugaring or requiring the new Pin-less IntoFuture to have Self: Send imply Self::IntoFuture: Send

…estebank Change return-type-notation to use `(..)` Aligns the syntax with the current wording of [RFC 3654](rust-lang/rfcs#3654). Also implements rustfmt support (along with making a match exhaustive). Tracking: * rust-lang#109417

Rollup merge of rust-lang#127092 - compiler-errors:rtn-dots-redux, r=estebank Change return-type-notation to use `(..)` Aligns the syntax with the current wording of [RFC 3654](rust-lang/rfcs#3654). Also implements rustfmt support (along with making a match exhaustive). Tracking: * rust-lang#109417

…kh726 Implement Return Type Notation (RTN)'s path form in where clauses Implement return type notation (RTN) in path position for where clauses. We already had RTN in associated type position ([e.g.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627a4fb8e2cb334863fbd08ed3722c09)), but per [the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#where-rtn-can-be-used-for-now): > As a standalone type, RTN can only be used as the Self type of a where-clause [...] Specifically, in order to enable code like: ```rust trait Foo { fn bar() -> impl Sized; } fn is_send(_: impl Send) {} fn test<T>() where T: Foo, T::bar(..): Send, { is_send(T::bar()); } ``` * In the resolver, when we see a `TyKind::Path` whose final segment is `GenericArgs::ParenthesizedElided` (i.e. `(..)`), resolve that path in the *value* namespace, since we're looking for a method. * When lowering where clauses in HIR lowering, we first try to intercept an RTN self type via `lower_ty_maybe_return_type_notation`. If we find an RTN type, we lower it manually in a way that respects its higher-ranked-ness (see below) and resolves to the corresponding RPITIT. Anywhere else, we'll emit the same "return type notation not allowed in this position yet" error we do when writing RTN in every other position. * In `resolve_bound_vars`, we add some special treatment for RTN types in where clauses. Specifically, we need to add new lifetime variables to our binders for the early- and late-bound vars we encounter on the method. This implements the higher-ranked desugaring [laid out in the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds). This PR also adds a bunch of tests, mostly negative ones (testing error messages). In a follow-up PR, I'm going to mark RTN as no longer incomplete, since this PR basically finishes the impl surface that we should initially stabilize, and the RFC was accepted. cc [RFC 3654](rust-lang/rfcs#3654) and rust-lang#109417

Rollup merge of rust-lang#129629 - compiler-errors:rtn-in-path, r=jackh726 Implement Return Type Notation (RTN)'s path form in where clauses Implement return type notation (RTN) in path position for where clauses. We already had RTN in associated type position ([e.g.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627a4fb8e2cb334863fbd08ed3722c09)), but per [the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#where-rtn-can-be-used-for-now): > As a standalone type, RTN can only be used as the Self type of a where-clause [...] Specifically, in order to enable code like: ```rust trait Foo { fn bar() -> impl Sized; } fn is_send(_: impl Send) {} fn test<T>() where T: Foo, T::bar(..): Send, { is_send(T::bar()); } ``` * In the resolver, when we see a `TyKind::Path` whose final segment is `GenericArgs::ParenthesizedElided` (i.e. `(..)`), resolve that path in the *value* namespace, since we're looking for a method. * When lowering where clauses in HIR lowering, we first try to intercept an RTN self type via `lower_ty_maybe_return_type_notation`. If we find an RTN type, we lower it manually in a way that respects its higher-ranked-ness (see below) and resolves to the corresponding RPITIT. Anywhere else, we'll emit the same "return type notation not allowed in this position yet" error we do when writing RTN in every other position. * In `resolve_bound_vars`, we add some special treatment for RTN types in where clauses. Specifically, we need to add new lifetime variables to our binders for the early- and late-bound vars we encounter on the method. This implements the higher-ranked desugaring [laid out in the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds). This PR also adds a bunch of tests, mostly negative ones (testing error messages). In a follow-up PR, I'm going to mark RTN as no longer incomplete, since this PR basically finishes the impl surface that we should initially stabilize, and the RFC was accepted. cc [RFC 3654](rust-lang/rfcs#3654) and rust-lang#109417

Implement Return Type Notation (RTN)'s path form in where clauses Implement return type notation (RTN) in path position for where clauses. We already had RTN in associated type position ([e.g.](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=627a4fb8e2cb334863fbd08ed3722c09)), but per [the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#where-rtn-can-be-used-for-now): > As a standalone type, RTN can only be used as the Self type of a where-clause [...] Specifically, in order to enable code like: ```rust trait Foo { fn bar() -> impl Sized; } fn is_send(_: impl Send) {} fn test<T>() where T: Foo, T::bar(..): Send, { is_send(T::bar()); } ``` * In the resolver, when we see a `TyKind::Path` whose final segment is `GenericArgs::ParenthesizedElided` (i.e. `(..)`), resolve that path in the *value* namespace, since we're looking for a method. * When lowering where clauses in HIR lowering, we first try to intercept an RTN self type via `lower_ty_maybe_return_type_notation`. If we find an RTN type, we lower it manually in a way that respects its higher-ranked-ness (see below) and resolves to the corresponding RPITIT. Anywhere else, we'll emit the same "return type notation not allowed in this position yet" error we do when writing RTN in every other position. * In `resolve_bound_vars`, we add some special treatment for RTN types in where clauses. Specifically, we need to add new lifetime variables to our binders for the early- and late-bound vars we encounter on the method. This implements the higher-ranked desugaring [laid out in the RFC](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds). This PR also adds a bunch of tests, mostly negative ones (testing error messages). In a follow-up PR, I'm going to mark RTN as no longer incomplete, since this PR basically finishes the impl surface that we should initially stabilize, and the RFC was accepted. cc [RFC 3654](rust-lang/rfcs#3654) and rust-lang/rust#109417

slanterns · 2024-09-27T21:10:02Z

The parentheses clearly indicates it's the eval result (output, return type) of the function, not the function itself.

…=pnkfelix Robustify and genericize return-type-notation resolution in `resolve_bound_vars` rust-lang#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)). However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect. This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds. Tracking: - rust-lang#109417

maboesanman · 2024-11-18T17:36:59Z

I wonder if a more discoverable and comfortable syntax for this idea would be the ReturnType<F> notation from typescript. It may make the syntax more uniform in where clauses, and I believe there is some precedent for "magic" generics like this in the rust language, specifically dyn metadata.

An example then would be:

trait SomeTrait {
    async fn some_func()
}

impl<T> SomeStruct<T> 
where
    T: SomeTrait,
    ReturnType<T::some_func>: SomeBound,
{

}

I think it would be usable in all the same places as T::some_func(..): style bounds, but it establishes a pattern that is more readable (in my opinion) and easier to extend if we needed to express other type transformations (for example, the tuple type of a function's arguments).

If we want to indicate these are not regular generic types, something like @ReturnType<..> or some other identifying character could be used to indicate the operation is more complex than generic instantiation.

In some sense, generic instantiation is a function that takes types and produces types, and that's what the return type syntax is trying to do. The only difference is that the output is less complex than the input, which is usually not true for generics.

(Originally I mistakenly commented this on the initial support issue before, my mistake)

onestacked · 2024-11-18T20:20:01Z

How would that look for dyn Trait (or impl Trait) like:
dyn Trait<method(..): Send>

I think
dyn Trait<ReturnType<method>: Send>>
is a bit weird.

maboesanman · 2024-11-18T21:23:34Z

How would that look for dyn Trait (or impl Trait) like:
dyn Trait<method(..): Send>

I think
dyn Trait<ReturnType<method>: Send>>
is a bit weird.

I don't think bounds on associated types are supported in that way are they? In that situation I think you'd do a separate trait for use with dyn that is auto implemented and has the specified bounds.

How is that resolved with the currently proposed syntax?

compiler-errors · 2024-11-18T21:38:54Z

Return type notation is definitely supported in associated type bound syntax. It's not allowed in dyn, but I expect it could be in the future. I don't think requiring a user to make a new trait (even if we had trait aliases) is an acceptable solution.

I don't think that the proposed ReturnType<T> really simplifies things. It gives a perception of being just a regular type, but frankly it's really weird on its own. Firstly, ReturnType<T::method> is in general a higher ranked type. It'll be some for<...> over all of the lifetime generics of the method it's referring to -- That's why RTN is only allowed in where clauses today.

Secondly, the generic parameter it would take (e.g. T::method) is not in the same namespace as types, meaning that ReturnType would need to a completely different type construct so that the name resolver can understand it correctly. Since we're overloading regular "path" type (e.g. Foo<T>) syntax for this, it definitely does not make it easy to implement, and even worse I fear it doesn't help with the readability of the bound either.

Setting aside a totally different syntax for RTN is part of what makes it easier to implement and understand. It's distinct.

Also, I don't really understand the parallel to DynMetadata; that's just a regular type that takes a generic type. That's not really magical.

maboesanman · 2024-11-18T23:41:59Z

I suppose my intention is to highlight that a type-system level construct for specifying the return type of a function type is an operation that belongs to class of type-manipulations which may make sense to anticipate growing in number.

Expressing "the return type of a function type" has a very specific syntax right now that may make the addition of something like "the tuple type of arguments to a function type", or even more exotic things like "the tuple you get when you omit the first item" necessarily inconsistent from a syntax perspective.

My suggestion is not that the proposed syntax is bad on its own, but that opting for a more general "function that operates on types" style syntax would be more extensible should those other extensions be added later. If the type system becomes more generally expressive, having a very application specific syntax for this feature may result in forced future language inconsistency.

This syntax change suggestion could be implemented in an edition (I think?) should those other extensions be considered, so I'm probably bike-shedding here anyway.

…jgillot Robustify and genericize return-type-notation resolution in `resolve_bound_vars` rust-lang#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)). However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect. This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds. Tracking: - rust-lang#109417

…=cjgillot Robustify and genericize return-type-notation resolution in `resolve_bound_vars` rust-lang#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)). However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect. This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds. Tracking: - rust-lang#109417

Rollup merge of rust-lang#132047 - compiler-errors:rbv-rtn-cleanup, r=cjgillot Robustify and genericize return-type-notation resolution in `resolve_bound_vars` rust-lang#129629 implemented return-type-notation (RTN) in its path form, like `where T::method(..): Bound`. As part of lowering, we must record the late-bound vars for the where clause introduced by the method (namely, its early- and late-bound lifetime arguments, since `where T::method(..)` turns into a higher-ranked where clause over all of the lifetimes according to [RFC 3654](https://rust-lang.github.io/rfcs/3654-return-type-notation.html#converting-to-higher-ranked-trait-bounds)). However, this logic was only looking at the where clauses of the parent item that the `T::method(..)` bound was written on, and not any parent items. This PR generalizes that logic to look at the parent item (i.e. the outer impl or trait) instead and fixes a (debug only) assertion as an effect. This logic is also more general and likely easier to adapt to more interesting (though likely very far off) cases like non-lifetime binder `for<T: Trait> T::method(..): Send` bounds. Tracking: - rust-lang#109417

compiler-errors added the C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC label Mar 20, 2023

compiler-errors changed the title ~~Tracking Issue for Return Type Notation (feature(return_type_notation))~~ Tracking Issue for Return Type Notation (#![feature(return_type_notation)]) Mar 20, 2023

nikomatsakis mentioned this issue Mar 21, 2023

Initial support for return type notation (RTN) #109010

Merged

tamasfe added a commit to tamasfe/rust-analyzer that referenced this issue Apr 1, 2023

feat(syntax): RTN in bounds

0b9c0c5

Limited syntactic support for experimental return type notations. rust-lang/rust#109417

tamasfe mentioned this issue Apr 1, 2023

Limited syntax support for return type notations (RTN) rust-lang/rust-analyzer#14465

Merged

Noratrieb added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Apr 5, 2023

jackh726 added the F-return_type_notation `#[feature(return_type_notation)]` label Aug 21, 2023

workingjubilee mentioned this issue Sep 15, 2023

Stabilize async fn and return-position impl Trait in trait #115822

Merged

Dirbaio mentioned this issue Oct 15, 2023

io-async: fix warnings for latest nightly (1.75.0) rust-embedded/embedded-hal#515

Merged

zyansheep mentioned this issue Oct 30, 2023

Alternate syntax idea for Return Type Notation #117375

Closed

GlenDC mentioned this issue Nov 26, 2023

decide what to do with tower plabayo/rama#5

Closed

yoshuawuyts mentioned this issue Jan 8, 2024

Rename AsyncIterator back to Stream, introduce an AFIT-based AsyncIterator trait #119550

Draft

fmease added S-tracking-impl-incomplete Status: The implementation is incomplete. B-experimental Blocker: In-tree experiment; RFC pending, not yet approved or unneeded. labels Feb 28, 2024

fmease changed the title ~~Tracking Issue for Return Type Notation (#![feature(return_type_notation)])~~ Tracking Issue for return type notation Apr 16, 2024

compiler-errors mentioned this issue Jun 28, 2024

Change return-type-notation to use (..) #127092

Merged

kennytm mentioned this issue Jul 2, 2024

Async closures rust-lang/rfcs#3668

Merged

traviscross mentioned this issue Jul 12, 2024

RFC: Return Type Notation rust-lang/rfcs#3654

Merged

traviscross added B-RFC-approved Blocker: Approved by a merged RFC but not yet implemented. and removed B-experimental Blocker: In-tree experiment; RFC pending, not yet approved or unneeded. labels Jul 13, 2024

compiler-errors mentioned this issue Aug 26, 2024

Implement Return Type Notation (RTN)'s path form in where clauses #129629

Merged

analogrelay mentioned this issue Sep 11, 2024

Client methods traits should desugar async functions to return impl Future Azure/azure-sdk-for-rust#1796

Open

carloskiki mentioned this issue Sep 21, 2024

tower-sessions-core crate rework maxcountryman/tower-sessions#218

Closed

This comment has been minimized.

Sign in to view

traviscross mentioned this issue Nov 6, 2024

Robustify and genericize return-type-notation resolution in resolve_bound_vars #132047

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Tracking Issue for return type notation #109417

Tracking Issue for return type notation #109417

compiler-errors commented Mar 20, 2023 •

edited

Loading

VictorBulba commented Sep 7, 2023

programmerjake commented Jul 1, 2024

This comment has been minimized.

slanterns commented Sep 27, 2024 •

edited

Loading

maboesanman commented Nov 18, 2024

onestacked commented Nov 18, 2024

maboesanman commented Nov 18, 2024

compiler-errors commented Nov 18, 2024 •

edited

Loading

maboesanman commented Nov 18, 2024

Tracking Issue for return type notation #109417

Tracking Issue for return type notation #109417

Comments

compiler-errors commented Mar 20, 2023 • edited Loading

About tracking issues

Steps

Unresolved questions

Experimental results

Implementation history

VictorBulba commented Sep 7, 2023

programmerjake commented Jul 1, 2024

This comment has been minimized.

slanterns commented Sep 27, 2024 • edited Loading

maboesanman commented Nov 18, 2024

onestacked commented Nov 18, 2024

maboesanman commented Nov 18, 2024

compiler-errors commented Nov 18, 2024 • edited Loading

maboesanman commented Nov 18, 2024

compiler-errors commented Mar 20, 2023 •

edited

Loading

slanterns commented Sep 27, 2024 •

edited

Loading

compiler-errors commented Nov 18, 2024 •

edited

Loading