Add a meeting Rate this page

A

So alright, let's try to remember so currently we did I think we did one thing well, what was the PR? We landed some PR right.

B

It was in a private branch, though okay, oh the P, did we landed a PR, but that was related to some cleanup, the important PR for this one, where we actually converted the list of upwards into a top. Oh, that will be dental and it's just in a private branch. Okay,.

A

So we can it. Oh I remember there was an efficiency problem right right right, so the basic plan I'm just coming back to me now. The first thing we did was: we were converting the closure substance and.

A

Generator subs pipes to to have a fixed number of type parameters.

A

Regardless of how many up far as they captured right all right, okay and I, think the T key on my keyboard is like I. If you notice any missing, T's fill them in so yeah.

A

So this is like right and so it's kind of step. One. A of this was like basically um changed the api's for closure, subset, cetera to synthesize a tuple type, and that part we did as a commit on the branch it has prey locations.

A

We didn't want to land it independently or it could have. We couldn't test that anyway and then step B was going to be changed, the type check or actually generate eight people right and actually.

A

My stinkweed, you have a few videos in and around this area, yeah.

B

So those videos are there in that the pull request that I sent you okay,.

A

Very nice, so you've been working on step, B right now, right yeah, and how is that going so.

B

When we have changed this into this, the topple we have a few test failures. Yeah I saw your mess. Are you I guess.

A

So the one with the trait the UI test for trait matching was adding an extra line. Is that correct, yeah.

B

And that same error is in all the nine tests that are failing. Okay,.

A

So I don't know if you saw my messages and Zul upon that topic, but I can expand yeah.

B

I.

A

Don't see them okay, let's leave that we'll come back to that topic because something we can discuss. Asynchronously I, don't think it's a major problem like okay Dorit. We could plausibly even land the PR, as is but I, think I'm inclined to try to fix the error messages. I, just don't think it's very well.

B

Yeah but.

A

Mostly because it seems like we're exposing uh implementation details, if we land those message, but the changes to the message kind of expose, an internal detail that maybe users don't care about, I, see but I'm, not overly concerned, it's not the best error message anyway. So I guess the interesting next question is: where will we go from here right, I think I, definitely think, step one that we should lay on this as a PR like this.

A

This is just a good change. That's the stance on its own okay, and so to the extent that you have it working already that's great, and we should um we base it and everything get it ready to land um once we do that, though, then the next thing we have to do.

A

We're going to have to change okay, we're going to have to change how many look all the code that assumes that the set of free variables is the same as the set of captures right.

A

Maybe a later a way to look at this. That's like a meta thing is we have some problems. We have some assumptions in the current.

A

Current code that have to be have to be fixed and step, one was number of bars, is baked into the sort of generics of a closure, / generator this yeah and just to review. This is the problem, because the type checker.

A

Or because we have to generate yeah, we have to know the number of generic type parameters and so forth before we actually type check with your body. So if the number of captures is going to be dependent on.

A

What the closure body on what paths, the closure body actually uses and the types of those paths, then this is a problem.

A

Okay, so that's number one in a similar vein code that uses the free VARs list to determine many field, slash captures, etc. An enclosure has so you remember what I mean by free VARs list.

B

Right so one question the first point: B we already did something about it. Right like there are in the last here. Okay, that's.

A

Basically, what we've been trying to fix until right.

B

Okay,.

A

So now I'm saying we probably want to probably the next thing we want to target. Is this free VARs situation, and once we do that change consumers, I think, I, think the plan here we're gonna have to dig into this a little bit.

A

I think what we're going to do ideally actually didn't. You do some work about this because you didn't. Actually we did something here. Maybe it's Anna branch, oh.

B

So it bit free bars the call to be three bars. We changed it that one.

A

Yes, remember: we did we added something to the type check tables right, yeah.

B

So we had so instead of going through the width field bars function which has mistakes, the closure, we added a map.

A

Lab.

B

Who's.

A

This up for a capture map.

C

No.

B

Not that one okay, we deal for capitalists, yeah I, think it was up for list. ah This looks right, yeah that one yeah yeah, that is the one we are right.

A

So so part a is to add information into this part. We've already done into the tight check, tables or tracks bars right, and this is basically done.

A

Okay, so let me add a link here just for I'm, basically hoping we can both for me to remember and that it's it will be nice to have a sort of overview of what the whole plan was and how I know and so step B.

A

We basically have to use this now and I. Don't remember how much of that work. We did.

B

Yeah, we we just filled it up and we let it be I think.

A

You did a little bit of experimentation or not at least at least one consumer I think you changed.

A

I'm pretty sure, because I remember there being some bugs around it, I guess we don't have a paper document. Did we? How did we communicate before? Well, it doesn't matter so I would say like the work here. First of all, the work that has to be done in step. Two is we have to make a list of.

A

Code that uses with free VARs we have to we have to for each for each user sort of make a plan for how it will be altered, all right, so I think a number of them and just use the up for list I'm, pretty sure you changed, mirror construction or something actually I could probably figure this out with relative ease. So the up wireless map is accessible through the up far list. Let me just do a quick.

C

Code.

A

Search.

A

Yeah so Samir construction Russ, let's see it, looks like oh man. This is the weirdest I have to complain it. She sorry totally unrelated, but in github. For some reason it does never. It does not find like in this file search mode, mere construction. It just can't find and I've never understood lion and drives me a little bit crazy, but there's some kind of there's some kind of bug. There's a directory lip rusty, mirror slash build, but you see it's not in this list, so what I always have to do is yeah.

C

Go.

A

To some other thing and then pop back and then go here.

A

Anyway, uh so online 635.

A

Right so this this code here um is now using the up farthest right right and that you changed that I'm pretty sure nobody, that's part of this PR so similar to this.

A

But there there may be other code I guess. The question is to check. Where is the other code, but in which cases is discharged and I think that would primarily be harder to do if, for some reason that code comes before type check is done, you know type check, yeah and I'm, hoping we don't have any such cases, or at least we can find you know, solutions for each of them.

B

In the last call we had you actually checked that, and you said that there are cases where it is happening, but it's later well be have already inferred. So it's risk-free okay, I.

A

Sort of remember that, but I don't know where. Maybe you remember if, if there was a like I, think I just did that informally, right I didn't like write it down! Yeah yeah! It seems like a good idea to write it down, but I'm glad I did look at it already.

A

Yeah I have a memory of that, so hopefully that won't be too hard. So once we land step 1.

A

We can do step 2 and that, hopefully, is mostly gonna, be like.

A

Straight this out.

A

That's mostly going to be a matter of making these changes, and once we've done that I think those are all the.

A

Yeah I think those are all the bits of code that sort of all the places where we need to break the assumptions right and I. Think at this point we are then able to make the.

A

We're then able to make the tight check code kind of change. The captures.

A

Well: okay, in theory, we're able to make the typeset code change the set of captures and other things we'll just adapt to that change, but I realize now. Another problem is going to be the mirror.

A

Well, let's see so mere construction, I guess when we right now, we assume that an up for you. Basically, we translate at some point a reference to X to a reference to self dot X and we might want hmm we might want to change so that we.

A

So that we're able to like intercept you know, X dot, food or food up bar hold on I'm gonna. Make a question. Mark section actually did a little uncertainty here in my mind. So so what option would be.

A

Let's see I'm making a closure and I used X x, dot y right and today we will translate. Let's make it very obvious, what's happening, this is a read today we will translate to a capture of X. What we want according to RFC is that, logically, we capture x, dot y.

A

There is some concern that if you had, for example, a number of captures with the same route.

A

Let's change this to.

A

We might prefer to still just capture X by reference right and the reason would be that it's just less one, you know just more in it's fewer fields at runtime, right that would sort of be unsafe in the sense like unsafe, in the sense that the borrow checker you you.

A

If you wanted to write that, as in real code, you'd have to use unsafe code kind of because you're actually taking a reference to X but you're sort of promising that you'll only use the Y in C fields and the bar checker has to kind of know to believe you I I, don't know how I want to do that.

A

I think that is a nice optimization, I, don't know whether we would want to do that as a actual mirror, optimization after the fact or whether we would want to create the mirror with the optimization but tell the borrowed checker to type check it differently. I, don't love I! Guess, I!

A

Don't love either of those plans but I'm I'm nervous about telling the bar checker to treat the code differently than what it's actually doing, because it's the kind of thing we used to do a lot and it can definitely lead to subtle, bugs I feel I mean I. Guess this that's also true for the optimization, but somehow it feels different to me.

B

So whatever you said, should we write it on the dock so that we remember.

A

Yeah I mean so the question is so basically the question is: should we or two possible there are two possible approaches right either we generate code that captures X like a borrow checker understands, treat it as borrowing XY and XZ, or we generate code that borrows.

A

No rate code that borrows X Y and X dot, C and optimize it after the fact now this is kind of maybe kind of hard.

A

So, let's just let's just drill into this a little bit, it seems worth it so like if I take an example.

A

Here's a captured variable X, we'll put some we'll put two vectors in it.

A

And I'm going to like print Len for three vectors, so there's one we don't use I'm going to print these two things: X, dot, 0, X, dot, 1.

A

This code will compile, let's find out. Okay, almost oh.

A

Of course, it won't compile the whole play. This RFC is to make this code compile right. So we would all of this RFC is that line six would compile, but it won't because right now we're capturing all of X, which is fine.

A

But what I wanted to do? The reason I was doing this is I, wanted to look at the to look at the mirror that results blah blah blah.

A

How can I resize this okay I, don't know.

A

So, while using vexes, maybe not a good choice because it's college stuff- let's just do this.

C

Okay, right.

A

Toad.

A

So.

A

Here.

A

Is interesting: okay, I guess this is getting more optimized than I expected, but this must be the point where it is underscore to this variable. This must be the closure and we're assigning to its to its one field, oops just in there for signing to its one field, the the tuple, a reference to the tuple X right, and so my point was if we were gonna change this after the fact.

A

We would have to kind of alter this code, like it's pretty tricky right. We'd have to alter this code to instead of doing one thing to do two or three things we still obviously have to change the fields. This alone might argue why we can't do it after the fact very easily, because, okay so to make the change or whatever. However, we do it, you have to accommodate two concepts, which is the number of fields in the closure struct, and the number of captures right, and these right now are one-to-one, but.

A

But we would want to make them separate because yeah right, you can't do this, and so what that implies to me is. However, we do this. The layout code and other code that has to deal with the number of fields is going to want to be kind of aware of the final result before we even get started right, because it has to generate the right.

C

Size.

A

You can't change it up later, and that means that code is kind of tied to to the mirror. In the first place, we can't generate mirror that writes to fields that don't exist. Do you see my point yeah? So, let's see so so it seems like we're kind of getting to that. We can't they're. Actually, this approach is maybe incoherent, because it would, it would require us, alter the layout of the closure struct after mirror generation, and we don't currently on them mechanism for that, like that would require introducing two concepts of layout one.

A

That's like pre, optimization and one that's post, optimization or something I. Think we just don't wanna do that so.

A

That means we either. We only really have one choice, which is this, which is that we have to figure out ahead of time, the logical Barros and the actual burrows or the logical captures and the actual captures and some parts of the code are going to want to deal with the actual captures and some parts of the code are gonna want to deal with the logical captures, and now we get to another challenge. So, let's just assume we're doing that.

A

That's how we going to separate logical captures our check sees on the actual captures what the code does and how we have. Another problem is that if you look at where these captures these borrows and things are occurring in this code, you can see that we are we're actually borrowing so underscore. One is the variable X here right and we're actually borrowing it just kind of in this random statement. That's not connected to the closure in any particular way, and this is actually after optimization, but but this is really the closure construction.

A

This is just a normal borrow from our point of view, so well for us to know that, logically, this is borrowing X, Y and X dot Z, even though it looks like it's borrowing X, it's actually something. We sort of can't do right now, so.

A

What this leads me to so ok hold on problem. A set of her borrow check. Sort of Muir has no way to reflect optical versus actual borrows right now. The borrows in Weston are just normal. Borrows borrow Tucker camp obviously distinguish, unless we add some metadata, so I think what I would what I I think what we should do a is. We should probably try to introduce this concept of logical versus actual, but we prob, we probably shouldn't use it yet.

A

Violation, ok, still be sort of one-to-one I'm, not sure if we even want to introduce it, but it seems like it might be nice while we're going through all the consumers, we can try to separate them out a little bit and maybe there's two api's that go to the same thing or something or maybe we don't bother, but.

A

And I think we should get it working first with the inefficient version is basically what I'm advocating.

A

However, I think there's a principled way that we might want to do as a second step to add this notion of logical versus actual, and that is that, actually this is the problem like if you look at the borrowed track in general, there's just a general problem of you know. If you have a method like this I.

A

Have.

A

I.

A

Try to call bar I'm gonna get an error right now, because.

A

Because I have a borrow of self dot, a and calling bar requires.

B

Access.

A

To all of self, even though it's not going to use the field eight right, it's the same problem and I I would like to have a way for us in rust in general, to declare sort of that that four bar to declare that it only uses this field bar, so that so that we could type check this code. I don't plan for us to add that to I mean I have no concrete plans for how that would work in rust, but it might be something where we could start building some of the underlying mechanism.

A

Now in order to handle this yeah I mean basically what it would mean is that we would so yes, the same problem as this, and the underlying mechanism has to be something like borrowing X, but specifying the paths you can use from X.

A

So so I yeah I'm, not even gonna venture a guess as to what this indicted ad syntax might look like. Well, okay, I will I'm like you.

B

Know you might imagine.

A

Something like this I, a reference that can home the access bar that's kind of the concept we want. It seems to me like well, we could sort of do this in any order, but it seems to me like it would be nice to get to first get the feature working so that we can test it and deal with some of the other questions like even ignoring this optimization. There are some questions and stuff we wanted to play around with around.

A

When should you break it up into fields and so forth, um and then we could separately come take a look at this problem and try to deal with it. That's what I think makes sense. So, okay, digression aside! Well, that means that that already tells us that there's going to be a like step n, which is like try to optimize the representation of closures. You.

A

Don't know exactly what n is gonna be yet, but two separate optical from actual bars, um so step three is probably going to be so we're gonna assume still a one to one logical and actual bar. Oh then, I think what that means is we're going to want to probably in the type checker analyze the paths that get used and create more refined borrows.

A

Probably the first step is going to be I think we could probably land some kind of sort of write. The code that figures out what paths should be borrowed like some unit testing of this. So the idea here would be that we can have code that figures out and in fact this doesn't really depend on any of the other we're doing so. This is like a separable.

B

Before we go into step, three we'll have to build a feature, gate and stuff right, because at that time we will be starting to rate the performance. Currently, we don't have our gate good point very.

A

Good point. Yes, so that's the thing when you add feature gate.

A

Yeah this, so this actual change, I'm proposing doesn't blow strictly speaking, require a feature gate but I agree that making a future Gators. It could it's time for that, because now we're starting in on the feature itself, and what I was going to propose here is that you would basically have something where, like.

A

Where you can kind of write a unit test where you you had some funny annotation like rusty, underscore captured dumped on to the function on the enclosing function, and then we will emit notes or errors for each closure with in describing the past that should be captured on. Why and so I can give you an example. This is something I found to be pretty useful, especially in the early stages, often less so later on, but it lets you kind of land PRS that have tested code without having built all the mechanism right.

A

You see.

A

So like in the.

A

I think in the NLL we do some stuff like this. Actually around closures.

A

Where we put this right little unit tests, they have a funny annotation rusty regions, which itself is feature gated and any any attribute that starts with rusty is feature Gator automatically with a feature that will never be stable because it's not really meant for real rust programs to use, and then it dumps it dumps this. This information, which the details aren't important. But the key point, is it's basically like a unit test right, saying: here's something: here's some details about the closure.

A

We figured out how many external variable IDs it has and and what their relationships are and that way you can kind of check that stuff right. Yeah.

C

Thank you and.

A

Then later we would add, I don't actually know the details we'll have to look more closely, but we're gonna want to sort of define the or modify the off our list entries somehow to specify the path that is captured and we'll want to modify your construction to translate sort of a dot, B dot C into a reference to the OP. Far, instead of only translating okay and probably, unfortunately, will probably also have to there are some other bits of code that will probably also have to be changed. I'm thinking of the.

A

With something called the expression use visitor, which is sort of a predecessor ish to Mir, it's used in the old used in the ast bar check, primarily though also other places and there's like a few other bits of code that it will have to alter. Hopefully, if we move slow enough, maybe some of those codes will be factored away.

A

Actually, not the expression use visitor, though, because it's also used in closure analysis. It's not going anywhere, at least not for the short term, but still there's some advantage to moving slow anyway, but I think that's far enough away. We don't have to like do in too much detail, but once we do that, we're basically done with versions one of the features or so maybe this becomes step. Four I, don't know I'm sure we'll add some more steps as we go.

A

Yeah, a simple PR would be adding a future game. I guess the main insight here. Is it indeed this code that figures out what path should be borrowed is something that it's kind of independent from the rest right like we can write that code and dump it out and we're just not using it for anything. Yet.

C

All right.

B

So you say version one, so the what will be the version two on this one, where.

A

Did I say version one. Sorry, no, like step three is version. One.

B

No, you just say we will be done with the first word. You know the future I think I meant the unoptimized version. Oh okay, I see.

A

We want to think about whether to optimize.

A

And how I should add that I think figuring out the set of things that are SCAP sure it is not like super complex but not entirely trivial. If I recall, there's some subtle points in order to preserve execution order and stuff like that, hopefully we think it's documented in the RFC more or less, but that's something we're gonna have to think about.

A

Okay and all right. So that's that's a good overview of the whole path. Maybe we have a few minutes left. Do we want to dive into the error message stuff? You were getting or are there other question.

C

On.

A

Your mind.

B

Yeah baby, the error message, because then I think we can land this Bri yeah. That would be awesome. Freak.

A

Atlanta star: okay: let's look at that error message so.

A

Let me first of all make a link or let me get your message so the.

A

Yes, okay right, so the problem was that.

A

Here's the test so in a test like this.

A

Not clone.

A

We get this extra line in the UI right, yeah.

A

So what's happening here right in particular in this UI error message: you get an extra line here, okay, so the what's happening is.

A

As part of trait solving.

A

There's actually well well, I'm, just going to show you what's on master and then we can sort of hopefully you'll be able to see what's different.

A

Let's see so there's this function called constituent types for tie, so, let's see as an extra line in the branch, but the context is in selected, I, rest constituent types for pi.

A

So this function, what it does is it it's used for auto traits and it basically takes a type and gives you the Constituent types of things that are inside of it like for a struct. It would be all of its fields for something like a you enter in there's nothing inside of it. So it's just an empty vector and the idea is, you know, for an auto trait.

A

Something is send, for example, if all of its constituent types are sin all right and so for a tuple, it's just gonna be the list of stuff inside of it and here's the change we made right because today for a closure, it directly returns a vector of the captured up var types right. So today they for a closure for a closure. Let's call it C, you get back a vector like: u 1? U, 2! U! 3 of the up four types right and in your branch of the branch.

A

If I guess you get back a vector? U of the up for bull-type right and then we will break that tuple.

A

Into its constituents right- and this is exactly what's so, as it happens- the error message kind of tracks. This.

A

Each step that we have to expand like this gets tracked and then that's how we generate that dump that says like in the type such thing we did something else hold on actually I have the output here.

A

Right, this is from your message on Zulu, so the each of these lines comes from from one of those steps. So that's why you're seeing an extra line?

A

Basically, we added an extra step and I see two options: how to fix this I'm, not actually sure which one I like better option number one would be that we we modify this line in your branch to kind of do something more like the current behavior, so you could imagine saying instead of just returning the OP particle tie, we could inspect it if it is known to be a tuple, you just returned its contents else. We returned the two bullet. The problem with that is, besides being complicated, I'm a little bit nervous that.

A

Something weird will happen, basically like having a consistent return. Type from that function seems better than inspecting, especially inspecting. The state of inference is very fragile. Okay, so another option is to suppress this in the sort of print out, right, I, think and that I feel a little bit. This seems maybe better because it's less steep the question is exactly how to do it.

A

So, let's see what happens today, let me show you a little bit more detail where that tracing mechanism comes into play, so each time we have to prove something we have something called a cause it so like. If we have to prove that something is send, will have a cause saying why maybe because we called another function or whatever and there's inside this cause, there's a code which is the obligation cause code.

A

And one of the there's a lot of stuff in here different reasons: we have to prove things which we use for error messages, but one of them somewhere. Where is it? It's probably this one? Let's see derived obligation, cause.

A

Yeah I think this is it so I think this is where we build up a little chain. That'll. Have these things saying, like I, had to prove I had it's kind of just making a little linked list of the types that that I had to prove and then, when you see this error message, we're actually iterating through that linked list going going through the parent codes.

A

So if I jump to the Diagnostics file and have I'm gonna have to end this call in a minute or not quite yet, just over a few minutes, um the I think and did I schedule everything there's so many schedules.

A

Sometimes I just heard some calendar notification, but it was for something else. So, let's see.

A

Bates, where is it? It's called error reporting? That's what it is so in the Train error reporting code, let's see required because it appears right. So when we see a built in derived obligation, we kind of get the parent. We dump some information about the self type of the parent and then we recursively process.

A

The thing in the list, so maybe what we can do is just add some.

A

It's a little bit tricky, so you could look. I can see I guess. I can see two ways to combat this either when we add a link when we're when we're in a closure type. We kind of suppress that link in the stage or something off to look where these actually get created, but basically so that we create a shorter chain that doesn't include the tuple type and then that we could probably do with relative ease.

A

Actually, that's probably the way to go: um that's just better, but either we do it that way, or we somehow add a field or something so that we know in this code to ignore that link in the chain. All right, but I feel like. If we can add some way to note to ignore it, then we could also just not create it. I guess: I, guess what we could do in this code. For example, is you could look, and you could say? Oh if I'm looking at a tuple and its parent is a closure.

A

I won't print it right. That would be alright.

C

Very.

A

A very local change: it feels a little like a little hacky I would sort of rather not.

A

What is that? Oh, no.

B

I was just saying that if the closure takes in a legitimate couple, then that case not interfere with our. If statement. ah Oh, it should be okay,.

A

Because.

A

Because, right now it happens so right now. What happens is that you have a closure.

A

It always has a tuple of up FAR's leg and then, if there's one of those up FAR's is a tuple, then it would have a tuple which is the individual of our right. And so when we go to print the okay, its first tuple.

C

Its parent is not a.

A

Closure it's another tuple right, but it still feels kind of hacky thing. Cuz we're changing these two parts of the code, there's! Obviously no! You know it's kind of a don't repeat yourself violation.

A

If we, if we then change again the constituent types function, then this code is now wrong with there's no reason to so it's sort of. Rather, if we can make it more local, but let's see where does that actually happen? It's probably not too hard hold on so I think I think what happens? Let's see, Constituent.

A

Yeah, so you see so this. What this function here is doing confirm. Auto, imple candidate is saying.

A

Given, let's see I'm just gonna leave a few notes here: I guess we have the video open anyway given given that you know like, given that you're proving sort of t send greater returns, it returns a list, among other things, of other things. You have to prove right, which might be like. If T happens to be, let's call it t you send eg, he send you send right, so it's gonna kind of and it and it calls constituent types for tight to do that. And then it calls v table Auto imple, which.

A

Which does some stuff- and this is the key line. Okay, this part is not important. This is building up the traits, it's like taking the types and putting them into the trade itself, but this line obligation, dot derived cause.

A

That's interesting that we get imple derived obligation.

A

Sorry hold on a minute. Let me look a little more closely. Yeah, no problem.

A

No, no I think this is wrong. This is the line.

A

Obligation derive cause built-in derived obligation. Oh, this line is where we're actually making that chain. I was talking about I, see, and so what we might do here. We could instead sort of say: if this is a closure, then don't use the derived cause, but instead use like obligation. Clause clone.

A

Okay, so could check here and say make sure this is a permalink.

A

If this is a derive, if the self type is a closure, don't.

A

Don't make a derived up with the right cause, but just use obligation column.

A

We could make it, maybe even a little less a little more local by saying that, maybe the return type of constituent types for tie instead of hard-coding, that it's a closure you could say or maybe make its- that you went I can't spell that word. Apparently one statue and pipes for a tie, return, sort of a vector and a boolean or something where the boolean means you know make derived cause, and that way we only we would literally change.

A

You know we're putting all the decision in that one function, which feels good, um so I think that's what I would do. Okay and this line you can leave alone. What this is saying is it's going, and this is this line is making this the sub obligations based on the type, and this is making other obligations based on the trait like if the trait has super predicates or something like that which actually are illegal now. This is probably no up anyway, but it's a different thing different different.

A

It's not gonna reveal the presence of this tuple so yeah. So that's what I would do I think. That's the right strategy, we'll see what happens but I think that will be good.

C

Sound good yeah, yeah.

C

Hey this was.

A

Fun so I guess what we'll do overall you'll try that out. We can pull this list here, I mean I, guess I can just move the heading down. This is kind of our roadmap and then, when next time we talk, we kind of already know the plan. We can figure out the next step, but it seems like maybe this could be on. This is a something I can do it's not too hard. Oh.

A

Wait I remember now, there's some way of tracking this section hold on a second okay.

A

I'll assign that to myself and you're going to change the type check to actually generate a tuple. This is what you're basically doing fix the I.

A

Got to make it all look pretty I can add your help. Okay, great now we don't need to use this double strikethrough, I guess in a particular fix the error messages around trade selection right.

A

Which one is you this must be you, okay, all right cool, then we have a plan see you later, but by the way, what time zone are you still in this time zone? You're in it also next week.

B

Yeah I'll get back March, 15th, ok, cool.

A

Well, maybe we'll meet again at this time. Oh yeah.

C

That.

A

Works for you.

C

We'll talk about owns it yeah see, you later sounds good. All right see you later for.

B

Your.

C

Time, bye, all right, bye.
youtube image
From YouTube: RFC #2229 Disjoint Field Capture Plan

Description

We discuss the overall strategy for implementing RFC #2229, pulling together a rough roadmap including a number of refactorings, and identifying some bits of work that can be done independently.