or
or
By clicking below, you agree to our terms of service.
New to HackMD? Sign up
Syntax | Example | Reference | |
---|---|---|---|
# Header | Header | 基本排版 | |
- Unordered List |
|
||
1. Ordered List |
|
||
- [ ] Todo List |
|
||
> Blockquote | Blockquote |
||
**Bold font** | Bold font | ||
*Italics font* | Italics font | ||
~~Strikethrough~~ | |||
19^th^ | 19th | ||
H~2~O | H2O | ||
++Inserted text++ | Inserted text | ||
==Marked text== | Marked text | ||
[link text](https:// "title") | Link | ||
 | Image | ||
`Code` | Code |
在筆記中貼入程式碼 | |
```javascript var i = 0; ``` |
|
||
:smile: | ![]() |
Emoji list | |
{%youtube youtube_id %} | Externals | ||
$L^aT_eX$ | LaTeX | ||
:::info This is a alert area. ::: |
This is a alert area. |
On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?
Please give us some advice and help us improve HackMD.
Syncing
xxxxxxxxxx
Open discussion
Attendance: TC, tmandry, Yosh, Vincenzo, CE, Adam Leventhal, Russell Johnston (rpjohnst), Дарья Сухонина (Huawei)
Minutes: TC
Renaming
AsyncIterator
toStream
https://github.com/rust-lang/rust/pull/119550
yosh: I'd like to compare the two traits in practice since we don't have consensus, even in this group, about the path forward.
CE: I'm concerned about the lack of a bridging implementation.
CE: Also, not using pin here makes
async gen
blocks very unergonomic.tmandry: The main value in putting this in the standard library is having some integration with language features like
async gen
.CE: The compiler can't distinguish
.await
andyield
b/c they both becomeTerminatorKind::Yield
.Yosh: You're saying this is how the compiler is written now, not that it's fundamentally inexpressible?
CE: Correct.
CE: Also, this seems predicated on the idea that people won't hold references across references. But I think people want to write loops, etc., in these blocks.
Yosh: This is an existing limitation of
gen
blocks.TC: But those aren't stable yet. We could choose the solve the problem there also.
tmandry: I'm mostly aligned with what TC and CE are saying here. I think we'll want to hold references across yield points.
CE: E.g., the
for
desugaring could add apin!
. The async version does this now.tmandry: How would we handle, in an await context, how would we handle?:
CE: You have to pin the outer async gen. You can't take a self ref in a block.
tmandry: There's a lot that hinges on whether we want borrowing across yield points. I wonder if we can experiment with that in a way that doesn't require a separate thing. E.g., we could add a feature flag.
Yosh: My main push here is that there should be symmetry between synchronous and asynchronous Rust.
tmandry/TC: +1, they should be consistent.
Yosh: We should also think of the emergent system for things such as
try async gen
blocks. We should try the fallible version, the lending version, the pinned version, etc. How do we want to navigate this? That's why I want to experiment with this. We should get answers here.tmandry: My worry is that in order to get that, we have to actually build them.
TC: One thing we can do is to experiment on top of Rust without building it into rustc. Many of these can be built separately on top of coroutine, and e.g. I've variously posted these prototypes to the discussion threads.
tmandry: …
Yosh: Pinning is sound, it works today. But it's a hard thing. But I'm not sure we can address the broader challenges we have without addressing the limitations of our pinning system. We could ask, e.g., how far can we get without holding references across yield points.
tmandry: What is a set of the concrete questions that we're trying to answer. One is whether we can get away with not pinning. It'd be good to have a set of questions that we're trying to answer with the experiment.
TC: What if rather than renaming, we added this experiment under a different name? Some of the concerns related to arbitrarily breaking nightly users.
tmandry: E.g.,
AsyncNextIterator
.CE: We should be sure that it's clear the point of this experiment is more than just, "which trait is it easier to write impls for?" Because that's obvious, but that's just one angle. There's also the user experience and other concerns. I think most people are using the traits, not writing impls for them.
Yosh: On the point of what people will write more often, we should keep in mind that we're writing a systems programming language. We have to be good at every abstraction level. We should ensure that the ergonomics of the lower level of abstraction are equally good.
CE: My converse option is that Rust is good at encapsulating the hard parts into things that people can use conveniently. I do think the usage ratio, e.g. the log of it, matters. We should of course make the ergonomics good at every level.
TC: We also shouldn't take for granted that it's always easier to write the
async
version as compared to writing the more manual version. Often handles thePending
state explicitly is easier.Yosh: Someone did an analysis on this: https://github.com/Kobzol/async-iterator-examples (analysis to be pending, he told me this over DMs; he wants to finish this out first, then will add an analysis overview to the project).
tmandry: What I'm missing is what are the specific claims we want to show with this experiment.
Yosh: I want to build all the things and see whether we like them.
TC: What if we try to answer tmandry's point here in this meeting:
poll_next
vsasync fn next
and whether or not theSelf
type is pinned.tmandry: I worry about blocking async iteration behind async Drop since that may block it permanently.
Yosh: Huawei is putting 2 FTEs toward implementing async Drop. So there is progress. It won't be permanent.
CE: Just because people are working on something doesn't mean that it will definitely happen. My hope is that we'd quickly come to the conclusion these features don't interact, or at least, that they don't interact in a way that's stronger than the way they interact with regular
Future
s, because if there is that equivalence, then we'd need to fix it anyway.Дарья Сухонина: Async Drop is related to linear types, at least a bit. There has been discussion that linear types may in fact be easier to implement. I have thoughts about an unsafe
Leak
trait. There was a blog post about changing the rules of Rust. There were, I thought, some basic misconceptions about whatLeak
is or should be. The core problem is that you can send a value to another thread that may have some undecideable algorithm…Yosh: We may be getting too much into the weeds.
Дарья Сухонина: In short, this new formulation of the
Leak
trait would allow use ofRc
and channel synchronization primitives. If you want to guarantee that your drop is safely run, you must prohibit these things for a type, and that might be limiting. A safe variant of async Drop is something where values could be forgotten. I'm working on writing a post about this.TC: We all look forward to reading that post.
tmandry/all: +1.
TC: On the main issue here, let's say that we don't rename the trait but add a new one, e.g.
AsyncNextIterator
, and we write down the findings we want from the experiment, do we have consensus to move forward on the issue?tmandry: +1, yes, we could go forward then; I'm still uncertain about these goals.
CE: I've nominated this for T-libs-api also. We should write down these points.
TC: It feels like we should develop a consensus as WG-async to help out T-libs-api by expressing our view as a group about how to move forward.
(The meeting ended here.)