[DRAFT] Update stream rfc #13
Conversation
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
|
||
| ## "Attached" streams | ||
|
|
||
| There has been much discussion around attached/detached streams. |
There was a problem hiding this comment.
I think we should find a time to sketch out what an attached trait would likely look like and some of the possible ways that we might 'interoperate' between them (i.e., every "Detached" steam can become an attached one, and some detached streams can become attached ones, but that is harder to specify), and perhaps to discuss the consideration that
- the current trait captures the case where the stream gives up ownership, which offers flexibility -- such as the ability to spawn off futures processing each item in parallel
- an attached trait would capture cases where we are re-using internal buffers, which is less flexible for consumers but potentially more efficient
i.e., there is room for both. And of course we will have to pursue the same design for iterators, whether it be two traits, or one new trait with a "conversion" from the old trait.
There was a problem hiding this comment.
every "Detached" steam can become an attached one, and some detached streams can become attached ones, but that is harder to specify
I'm not quite sure I follow – I think you meant that some attached streams can become detached streams? In that case it seems clear that you would define it as impl Stream from the start, since that's more general?
There was a problem hiding this comment.
(We had a more detailed conversation about this on Zulip the other day, follow up there?)
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
…ion of the RFC Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
@nikomatsakis thank you for the comments - I believe I have addressed all of them. I also believe the Generator syntax section should be expanded. I would love some ideas of what to focus on. |
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
There was a problem hiding this comment.
A few more nit ideas -- happy to land and pursue them as follow-ups -- should we open a tracking issue, @nellshamrell ?
rfc-drafts/stream.md
Outdated
| ## IntoStream / FromStream traits, mirroring iterators | ||
| ## IntoStream / FromStream traits | ||
|
|
||
| The `IntoStream` trait would provide a way to convert something into a `Stream`. |
There was a problem hiding this comment.
Probably good to elaborate a bit here and to mention that: Iterators have an IntoIterator trait that is used with for loops. We might want such a trait for streams, and it would look like ...
rfc-drafts/stream.md
Outdated
|
|
||
| The `FromStream` trait would provide a way to convert a `Stream` into something else. | ||
|
|
||
| Implementing the `IntoStream` and `FromStream` traits on `Stream` is currently blocked on needing [`async fn` available in traits]( http://smallcultfollowing.com/babysteps/blog/2019/10/26/async-fn-in-traits-are-hard). |
There was a problem hiding this comment.
...that would then clarify why this is true (in fact, I'm not entirely convinced this is true)
|
Oh, I guess there is a tracking issue. cc #12, maybe you want to add some of the points and to-do items in there... |
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
Signed-off-by: Nell Shamrell <nellshamrell@gmail.com>
|
Thank you @nikomatsakis! I've incorporated several of those suggestions and placed everything else in a checklist in #12. Merging. |
This is still a WIP.
Rendered