Add a meeting Rate this page

A

So we're gonna start by reading the duck. uh Welcome to this recording meeting on generators. There you go I'll set your.

A

Timer.

A

Foreign.

A

You.

A

Shhh.

B

You.

B

Josh feel free to delete my my parentheses there. If you want to fold it into your comment.

C

Nah, that's fine, uh especially. It helps with the.

C

Attribution.

C

uh

D

You.

D

You.

D

You.

D

All right.

A

We're 10 minutes have passed where people are starting to leave questions and put some answers. um Oh we get started. Does anyone want more time to read.

E

I'm I'm almost done I'd like it all.

C

Right.

E

I think another minute speak up.

C

I would like another couple of minutes as well. Please.

A

Okay, let's do two two minutes to start.

A

See.

D

You.

D

You.

B

um I think I don't know if nico or esteban is the one putting in the the bits about four right at the bottom. But I I would like to discuss that at some point.

A

I mean I'm assuming.

B

We're going to go over each of the.

A

Questions.

A

We'll discuss it, don't worry about it now. Yeah.

B

Sorry, sorry, I wasn't meaning to jump jump. The cue I just I don't.

A

I don't want to pilot a bunch of extra.

B

Text on top of that, I think.

A

Yeah, that's why I only wrote trying not to put long answers just no interest anyway, we're two minutes in. um Is there more time for reading desire, josh, felix or others.

E

I'm okay: let's go ahead.

A

All right um so pulling from the queue I don't know if we want to order in any particular way, but I think the first question.

C

Well, um before we dive into the queue, do we want to give esteban a chance to give us a tour, and then we can dive into questions or do we want to dive directly into questions.

A

I don't know that we need to do a tour given that we just read it, but mr esteban. If you want to give a brief overview or have any particular comments, I think that makes sense. My other.

D

Thing, I would say, is if there are short.

A

Questions uh like clarifying questions that might be a good place to start, but.

C

Right make sure that if there was an intent to present the document along with some explanations, then let's give an opportunity for those explanations before we dive in and that's.

F

Fair do do anybody feel like the document wasn't clear and would be, it would benefit from that.

E

I think to me the thing I might like to see at the outset is: I wrote comments in line for things that just were unclear in the doc itself. Just a quick like skim over the I didn't want to put them as questions at the end because they didn't seem worthy of that, but even if you just skim over them and say yes, no, like for the.

A

Why don't we go over? Let's go over live. I guess.

F

Right so I think I addressed that, but part of the idea is to make this.

F

I I've gone the two main things that are lacking on this proposal. Compared to the current nightly. Only generator feature is being able to return values through a yield point back into the generator so that you can affect its behavior and the return type and the those are depending on how we actually implement this may be problematic, but nothing here would preclude us from grafting on both of those features.

F

After the fact on this proposed implementation, uh the biggest problem I could see would be on the scene, surface, syntax, and that is not something that should be too problematic and because this feature would be returning an infiltrate and we could expose different ways of consuming the generators where you have a simplified version where you can only cons, consume new elements and a more elaborate syntax where you can actually affect uh the behavior of the generator.

E

So I I don't, I don't.

F

I don't think it's a one-way door.

E

Right no, it sounds like the quick summary then is, since this document isn't actually trying to it gave us syntax, but it wasn't committing to it. It sounds like right dues here with generalized code. Routines are more about, sounds like the syntax you'd use for them, and thus we don't need to it's not really. This document is not a one-way door. In that sense,.

F

Right.

E

Okay, that's all I wanted to hear for that. um You might be faster, maybe if we uh there's a link at the top. That says that says four comments. If you scroll up niko, if this is niko's screen, I don't know who screen this is nico's. I think it's! No! I don't see it in here. It's weird, there's a oh there. It is yeah. If you click that, then you can just sort of go down and see all of them. um I just want to clarify yeah.

F

Subset of obligations not of stream, but rather of applications than the end users would write. There are some.

E

Okay, so.

F

It's more general.

E

It's more difficult, but just okay, that's the so.

F

There is an argument that can be made that this is a niche feature that isn't actually used, and that uh is only a concern for libraries, writers and from my searches. I've seen what you would consider an end user application, a service that actually needs to operate on streams and create their own stream. A stream is not the only thing that they have to implement. In many cases they also have to implement async read, and I think right.

F

But there are cases I'm making the case that getting this right is a foot gun that would benefit from having a level uh is.

E

It fair: is it fair to say that the the improvements you're talking about here are roughly in one to one correspondence to when people are implementing streams.

F

um

E

Oh, I guess I guess mostly. I was curious about the when I my first interpretation of this. When I saw subset applications, I thought it was saying substitute application of streams, and then you wonder about whether you're making some distinction there about how you might implement stream in general versus what you can express with the syntax theory, with the the semantics and syntax you're providing here. If there's certain things you'd be able to express by manual stream implementation that you wouldn't be able to express um with this system.

E

I think there are some.

A

Questions in that direction, like mark's question.

E

All right, then: let's, let's wait till we get to that. Then you can scroll.

B

Down? That's all the relevance to my question in the discussion that we're having on zulu.

E

Okay, so let's let's move along um this was a detail about the python code. I think in terms of I didn't understand, why join in inverse is there and I didn't see it referenced anywhere, but I think it's because there's a typo um in the line. The very last line- um oh yeah,.

F

Yes,.

E

Okay and then I think scott has the last one way down.

F

This part could be done with a little yes and the main.

F

Difference so yes, uh the thing with eater from fn is that you, you are limited it either from a fan, works great when you need to create um an endless stream, for example, or some sequence, but it doesn't compose very well when you need to affect uh that behavior, based on a set of initial constraints that are affected.

A

It would basically still like it would look. It would.

G

Look very similar right. You.

A

Eliminate like a little bit of.

F

Yeah.

G

And you save the defining, the struct is all that I meant there.

B

That, like iterator or stream from fn, is like a worse thing than error from because of semantics about how um borrowing works for async, like our missing async closures, feature, which is another thing, that sort of come comes up in in passing in the stock and gets mentioned lower down.

A

Yeah, I I would say to me the key point is that you still have to write it as a like function that you know manually encodes, the state machine.

G

uh Yeah, that's what I was about to say. My point here was: I don't think it's particularly relevant that you have to define a type compared to manually state machining. The flow right.

B

Okay,.

G

Cool.

B

Also, I I don't know, I'm adding this question at the bottom. Forget that.

A

Okay, so why don't we go? I thought taylor's question is sort of, like probably the most important in the sense of like how I understood it was kind of why now why? Why do this at all? It's sort of the motivation question right uh and I guess esteban. You started talking speaking to it already a little bit, but maybe you wanna.

F

Yeah, so from interactions with people in the community on different on social media. Through what I've been seeing on the assign a sync vision document exercise, there is a common pain point of people. First of all, pin is probably the the one of the biggest pain points that people uh have when learning a single weight.

F

That is both because the semantics are subtle and somewhat counterintuitive to uh what a person may think is in the first place and when first encountering it so and one of the common cases where people have to interact with pen is when writing a new stream.

F

The other thing is, I we've seen cases of people misimplementing streams or in such a way that it doesn't cause a compilation issue. It doesn't cause an actual uh incorrect incorrect, observable behavior, but what it does cause is um a very slow stream uh consumption. If you there is a link, I think earlier in the document that talks about one of those cases.

F

So I what I posted is that this is a common enough thing. May it may be niche in the larger ecosystem, but it's a common thing that any micro service that has to deal with different connections will need. It's not just libraries that need to implement stream and the ex there are. There is a problem with discoverability on one, these, these potential food guns and two how to actually um implement these things.

F

If you, there are blog posts explaining how to write your own stream from scratch, there are a a handful of different crates that let you actually implement this in uh or or just sidestep the issue and give you what the language feature would give you. But again you have the discoverability issue and when you have multiple alternative implementations, you have the problem of okay, which one do I choose and on the cons.

F

This is a part that I I don't know if we actually want to tackle on this meeting, which is uh this document is heavily focused on the producing side, but you also have to keep in mind the consumer side and whether we would have something I came to uh 408 and I I know that there is some contentious contentiousness there for how that would behave, but having some expression to ex to express, if you forget my the redundancy there to express that concept.

F

That would let us hide things like uh having to pin the the stream before being able to iterate. I.

B

Think I'm sorry if I could stop you first again, I I want to say I I'm.

B

I think that this is answering a different question than the one I was asking, um I'm not trying to figure out like why people want um to not write streams by hand. I'm trying to understand like what specific like what is the specific sort of like user story where they're not being served today and and how like? How can we meet those needs if that makes sense.

B

So in my mind, um a lot of the people writing streams today manually um aren't people who would be served by this feature, because they will continue to need to write streams manually for either performance reasons or um details of of the implementation like, for example, you know the stream I wrote above like has a future baked into it, and it has something where it like. It doesn't pull the stream unless the.

A

Stream.

B

Future has I'm sorry.

A

Which stream did you write above.

B

Oh sorry, the um appendix oh.

A

This one.

B

Yeah, so appendix c was sort of my example of like how today you.

D

Can.

B

It like on stable without macros or anything you can already write and sort of like impulse stream. If you don't mind the the resulting thing has these sort of restrictions about um you know being not conveniently nameable and you can't add methods to it and sort of all these other things that we have other sort of systems in the works trying to solve like the type alias infiltrate system.

B

So I'm trying to figure out like what specifically like what specific audience of people we're trying to target with a um by providing this sort of mvp feature who aren't already being served by things like this or by the macro libraries, or some reason why, those like the macro libraries or this you know this proposal. The my code example like isn't good enough for those users. If that makes sense,.

F

Yeah yeah, it does so I there are multiple things. One is a in my eyes, discoverability.

F

That is an issue once you're told how to do it, it's easy enough to go about modifying the example and getting what you wanted to do, but this is the same kind of ergonomic distance that you would have if we didn't have a closure. If you tried to, if you had to implement every closure as your own struct uh with its own, like, if you had to implement a strike for every closure that you wanted to use, then there is a certain level of friction there.

F

That doesn't really need to be, and one benefit that I see from this is if we do go all the way to actually implementing some item syntax for streams, then we also get iterators almost for free, where we, which also let us simplify heavily any kind of.

F

I I think it's going to it- would change dramatically how people write certain types of code.

B

I guess maybe that's something to push on, because I don't I'm not convinced. I agree. I think that most of the people who are writing iterators by hand today, would continue to write iterators by hand if we had async, gen, fn or or gen fn or fn or whatever so.

C

I I'm happy I'm happy to chime in on this one. I would love to never write an iterator by hand again, and if this syntax is good enough, then I doubt I would ever want to use an alternative unless the syntax isn't good enough.

B

So so john.

C

Adam write, iterators.

B

By hand today.

C

Say again,.

B

When do you write iterators by hand today like when, do you write the the actual and implementation of the iterator function?.

C

Generally speaking, when I'm trying to provide like a data structure that has contents- and I want to provide an iterator over those contents, so I end up with a you know: a foo type that has an inner method that returns a foo error with a reference to the foo that walks over the foo and returns its elements.

B

Right I at least it's been my experience that when I'm writing those things I'm, I also want to offer, for example like a debug impule or something that prints sort of the current state of that iterator, and I also want it to be. You know copy your clone, or I want it to have some other method to extract the intermediate value or or something else or- and I want it to be nameable to my users, like things.

C

That I wouldn't.

B

Do if I didn't write it by hand.

C

Well, two things one is: I haven't tended to run into much other than yes most things should be debug, but the other is. uh I don't think I think what you're capturing is a requirement for this syntax of maybe there should be a way to name the type that's being produced and to then further extend that type. By saying, I also want that type to support debug. I also want to add another method to that type.

G

So the piece that gets complicated for me, there is specifically for something like a data structure scenario I feel like it wants to be double ended, a lot or to have an exact size, because data structures reasonably often know that that's what my question above is about.

F

And.

G

Reversing a generator is, I assume, a very difficult computer science problem.

A

So I want to say two things. um First of all, I often find myself writing small iterators. I don't know. Often I sometimes find myself writing small iterators using it or from function or other things which works okay for like just anything where I don't. You know doing a depth first search over some structure, some graph or something like that um effectively, not necessarily an actual graph but like in the compiler, for example. We might be for walking through a list of predicates, and I want to evaluate them one by one.

A

Without forcing everything to happen up front, um it works.

B

Okay, clarify I'm not saying that that use case doesn't exist. I'm saying that that use case is already served for the case of async streams by the tools that we have.

A

Yeah.

B

I.

A

Want to speak to that point specifically, which is just to say that I have pretty much not had any com like pretty much every conversation I've had with. I was going to say customer conversations I'll just say that with people about async, they all bring up writing streams and nobody's using those tools.

A

um There are that that's like the reason for that is probably many fold, but, and we can maybe address it by pushing harder on the tools, but I also think there is like a legit.

A

It is that that's partly discoverability as esteban said, and maybe we can make them more discoverable, but I think it's also yeah feeling first class and other more subtle things um like it's. Definitely something that is hitting people a lot and one way to address it. I think, would be to offer them nice syntax.

A

But I do hear the concern that, like we'll offer a nice index, that they won't actually be able to use. That's not very appealing.

F

So one thing that they want to say is um taylor has a point. It's it's very possible that the people that currently that are currently served with uh the with the implement implementing a new iterator or a new stream may not make the switch because one they already used to it. Two. They may want to support all their uh rasi versions. Three.

F

They may have very specific um needs, but what the new feature would do is allow a lot of people that aren't currently writing neither iterators or streams which would like to or but don't have as high a necessity and are put off by the current um difficulty in writing them. uh It was just in I. I've lost the the the sentence structure there, but it wouldn't enable all of those people so because the fact that there are people that currently aren't using it doesn't mean that they wouldn't use them in the future.

F

This would be a bit of induced demand. If you will.

B

Yeah to to clarify I'm, I I guess I'm saying like I.

B

I think that the discovery ability argument is good and it's probably the best one and, in addition to the sort of feeling first class point, I think that I feel like providing these tools via like clear standard crates, and I, which is just impossible right now, because there's at least three different definitions of the stream trait floating around in the wild, and so you can't write a smoke canonical library for all of this, um like I don't know, I feel like as an ecosystem, we're like in a mess right now and and discoverability is incredibly hard and understanding documentation like there's no centralized documentation, because you have to figure out which of five different libraries.

B

You're writing your documentation for um is, is like not gonna, be like this, isn't a primary step in the solution of solving that problem and the reason that these, like there are other things that we can do that are low at lower effort than introducing native generator syntax. um That would have a lot more payoff. I think.

A

I think there's a bit of a. I don't disagree with that. In fact I agree. However, I also think there's um like uh assumption that we can't walk and chew gum uh right that we can't do some of those things and push on.

B

Yeah I mean if we think it's not going to use up a whole bunch of lang team bandwidth to argue about whether it's async, gen, fn or async it or fn or async fn star um or whether yield can like what it returns and what happens when you use question mark in the body and whether, like what the return type syntax looks like like, if we think that those things aren't gonna like eat all of our time, so that we can't focus on other things, then I mean go for it.

B

But I'm skeptical that that's like I. I think that those things are going to occupy like a huge amount of bandwidth, so it better be sent elsewhere.

C

So I'd like to interject for just a second here, um I think it's a valid point and I also think we may not want to spend the entirety of the meeting talking about whether uh I think that the point of whether should we should do this or not has been made, and we should seriously consider that and in the meantime we may want to take the rest of the meeting talking over okay conditional on if we decide to do this. Let's talk through some of the other potential issues.

A

I think that's a good idea, yeah. I think this. We won't reach consensus on this. At this point,.

B

Beforehand, but I think I didn't quite succeed um so yeah.

A

Yeah, please please have like.

B

Discuss the rest of it, that's.

A

A good thing, the voice to spend time on just we did all right.

C

To be clear, I don't want to invalidate that point, I'm simply suggesting that we move on from that point for now and reconsider it later after we've talked through some of the other issues which may give us some more color on that.

B

That sounds great thanks. Josh here's.

A

A cool.

G

Question.

A

Why.

G

Would.

A

I certainly say.

G

That uh usually being able to use yield return in c sharp for iterators means that basically, no one ever writes a manual iterator implementation. Because there's no point.

A

Yeah all right, so that's actually. That is helpful. I think it's a good precedent to think about, but so then I'm going to go through the queued questions says: why does the d sugar return into iterator rather than iterator kramer tj.

F

So flexible, one of them is flexibility uh it having to. If we had to return well.

F

So if we, if we were to return a specific input, iterator, then that's all that we could even ever do. I don't know if that is actually what we want to do. It may be the moral equivalent to that, because it would be useful, as you mentioned earlier, it would be useful to have to be able to extend and potentially name that type uh we if we were to return something close to um what a closure is or some other name-able type.

F

You could actually extend it and have not only just iteration, but uh it adds extra methods to it now why integerator, instead of iterator, just flexibility and forward being able to change it after the fact, that's one of the things that I had in mind.

A

Okay, so.

C

It doesn't seem like returning impul iterator would prevent us from having that flexibility in that you could always potentially have a name for that type elsewhere. We could have a syntax that allows you to name the type. I think that uh into iterator just implies you're returning a thing that you can call a function to get an iterator from, but you're already a function, that's returning an iterator. So if there were code to write, you could write it there.

C

I'm not sure what the use case would be for it being into iterator or into a sync iterator that doesn't just add complexity.

E

Are there cases where the structure that you get from like for iteration is different from the structure you get for async iteration, where you really would want that level of um that level to be extracted so that you don't prematurely commit to one when you really wanted the other. You can't enter convert.

A

I think you're implying you could get an input, iterator and or into iterator and then like choose. If you want it into sequential or async right.

E

Based on the idea that, if you have the name type, I guess yeah, like whatever the type, let's say you have the name type: either it's going to implement into it or it's going to implement iterator and I'm trying to stay say that if you go with what josh is saying, I think of saying it's an iterator. Does that mean you've now committed yourself down a path that you didn't want to be necessarily.

A

Only the only thing I would say is like I don't know. If this is a good precedent I would, I would have initially thought into iterator just because we regretted, I think, making ranges not into iterator, uh but I don't know if that's really good.

G

The.

A

Other side of that.

G

The other side.

C

Of that, though,.

G

Is that part of? Why part of what stalled the work for the addition to move rain, to move dot dot syntax to being into iterator is that it means you have to call dot into iterator right.

E

Any.

G

Time you want to apply the apply other things on top of it like if you just want to. If you wrote your iterator, and now you want to zip it with something else. Well, zips on iterator, not into iterator yeah,.

A

Right, I think we should um move to the next question, I'm mindful of the time and I think there's a lot of good details like it seems clear that this is a choice that one would have to make. It may not be correct.

C

I think there's a lot of trade-offs to making it and we should consider if we actually need to add that flexible joint at that point or if the indirection is not adding anything.

A

In particular, I think the next question applies.

G

Lending iterators also make me very curious about how that should work. If we're going to do those from generators so.

C

This isn't the next cued question, but the next couple were mine and I think that this one is more important from scott, so I bumped it up the queue.

A

Okay cool, so this was about adding methods um like size, hint and so forth, and I think that's relevant to the previous questions. Why? Partly why I wanna.

C

And to cramer's question I think as well.

A

Yeah, because if we return into iterator, even if you had a syntax for naming it, that's actually not you're, not naming the thing you're returning is not the one that will add these methods right, um so you couldn't implement them by hand, or at least it would be a little trickier. You'd want to be implementing on the iterator that will get yielded by the into iterator.

A

But that said, I just want to say it seems like you could imagine allowing use if we had like name dimple trade or some of these other features. I can certainly imagine allowing you to write impulse on them.

B

I think the thing I'm confused about is how we would handle accessing captured values inside those impulse, because I'd imagine like for size hint you. You need to take advantage of the fact that, for example, a range inside of your generator has advanced.

B

I would add.

A

This is totally applicable for closures right.

B

At that range, somehow right.

A

Yeah uh and that's when I say this is totally applicable to closures right like we have the same problems now, I think yes, uh and it's come up- that we, for example, implement clone automatically, but that's not always a good thing and so forth.

D

It is worth noting that I think it would be sort of pretty sad uh like if you you know map can look a lot nicer as a generator. I think in many cases, just from like a looking perspective than a map call, but you'll get you know, potentially many more allocations or whatever else, if you're collecting that iterator or stream, because you've just lost your site by default, um and I struggle to imagine that we can do anything in the compiler um to to avoid that.

B

Things like maps specifically like you, like you, want to optimize the layout of it, because it's really commonly reused, like those sorts of building block things, are, are used heavily everywhere, and we wind up with like accepting prs to do this sort of, like smallest, smallest micro things, to reduce a branch somewhere, because it made somebody's thing optimized better and we wouldn't like in practice. We wouldn't write those things as to.

D

Be clear when I say map- I I I mean like I have you know library code that has some things that I'm mapping to some other things. So I'm not like writing the map itself. I I want to sort of use map yeah.

B

But I think, in the case of I think in the case of async right now, the ecosystem's at such an early stage that a lot of the things that people are struggling to build are these like really early building block functions.

D

I think the situation may be different for async than for iterators. In that case,.

A

I don't I don't totally buy that point. I mean I'm looking a little bit ahead. Let's put it that way and I think people are building a lot of stuff anything, some of which is building black summer, which isn't, but I do think the point of I was. This actually comes to uh the rust guiding principles, meaning I think one of our guiding principles of our design has always been.

A

Efficiency is idiomatic using iterators, not just because they're nice to use, but because they yield better code, and I wouldn't want to see us regress on that point. You should at least at least be able to provide those sort of hints so that using the nice thing doesn't cut you off from it. I think that's definitely a design requirement. We need to add.

G

Yeah we, we do have some small problems with that for iterator already, because if you return input, iterator you've lost some of the things like exact size.

D

Or double ended or conditional.

G

Or so maybe part of that, but I.

D

Guess that's sort of for generators.

G

If we fix that for impul.

D

Some of the stuff today specializes, so it bypasses the um like visible barrier in some sense. Like you don't know, it's an.

A

Exact size.

D

But your collect knows so it doesn't actually lose any performance. True right.

G

Unless.

D

Your caller needs to.

G

Use it somehow through a way, that's not.

D

Specialization.

G

Yeah but yeah.

A

All right, I think we answered this question. I don't know who's typing this hypothetical proposal, but do you want to talk about it.

C

uh That was me. I don't necessarily know that I have a precise syntax proposal here so much as I wanted to point out that if we had generators returning something that was an iterator where it could either be an anonymous iterator with impul iterator or a named iterator type, then we would have the option of subsequently implementing further things on that iterator type, so that you could add things like size hint. After writing. Your generator function.

B

Yeah, I think the problem josh is that, like we were saying foreclosures like you, don't have the ability in the body of seismic, you would need to access state. That's inside the iterator generator right.

A

Yeah, we have to add a way to do that so.

E

What I, what I was imagining was some way to say under there's some some like one of those zen cone things where it's like you know, every lambda is actually an object and every object is a lambda. It's just a matter of you know what methods you attach to it. I always imagine something where, for closures you'd be able to throw on extra method, definitions and you just within the body of the lambda and you'll reference, the captured variables within there and likewise for generators.

E

I guess it would be a method definition in between every yield point or something because you have to you know, handle it for each distinct state machine, but it doesn't seem like an unsolvable problem. It just seems like another syntax bike shed to be had.

C

Right, another approach by the way would be if we inverted the flow of syntax there, where, rather than having a top level generator that impulled iterator, you could have an impul of iterator for a type and then a uh instead of having to hand write the iteration functions. You fill it in using generator syntax saying this is how I want to implement this.

A

Yeah, I was thinking about that.

G

If we had an expression for this, would that avoid a bunch of the syntax questions or the problems like whether a generator function should return impoliterator or impul into iterator or whatever.

C

I'm certainly tempted by the idea.

G

Of only.

C

Having a block and not having a function, syntax and then it's easy enough to wrap a function syntax around it.

G

I assume there's some funkiness for async, though around lifetimes. I understand.

B

It might make that.

D

Harder.

B

Think right is how you'd spell it right or something like that, and then you have gen blocks.

E

How does that give you to solve the problem of adding solve.

B

Any.

E

Of these problems.

B

You don't have to solve the problem of the return type syntax, because you you don't have the the sugar for function, signatures.

G

I think I don't think it solves the size hint though I agree.

A

It doesn't solve the size and, moreover, in a way it makes the return type harder, because you don't have to write it so like. If you want to use it to pick things you can't, um I don't know I, I don't think it solves the interesting problems. Fundamentally, um no it just.

B

Sidesteps syntax, like.

C

Well, it's not just that. It would also give just enough language support to let you write the actual iterator block uh such that then it would be easy to invent whatever I want to write an iterator.

C

You want using a proc macro or similar. You could have a proc macro that results in defining the my iterator type and allows you to define things like size, hint and state, and introspection and similar yeah.

A

But you can do that yeah.

B

You could do that in either case. I think.

C

True, but what I'm suggesting is that, if we had just enough syntax support to do iterator blocks, that then allows for a lot of experimentation in the ecosystem for the next round of what should the top level syntax look like. We might then one day adopt the top level syntax, but we might be solidifying too much too soon. If we add it now,.

B

Yeah.

B

Sure, yes, I agree. I agree that I think it could help avoid some of the syntax questions.

C

In particular, I feel, like the block syntax, solves a huge fraction of the problem of it's painful to write an iterator or a stream, and then anything beyond that is additional ergonomic improvement and additional expressiveness improvement. But the biggest part of the problem that people are complaining about seems like it might be solved by a block.

B

I'm not totally convinced that that totally sidesteps everything, because I think you still need some way to annotate the return type so that we can have correct question. Mark error, type, inference.

C

No argument there there are a lot.

G

Of I'm.

C

Also not sure how I'd store.

G

The generator inside my iterator, because the generator needs somewhere to store its state.

B

I don't think this is about.

A

I don't, I think we should sidestep this question and I.

G

Mean I do think this is a theme but.

A

I want us to. We have four minutes left and I'd love it if we can hit a different one.

F

Regarding size hints before we move on uh is the concern only for cases where the programmer would have to determine what the the size the size bounds actually are, or is it also about propagating a consumed iterator that is being yielded and propagating that size hit outwards? Because that second case feels to me like we could support.

B

uh I'm not sure how you would, for example, if you iterate over two streams in sequence, right, you want the generator to give a size hint that is the first plus the length the size into the first plus the size of the second right right and there's no way. I don't. I don't know of how we would infer.

F

Well, you you have an. You will have an iteration expression on both of those, so on those both of those values, you would have an iteration expression that would have a yield in its block, so you could just call just a quote: unquote, all of uh all of the iteration expressions that have yield and see at a peak at the time to get the value of the size hand.

B

But you might not have created the second iterator yet right like you need like there would need to be some sort of hints from the programmer or like.

F

Oh.

A

I I think we can, I guess so.

F

But yeah.

A

It.

F

Seems.

A

Like it would be possible, well, I guess what josh is writing already. You can imagine some cases where we might be able to infer, but certainly not in the general case. I think we kind of covered this question. Maybe we've already covered all the main big questions. Are there any questions that people feel they wrote that were just like different than what we've talked.

B

About.

B

Sorry, I'm scrolling back up to read the questions that are done. Yeah. I did kind of want to talk about that four weight thing, but we can talk about it on zula.

A

Yeah well that well, you only have two minutes anyway, but we could do that. Let's talk about 408 real fast.

B

Oh, and also I'm assuming from for them vp, I just left a comment here, uh yielding borrows out of into the stream state, is out of scope for this right since we're just considering async iterator and not async, ref iterator or whatever.

A

Iterator.

C

Limiting iterator or something blending.

B

Thank you, that's the name we use now.

A

I think that's correct.

B

It's like it's like gaps, we're gonna, be calling.

A

It the old name for like, but I do think uh landing.

B

Iterators.

A

Like I do think it, I think it's out of scope, but I think it's a good example of like we should leave syntactic space to not have to infer whether it's a lending, iterator or not.

B

Right we would really like for that to be easy and natural that one thing yields you know owned values and one thing yields borrowed values like because I think the thing the borrowed value thing is something that I really frequently want and yeah. I would love I would love for that to be supported.

B

I would like.

A

To ask yes never mind we're out of we're at the end of time, I'll move it to zulu. um Sorry, that's all right! That was a good final question. We can follow up on the 408 stuff on zulu thanks everybody for a great call, all right. It was really fun.

B

Yeah thanks so.

A

Much for your time.

C

Thanks absolutely thank you esteban thank.

C

You.
youtube image
From YouTube: 2021-05-12 Generator Design Meeting

Description

No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).