Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

async T and gen T types #3628

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

joshtriplett
Copy link
Member

@joshtriplett joshtriplett commented May 7, 2024

Allow the syntax async T and gen T as types, equivalent to
impl Future<Output = T> and impl Iterator<Item = T> respectively. Accept
them anywhere impl Trait can appear.

This RFC was inspired by a few different needs.

First, writing large numbers of functions that manipulate iterators or futures.
Having a shorthand for the type makes function signatures much clearer.

And second, providing one part of a general solution that gives people the
benefits of async fn in all contexts, and for new constructs like gen.

Co-authored-by: Eric Holk

Rendered

Co-authored-by: Eric Holk <[email protected]>
@joshtriplett joshtriplett added the T-lang Relevant to the language team, which will review and decide on the RFC. label May 7, 2024
@kennytm kennytm mentioned this pull request May 7, 2024
[explanation]: #explanation

In any context where you can write an `impl Trait` type, you can write
`async T`, which desugars to `impl Future<Output = T>`:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this won't work when lifetime needs to be captured right?

use std::future::Future;

async fn g(a: &str) -> usize {
    a.len()
}

fn h(a: &str) -> impl Future<Output = usize> + '_ {
//                                           ^~~~
    async { a.len() } 
}

I suppose #3617 will need to be a prerequisite in any more complex situations assuming you don't want to utter the impl word.

fn i1(a: &str) -> use<'_> async usize {
//                ^~~~~~~
    async { a.len() }
}
fn i2(a: &str) -> use<> async usize {
//                ^~~~~
    async { 0 }
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would expect that in any context where you could write impl Future<Output = usize> + '_, you could write async usize + '_. You could also use use.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we write async async async async usize + '_ the lifetime attach to the outermost async?

Type Desugared
async async usize + 'a impl Future<Output = impl Future<Output = usize>> + 'a
(maybe require async (async usize) + 'a, like &(dyn Trait + 'a))
async (async usize + 'a) impl Future<Output = impl Future<Output = usize> + 'a>
async impl Send + 'a impl Future<Output = impl Send> + 'a
async (impl Send + 'a) impl Future<Output = impl Send + 'a>

Since that + '_ is part of the TypeParamBounds syntax does this mean async usize + Send is allowed 🤔

@tmandry
Copy link
Member

tmandry commented May 7, 2024

An alternative I'd like to see explored is impl Future -> T and impl Iterator yields T. Definitely more wordy, but also less opaque, more extensible – and generalizing the existing syntax for Fn traits.

@dev-ardi
Copy link

dev-ardi commented May 8, 2024

An alternative I'd like to see explored is impl Future -> T and impl Iterator yields T. Definitely more wordy, but also less opaque, more extensible – and generalizing the existing syntax for Fn traits.

That would open the conversation of extending that syntax to all traits with only one associated type.
Something like impl Trait<T>

@traviscross
Copy link
Contributor

traviscross commented May 8, 2024

@eholk and I discussed some points related to this draft, and I know that he's working alongside joshtriplett on incorporating them. As these same items have come up in discussions with others, though, I'll go ahead and mention them here to reduce duplication:

  • In argument position (and perhaps in some places in bounds), we might consider whether this should desugar into impl IntoFuture/impl IntoIterator instead of impl Future/impl Iterator. Many, probably most, functions would be better served accepting the Into* variants. We wouldn't want to push people away from doing the right thing here by making it much more comparatively verbose to write that.
  • We might consider removing gen T from this RFC and adding it instead as a future possibility (or alternatively, adding an unresolved question for which trait to use in the desugaring for gen T). Since we haven't yet worked out the situation with respect to pinning and self-referential gen blocks, it's not yet clear that gen should exactly equal Iterator. As we did in RFC 3513, we probably want to leave space here.
  • We might want to discuss the placement of use<..> (RFC 3617) in this syntax, e.g. async use<..> T.
  • We might want to discuss the subtle relationship between async T in this syntax and the pending syntax for async traits, e.g. async FnMut() -> ().
  • We might want to discuss whether this syntax, combined with doing async traits, would foreclose the possibility of supporting bare trait syntax (but desugaring it to impl Trait rather than to dyn Trait as was done in earlier editions). It's not clear whether or not we'd ever want to do this, but the possibility had been left open.
  • As @tmandry mentioned, @eholk has an alternate proposal that he described in this post for impl IntoFuture -> u8 syntax (and generalizations, including supporting this syntax for arbitrary traits). It would be interesting to consider the relative merits of that along with the proposal here.

In talking this over with @yoshuawuyts, we pondered this question also:

  • This RFC is proposing async T as syntax for an opaque future type. If we were to do this, would we want some analogously impl-eliding syntax for an opaque future closure type, i.e. for impl async Fn/*{Once,Mut}/*() -> T (i.e. the output of an async |x| { .. } block), or for an opaque generator closure type?

@scottmcm
Copy link
Member

scottmcm commented May 9, 2024

This reminds me of the old complaint about TAIT that it means that type G<T> = impl Iterator<Item = T>; doesn't work in a copy-paste way for APIT.

Should there be a way that users can make their own aliases that work for RPIT and APIT? Or is this only useful for Iterator and Future?

Feels at least plausible that I'd want to make a

type[not_TAIT] Task<T> = impl Future<Output = T> + Send + 'static;

or something.

[prior-art]: #prior-art

We have special syntaxes for arrays in types, `[T]` and `[T; N]`, which are
evocative of the corresponding value syntax for arrays. Similarly, the syntax
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, I think that array types are horrible precedent that exist primarily because there weren't const generics in 1.0. Array<T, N> would be completely fine, and avoid the weird ; in there that's unlike anything we have anywhere else in Rust. [0; N] is similarly bad, since it's trivially-but-disastrously typo'd as [0, N], and has lead to still-unresolved questions like [0; _] that wouldn't exist if it was just repeat(0) (turbofished as needed). And unusual syntax makes it less obvious that it can be nested and a higher edit distance to change to some other type instead. (For example, Array<T, N>ArrayVec<T, N> is nice, [T; N]ArrayVec<T; N> is a pain.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@scottmcm I think even if we had perfect const generics, we'd still want the shorthand array syntax because it's evocative of arrays.

The use of `async fn` to hide the asynchronous type serves as a partial
precedent for this: the case made at the time was that users cared about the
output type of the future more than they cared about the `Future` trait. This
RFC extends that benefit to any place a type can appear.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This has also introduced the send bound problem, however. I think this RFC should talk about how impl Send + Future<Output = T> fits into a hypothetical async T.

obfuscating the difference between associated types and generic parameters.

# Prior art
[prior-art]: #prior-art
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The prior art that jumps out to me, but is currently unmentioned in the RFC, is impl Fn() -> T, since that actually does involve associated types.

If this RFC doesn't want something like Task<T> because it

may confuse users by obfuscating the difference between associated types and generic parameters

then I think the more direct path would be to a shorthand that is evocative of one that constrains an associated type, not something that looks closer to a generic parameter where you just dropped the <>s.

@kennytm
Copy link
Member

kennytm commented May 9, 2024

Should there be a way that users can make their own aliases that work for RPIT and APIT? Or is this only useful for Iterator and Future?

Feels at least plausible that I'd want to make a

type[not_TAIT] Task<T> = impl Future<Output = T> + Send + 'static;

or something.

for a pure syntactic construct you could use a macro 👀

macro_rules! Task {
    ($t:ty) => { 
        impl core::future::Future<Output = $t> + core::marker::Send + 'static
    } 
}

fn run(a: u8) -> Task!(u8) {
    async move { a }
}

fn flip(x: Task!(u8)) -> Task!(u8) {
    async move { !x.await }
}

@wyatt-herkamp
Copy link

I think this will only add to the complication of using Rust.

Rust is already a pretty complex and verbose language and adding more sugar syntax is not the answer.

Now let's take a new Rust developer perspective. They have used some basic async and asked themself the question. Can I have a function handle the result of an async result?

If they try this

fn do_something<T>(value: async T) {}

What have they learned? Nothing. Async is still in their mind as a weird magical property that is added.

But currently, this is how they would learn to do it.

fn do_something<T>(value: impl Future<Output = T>) {}

This shows the developers. Oh. Async is just sugar syntax to the Future trait.

I don't think the syntax suggested in this RFC adds much benefit to the Rust developer experience and only complicates things.

An alternative I'd like to see explored is impl Future -> T and impl Iterator yields T. Definitely more wordy, but also less opaque, more extensible – and generalizing the existing syntax for Fn traits.

I enjoy how this syntax looks. However, I don't think this is necessary.
This could be explored in something like this

trait Future {
	// I don't have a good name for the attribute
	#[some_marker]
	type Ouput 
}

This allows for the trait impl to be written in the suggested impl Future -> T
The impl Iterator yields T would be impl Iterator -> T
But even this I feel like this is unnecessary sugar syntax and does not solve the problems that face Rust developers.

Overall my opinion is that Rust does not need more syntax and more ways to do one thing.

@Wyverald
Copy link

Wyverald commented May 9, 2024

What have they learned? Nothing. Async is still in their mind as a weird magical property that is added.

But currently, this is how they would learn to do it.

fn do_something<T>(value: impl Future<Output = T>) {}

This shows the developers. Oh. Async is just sugar syntax to the Future trait.

just wanted to point out that impl Future<Output = T> is itself syntactic sugar. Do you think they also learned nothing about what impl is?

Not to say I disagree with your assessment that Rust doesn't need more syntax at this point. But the argument to be made here should be why we draw the line at asynx T, not that syntactic sugar makes things "magical" -- that is a given, and a necessary tradeoff.

@Jules-Bertholet
Copy link
Contributor

Is impl Future<Output = T>/impl Iterator<Item = T> really the desugaring we want in argument position? It would require the associated type to be exactly T, which is sometimes overly restrictive. For example, a function that accepts an impl Iterator<Item = &'a str> could probably handle an impl Iterator<Item = &'static str> just fine. So perhaps the argument-position desugaring should bound the associated type to be a subtype of T, instead of exactly T.

@wyatt-herkamp
Copy link

just wanted to point out that impl Future<Output = T> is itself syntactic sugar. Do you think they also learned nothing about what impl is?

True. I think some syntactical sugar is good, however, with all things. It is good in moderation. Rust has a good amount of syntactic sugar. But continuing to add more will only make the language more complex

Not to say I disagree with your assessment that Rust doesn't need more syntax at this point. But the argument to be made here should be why we draw the line at asynx T, not that syntactic sugar makes things "magical" -- that is a given, and a necessary tradeoff.

Personally, I don't see an overall benefit to async T. It seems like an overall unnecessary feature compared to other features the Rust team is working on. I would much rather see more progress made with async working group or stabilization of other trait-related features such as type_alias_impl_trait.

@BoxyUwU
Copy link
Member

BoxyUwU commented Jul 19, 2024

@Jules-Bertholet extending the type system with the ability to require subtyping is a significantly more involved undertaking than a simple async Ty desugaring. It should not be done as a "quirk" of async Ty and instead a principled extension to the type system that can be applied to other applicable cases, such as the Fn* family of traits.

Ad hoc special cases like the one you are proposing are the kind of thing that wind up with inadequately specified behaviour and causing soundness bugs or future compatibility problems, all of which cause problems with the long term development of the type system.

@tmandry
Copy link
Member

tmandry commented Jul 19, 2024

No disagreement with @BoxyUwU that such an extension should be principled. I think it's worth taking @Jules-Bertholet's suggestion as a future possibility and thinking about whether it can be done backward-compatibly, or if not, whether we might want to save this syntax for then.

[summary]: #summary

Allow the syntax `async T` and `gen T` as types, equivalent to
`impl Future<Output = T>` and `impl Iterator<Item = T>` respectively. Accept
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there particular motivation for desugaring to impl rather than desugaring to the trait and allowing the user to specify impl vs. dyn? The current approach would preclude users doing things like:

fn takes_iterator(iter: &mut dyn gen T) { ... }`
fn returns_future() -> Pin<Box<dyn async T>> { ... }

Allowing dyn would make this syntax usable in more places and would help mitigate the existing "cliff" users fall off of when transitioning to dynamic dispatch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is, I'm imagining that gen T would be sugar for Iterator<Item = T>, and async T would be sugar for Future<Item = T>.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

Successfully merging this pull request may close these issues.