-
Notifications
You must be signed in to change notification settings - Fork 28
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
Add a convenience trait for Generator + Iterator? #23
Comments
This could also include |
If you want to preserve all capabilities of the original generator, why not just return a concrete |
Because a concrete Gen can't be swapped out as easily. Though I guess if
standard generators make it out, I will need to change the interfaces, so
maybe it's not worth.
…On Thu, 30 Apr 2020 at 19:20, John Simon ***@***.***> wrote:
If you want to preserve all capabilities of the original generator, why
not just return a concrete Gen?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AE7AOVMJXPACEBWYRCOR7DLRPIBUHANCNFSM4MRRYDUA>
.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I found myself writing a generator for an
impl IntoIterator
type---I had originally usedimpl Generator
before realizing that it wasn't what I wanted because I wanted synchronous usage only. But in theory there's no reason not to expose in my API that the same result could be used as an asyncGenerator
. So perhaps there should be a convenience trait that implements both?The text was updated successfully, but these errors were encountered: