Add a meeting Rate this page

A

um So do you have a plan? I.

B

Want to talk about migrations like okay,.

A

Before.

B

We talk about that. I want.

A

To talk about the pr.

A

I read it and I think it's looking pretty good, I could probably just r plus it the only thing that I thought was the set of tests in the pr looked a little meager and I couldn't remember if there's a bunch more tests that I kind of forgot about like.

C

So there are a couple that are not in here for well. There are a couple of things I wanted us, but I'll slowly add those tests once you fix them, because what I'd initially done was uh I added them? They just don't work because patterns are immutability issues, okay, okay, so those will be. I I want to add them as I fix them. So that's like if someone looks at a pr like yeah.

B

Yeah, if they see.

A

Okay,.

C

Why they're relevant.

A

All right all right, I think, I'd be happy to r plus. I was trying to think I feel like there's a lot of corner cases around things like finding the minimum ancestor and stuff like that which are not really being exercised by the test. A year ago, like.

C

Actually, life patterns and stuff like that, but I guess those were tested by the earlier pr which then had like the procedure. So we did that. There's one test that does this. uh What I'll do is I'll look at a couple particular tests here, because uh we still see them failing because, like we now see precise volatile errors, regardless of us fixing things which is nice.

A

I still.

C

Think some of those.

A

The one I guess I still think it'd be nice to have some run past tests that just exercise uh capture exercise not necessarily min capture but places that are more complex than just a b like, for example, indexes or um stars of box stuff, like that.

C

Okay I'll add some of those yeah. I I have tests for them, though those weren't really uh okay, so I mean they should work right like the same thing, they should write if you have, but so what I would have done is like I I guess we should add test case exclusively but yeah well explicitly. uh I did come, make the whole test, the whole compiler other things, so you.

D

Did you're.

C

Saying, yes, I did do that so and we can go with the perf as well.

A

I mean I feel pretty good about it. I just I would.

D

I would like to make sure we're.

A

Actually,.

C

That makes sense uh yeah. I think I was doing the compiler, where I found out that the migration issue might be.

A

And the current status after this pr is basically it works, except for a bunch of small bugs.

C

uh Yes, categorically speaking three main issues, one is when we have mutable references.

A

Then.

C

We have moves uh that and the third one would be unsafe pointers.

B

And.

A

The moves we had talked about modifying moves to only move interior pads.

C

Yes drop any drafts or any projections after and then well of course, any projections after that. That's what uh that's not implemented, though uh that's I have comments for them. I have tested them because I needed to do that for the whole compiler when I was doing the whole compiler test, but they're not, but it's they're not in this pr, just because they're small patches, no.

A

I think that's good. um I still I'm not sure. If that's the right rule, I think we might, we might need to go with the like dumbest rule of move just means capture all the local variables, but that was something I wanted to bring up. I was I was thinking we should schedule a laying team design meeting to talk, probably not till the new year. I guess I don't know whether you all are available at our usual slot. It's on wednesdays, at 1 p.m. Eastern time uh I.

C

Will be available well not next week. Next week is last week of my internship, so I'm not going to marry that, but nothing after that after next week, I'm free, but I'm assuming everyone's gone for a holiday. So.

A

Yeah, I think it would be like january.

C

January 15th, or something like that yeah, that's that's fine yeah! We, our our winter break, is still like january 11 this time. So we have a lot of time to kind of protect things and like test things out I'll.

A

Ping you all in, uh but this is going to want this- is going to be a bit of a judgment, call yeah either way. Let's talk about migrations because it's going to be relevant, I was going to discuss something yeah.

C

So one thing that was brought up during the rfc was and I'll send a link again here, uh it's similar to what we were discussing last time and I think it's maybe written a bit more formally. uh It's on the zoom.

C

Chat.

C

So was essentially that we add, from what I see is basically instead of removing a draft. What we see is that, if our base type was in a reference, we add a border to, it is kind of how I'm picturing.

E

This.

A

uh What am I reading here? uh The rfc is about how captures are split up, so the questions.

B

So.

C

At least the way I understand this is we essentially enforce so, let's say we were we had. We had a mutable reference or something, let's say uh some point and we capture star, p, dot x and instead of since p, our base type was a reference itself. We essentially add a border on top of this and then move the borrow instead of moving star p dot x, which is a value.

A

Yeah, so this this, what sam sartor wrote here we had a hackmd last time right. Yes, we did uh it's, I'm gonna get a ratio.

A

This must be, it doesn't have a very good title.

C

uh Which one was move out of references and okay? I think I should probably make it better.

A

But I I can yeah it's called well. If I'm opening the right one, it says like issue 31 at the top.

C

Yes, it is 31., okay, so.

A

um Let's see.

A

I don't know whatever so you have it open. I have it open, yes right, so I think I think this rule that sam describes is um the same one that I arrived at yeah, but where I wrote possible extension on.

C

uh I thought this was more around the option. One we were looking.

D

At maybe but uh yeah possible. Actually, yes, sometimes.

A

Capture by reference- oh, I guess I'll share this- why not maybe okay! So this this extension here! um I think that that's exactly what what he's saying is exactly what I proposed there.

C

Yes, my I'm I'm trying to see where the complex lifetime interaction is coming from, because earlier again we are moving earlier. We would have moved a reference. We are still kind of moving a.

A

Actually, this is this is interesting because it's connected to.

A

um

A

um The the new match, the the match modes- change that we recently introduced a few years back. It's not sure if.

D

You're familiar with that, um I am not. Is it the ergonomics one.

A

Yeah, I mean like if, if you have, if you do this today,.

A

Or well, you can't do that, but oh bother.

C

Some um okay yeah.

A

um So we wind up turning this into a reference, because you kind of pass through this reference. Oh I see that's what we call a borrowing mode and that's kind of the same rule. I hadn't actually seen that until I read what sam wrote there, that's a good!

A

He didn't explicitly make this connection, but the idea is the same. That sort of when you capture something that's borrowed, you're capturing a borrow of that we're propagating.

D

That yeah.

A

Yeah exactly, I think that is probably the rule we want. uh It is not.

A

It is not this truncate on d referral, yes, I think so it's um an extension of it, which is why I wrote extension like it. Sometimes. Basically, you would still truncate a draft, but only for boxes or like, but not for reference dress your truncate drafts that are of other things, which in this case.

C

Yeah, so that's what I was thinking like again in the rfc. It was discussed that we probably want to special case box and what I was thinking over the last week was. Maybe we should not use box other motivation to do some of these things, but rather handle bots as a thing of its own.

C

I do not know what the complexity around that would be, so the problem is.

A

I still, I still feel like.

A

I don't know, I think I think we should defer this question. This seems to be a policy question and we should take it to the lang team and it would be useful- and I can try to do that- who write up the like options and interest races. I think I have a pretty good handle on that and I can write up the things, but in the end of the day, this is a policy question of like what policy right. It's not an implementation problem. It's a problem, who's, the right thing for the language.

C

That I think they do, I I sent a doc last week, where I just kind of documented some of them with examples. uh If you want to use.

A

Yeah yeah, is it linked somewhere.

C

It's on the zoo, I send it in the status meeting from last week. I'll send it again here. It would be great to jump in this.

A

Dump it in this document.

C

All right I'll link it here and I can just add it on zoulip, as well as the 2020 status right. Sorry, not on the.

A

One github, oh okay, it's fine! What I would like to do is talk about implementing the migrations. Yes, one thing I will note is that these rules are all about move closures like we have to consider, move and not move closures.

A

I don't know whether they should behave the same or not, but like I have opini, that's something we have to decide. um However, non-move closures, in my opinion, like what am I saying so they I think, there's prob there may be room for them to be like am I saying whatever they do? I think they they'll probably want to be, at least this precise. This is what I'm trying to say.

A

So you don't you don't want you don't want it to be that you move a dot b, dot c and you capture a that's like two too strong. I think you just want to capture it.

C

um Yeah so my my concern comes around that moves behave differently in a move closer versus in a regular closure, and I understand that it's because of well the move keyword. uh I do not know if that will add to any confusion.

A

All right, that's the policy we have to decide, but I guess the point is that, like.

A

We should think about all I'm trying to say is: there will probably be some subset of cases where moves occur differently than they used to, and that might be for all closures, or it might be for only like non-move closures, but either way we need migration.

A

So we can try to.

D

Implement the.

A

Migration and then decide how often we have to use it separately.

A

So, okay, because.

A

Yeah, um so the question is how to implement it right or what or did you have other questions about migration.

C

I did not. I just had concerns about the issues that we discussed, but again that's a policy thing as we discussed so.

A

Yeah, um why don't we?

A

Why don't we talk a little bit about it? I'm gonna make. I don't know whether to just dump it into this hack, md or maybe I'll make a fresh one.

C

We have a couple issues for migrations. We can drop the hack company in one of those I'll link it to my 2020 status, doc.

A

Okay,.

C

Or if you want to just write it in there I'll send the link again here, there's two: we decided section for migration anyway, so.

A

Where are you spending what.

C

uh Zoom chat right.

A

um So there's a I see, yeah great migration plan. ah This is cool. Okay,.

A

So open, no, I'm trying to find. Why can't I find this right now um there, a migration plan. Okay,.

A

So.

B

um So, although you want to share, yours, uh probably is getting let me let me share that make.

B

Sense.

A

So what I'd say is, in some cases.

A

The.

A

Closures will capture different paths or different places than they did before right, and this affects the runtime semantics, because or actually what they all do is not just different but narrower places than they did before right. um Nice never ever sounds funny. uh I don't know why.

A

uh It affects the runtime semantics, because the destructor for the or because the destructors can run at different times in the older version, the destructor for the base variable x would run when the closure was dropped because the closure owned x in the newer version, if the closure only captures x, dot y and the destructor for y will run when the closure is dropped or for the field y.

A

But the destructor for the remainder of x will run in the creators scope. All right.

A

Does this all make sense, yep, okay, so work around is introduce left x, equals x into the closure, um and now I can make an observation. A few observations.

A

This only matters if there is a or let's let me start with this, not all destructors.

A

Matter or uh let's put it this way, let me rephrase it a few destructors actually have side effects in practice, most just free memory.

A

Most users, don't really care.

A

When the destructor runs as long as it runs um and or they would probably prefer the memory to be freed earlier- which I don't know- which it may be or may not be.

A

With the more precise capture, the reason I say that is, if you make a move closure and you return it from your stack frame, yeah you're, going to get straight just living longer than your stack frame. So, but on the other hand, if the closure does not escape the stack frame, then that's not true, but in that case it's probably not anyway. The point is my hypothesis is so long as the destructors are only freeing memory.

A

We don't care and I think we would be doing users a disservice if we migrate their code, um such that you know, if we introduce let x equals x, just because some string might get free to slightly different time. uh That's my consensus. So.

D

Long as.

A

The destructors only free memory we probably or we should not try to preserve their ordering or precise ordering through automated migration. um We could have an opt-in.

A

Maybe I don't know we don't have any mechanism for that uh right now and that's fine. um I wouldn't worry about it. It's just really easy to change. um What I basically want to do is how I think it should work is we should detect if the no longer moved content has a type that may have a sort of significant destructor.

A

How do you define what a significant destructor?

A

Well, probably, what I would do is annotate destructors in the standard library with.

A

Some crazy attribute.

A

And everything else is significant, so we essentially have an accept list or something uh and uh the point being now.

A

um Then we have to sort of walk the type of each path you know of each non-captured place or no longer captured.

A

And see whether it may include uh to see whether it may.

D

Include.

E

A detour.

A

um That makes sense so far.

C

Kind of I would yes yeah, that's just technically. We just refers to it, yeah that that makes sense. It will be interesting to see uh wait. Are you allowed to put attributes on standard left definitions? Isn't that okay.

A

The standard limb is um tied to the version of the compiler that is building it. Basically, so uh you can have like nightly unstable things in there that's kind of a standard, lib special. It's the only the rust code that can ship unstable things in stable. um We have to be very careful too.

A

You know um and yeah we'll have to write a little bit of logic to like say like if you have a tuple, you know whatever um it has to know there kind of is code for doing this already have to be slightly adapted, there's code for figuring out. If we need to run a destructor at all, we would have to like tweak it with a boolean or some kind of flag. That says, like.

C

If significant or something.

A

Yeah and there's a little bit of other logic, we're going to need to like say here's the place that is now captured, so don't walk the types of that come from those fields. You know.

C

Yeah, that's apparently it's going to be interesting. That's going to be an interesting, oh yeah, so this would also need to be done after a type check, because that's when we figure out what's being captured, yeah.

A

This can happen like whenever right, okay, so it can be pretty late um and actually it wants to run in the old edition. So it's gonna want to run.

A

This is kind of a nice thing, or it's good that you have the code, which is computing, we're going to need to know what the precise paths are.

A

Yes, we can do that even in the old edition like even when the feature is turned off, we can fake it yeah, I figure we can because if I remember you're doing the analysis now and then you're like adding some moves later right or something to go to the local. Well,.

C

We just well we just uh faked like well, it's not fake. Really, we just initialize uh reads for the upwards that were mentioned, and that will just force the min capture to do things did.

A

You do that at the end right.

C

We do that at the start right now, because we realize there's no reason to move it to the end, but yes, uh well, not until recently, but yeah we'll probably move it to the end yeah now.

C

The reason we want to move it to the end is because that allows us to prioritize the things we see inside than just whatever fake things we created uh earlier and in the sense that our algorithm prioritizes what we see earlier over things we see later, and it just forces any kind of fake information that we are adding into there to be as less uh of as little priority as possible.

A

I sort of remembered that, but I think this is a second reason then, to do it at the end, because we're going to need to be able to diff what would be the most precise path with what actually got captured and so okay.

B

Yeah.

A

So so you'll have to save it off or something, but right so we'll do that and then.

C

I'm assuming there's some kind of like context right that we are doing uh this particular uh analysis like we're doing this migration analysis or whatever you want to call this.

A

Yes, so it can just run at the end of up our analysis right.

C

Like capture analysis, not up our analysis, actually, no, we we don't really need that. Yes, you're right, I can just think that, so what would be have been previously captured to what is now being captured is essentially, uh of course, mentioned, was being what is was being really captured before, and this is what has been captured now. The only question comes down to is: uh do we need uh I'm forgetting yeah? The moves is what what we really care about, so we might need to figure out uh which parts get would have been moved really.

A

So know that by the end of type check, essentially.

C

And yes, but what I was thinking he was using uh upwards mentioned directly to figure it out, but uh yeah. This is possible to do something of this sort.

A

It should work, I think, we're gonna wait. I think you have to do it at the end of essentially.

C

uh In in check, yes, yes, so there's two analysis right. One is when, when you software analysis, it confuses me for, like the very first pass that happens for things that are just mentioned and when I say caption analysis like the second one, uh which is the type check one.

A

No yeah, we need it after capture analysis and it. I think what it's going to want to do is something like. If you're doing the analysis, then you you save the value of the captures, you might make a clone before um before you add in the new and then you just.

C

Meant capture all over again and then.

A

Then you add in the fake reads of all the mentioned up bars and then you have the the two versions right, because you have the one you cloned from before and then you have the one that's been modified.

C

When you add it, you need to run min capture again, but yes that will work.

A

Okay, very very um yeah and uh yeah. So then the point is it will be like zero cost. If or what's nice about, this is you're gonna. Do the clone sort of into a local variable during the upvar analysis, and that means you'll you'll drop that local variable when it's done so we won't like expand the memory usage and so forth. In particular, it never has to get stored into any query results.

A

Clone the captured variable data before adding in the fake reads of mentioned, upvars and sort of add fake reads of mentioned. Upvars. We run capture analysis.

A

Now we can diff the results um and I think, a good place to start. I guess is like this is a plenty of challenge to get all this working, but once we do have it working, we will have a list of um local variables that you know may contain a significant.

A

You know we could do this, that we can do this. The approximated way.

C

Okay, what do you mean by the approximate right here.

A

uh So, there's basically an analysis that we want to run this like it's like given, uh given the captured place, given the minimum captured place, it returns.

A

I guess it only needs the minimum captured place because we always used to capture the whole variable returns. True, if.

A

The local variable may have a significant destructor in its type and that destructor is not or is found somewhere outside the captured place, and my point is this second part is optional, because that's like more precise, but if I had to take a guess, I would guess that most of the time, it won't matter so quiet, sorry, guys I'll give you an example of what I think. It's probably worth. Writing writing a few examples to show what I'm talking about unless you're completely following and don't think that's necessary.

C

Examples would be nice, but I do think I'm following you.

A

Okay, well, here's an example anyway, just because um so you know you might have some code like this, and this is an example of changes semantics. But who cares and the change in semantics is like x, is dropped, sorry, x, dot, one is dropping and the block exits not when c is dropped, yeah just slightly later or the ordering is changing, um and uh if we change this to so this case.

A

This is actually kind of the same because yeah, who cares? Because the thing that's changed, is a string.

C

Yes, you're right and this.

A

Converter.

C

Dropped, I start one. This is different right, yeah, all right that works, sure yeah.

A

uh But what I'm basically arguing.

A

And.

A

What I'm basically arguing is maybe this case.

A

This is the optional case, so I'm saying that if we make the analysis simpler, all we would do is say: does x anywhere have a significant destructor, yes or no yeah. If the answer is yes, then we'll conservatively transform it. Even if, because we happen to capture the significant destructor, it doesn't actually matter um and then we could go back later.

E

And make it better so.

C

That's kind of where my question was coming from is like when we do this type analysis sort of thing, how do we figure out? How do we plan on storing the path itself that, where the like, I know it's optional, but if we were to do that, how do we store that? Oh, if the path that we take is, uh let's say let's say this- was something complicated again: a dot b, dot c and or- and we had again an a dot b, r d. How do we store that.

A

Yeah we'd have to write some code. I don't know where I'm trying to find the right. The best thing to.

C

Like the way my head was around, this was like: if we can get a list of all significant uh drop pods and we can represent it similar to places we can again do the similar ancestor analysis, sort of thing we do for min capture and that will give us.

A

Yeah, that would be one way: it's probably not the way. I would do it, but it would be one way I think oh needs drop. I think as well as cool, so we have some code called needs drop.

A

This does not do what we want, but what this does is this figures out, um so needs drop figures out in an approximated way if any part of this type may define a destructor basically um and but it only considers the type.

A

So what I would probably do, if I were going to write this code, is make a variant of needs drop that takes the place as argument takes an optional police and, and it kind of matches up the projection, so it would be like okay, we the place is that the place of the sort of the local variable or whatever, and it would say, okay, the first projection- is the field f.

A

That means the look of a will better.

D

Be a struct.

A

Because from a non-struct and if you look at how needs drop is implemented.

A

What you'll see is it basically says? Okay, it calls needs drop component wherever that is, um but basically it matches the type. And let's say it's just.

A

Okay, this is annoying, but the code is like kind of generic and weird, but the the point is this is a good example um for tuples. You know it goes through each of the fields: false needs to drop on the tuples yeah, and so what I'm imagining is. You would look at the place and you would say ah this is the dot one field I'll go through all the fields that are not dot, one of this vector and dot one I'm just gonna, ignore it because well, okay, that makes sense. That's actually not quite right.

A

You have you have to get to the end of the place before you can actually ignore it, but what you would do is you would have this optional place, that's like if you match this place, or maybe it's an optional slice of projections. Actually, if this slice is empty, then you found a match. So you can just stop here because that's the place that got captured, so I can ignore it.

A

If this is none, then I always do all the work, because that's some part that I didn't capture and if the slice is not empty, then I like pop off the prefix when I find that part and otherwise I pass none. Does that make sense? um I.

C

Mean sort of like I get the general idea, I think when I start writing portugal just kind of makes sense. Also like we really just care about adts and doubles here, because that's that's. What introduce our field projections right and I don't know, what's happening with ddos and the situation, but again it's just like it will provide us access to another field. At best you.

A

Guys are actually the easiest case right because there's no like there's only one like it's like a few there's only one of them. So it's always a matter.

C

Yeah.

A

Exactly yeah yeah, so that's how I would do it. I would probably not do that to start, because I think that's a beautiful follow-up pr and it's not the hard part. We haven't gotten to the hard.

D

Part.

A

Yet I would start just by using needs, drop, um okay or a variant of needs drop which we'll have to define um that I mean honestly, we could actually just start with needs drop. Yes, I think these droppers and not even have the idea of significant destructors, because yeah.

E

We can test all the hard.

A

Code with local copy types um yeah so then make needs, drop, understand significant destructors, and then these are like the refinements. We can do um now. The hard part is this one. We come to some list of local variables that used to be captured and we want to have backwards, compatibility around them or, and I'm just going to say, and they may have significant detours, um which we can define what significant means in more and more refined ways.

A

um So then, this is where we have to make a suggestion to modify the text of the closure in some way, and one thing I will say that it's relevant here is: if I guess it depends what comes out of that linkedin meeting, because if the, if what we decide is that move closures need like, we need some more complex syntax for people, so they can more conveniently handle some of these annoying cases that may affect what we do here, because right now, the only workaround we have is let x equals x inserted into the body uh which is okay.

A

But you know it's kind of annoying we have to if the closure doesn't have a block. Already, we have to add x kind of at the front and uh at the end you know else, and the nice thing is we can just we can make these edits really gross like the formatting doesn't happen.

A

It just has to tokenize so that rust format can run yeah yeah, but it's still gross like whatever we do. It's going to be grody hacky code, it sort of says I mean yeah.

A

uh It's not the end of the world, but it could definitely work. um However, imagine that we added a syntax like move. No, no, no, like suppose you could write this. I don't know yeah, which kind of says I want to move these.

B

Two.

A

Kind of like the c plus was doing that yeah yeah. I don't really know what this syntax looks like, but let's imagine that something like that. This would be an easier transition for us to make like. If we have that syntax we should use it. Yes,.

E

That actually is way better than what I was suggesting and, yes.

A

I kind of suspect the outcome of this meeting may be that we want some syntax like that, like it's been kicked around for a long time that there's kind of no when we designed closures because of the way my brain works, I thought it's perfectly acceptable to have the like capture clause.

A

Be written in this form like make a block that has a bunch of lets and then a move that just uses those lets and that's like a capture clause, not really right, but it has the effect.

E

Again, this is very close to see us.

A

Like yeah, the point is all I mean is that the the move closures are fully general in the sense that they can express any possible captures. You might want to do if you use this sort of yeah exactly.

D

But.

A

Nobody in their right mind thinks of this, except for me, you know.

C

Yeah, I think the at some. This was just like work around that I heard on the rfc yeah, so.

A

Right and another one, that's very common that I've seen people complain about. Is this.

A

Yeah well, this is something I do all the time but, like I said you know, I've shown it to a few people and they're like I never thought of that. So the point being we're actually missing a syntax here, and maybe we need to answer this problem uh and maybe that will give us a better transition.

A

Unfortunately designing that syntax is like non-trivial a lot of interesting questions. um Well, not impossible. I don't know you can do it.

B

So.

C

I I.

B

Guess.

C

Still still comes down to, where do we insert this text right.

A

Yeah, it's not going to be that much different for you in the end of the day, they're both going to be textual edits. The only difference is in this version.

C

I I guess my question was more around where in this curve, we force this actual edit to happen on the user's code. Oh.

A

Sorry, well, we act yeah, so what you would do is you would once you have this list and let's assume we can generate the edits in some reasonable way. You make a lint and that lint carries a suggestion.

A

Oh and cargo fix it. That's right! That's why we do migrations. We we issue. Lints and people run cargo fix to move between. um um We have like edition or something okay,.

C

All right, so I guess.

A

The first problem comes your job, I'm saying it's, not your job to actually apply the edit. Your job is a suggestion.

C

Okay, that is all right. Okay, that is a little nicer, uh yeah! Okay, so I guess you have the challenge for next. Some weeks, for us is just getting this as clean as possible. While we get whatever open peers are in before winter, we break it. Yeah.

A

When is it, I will say that this this let x equals x is probably not that hard. Yes,.

D

uh

A

It's a little grody, but it's not as bad as I first thought it was going to be because I think at first I thought it was going to require the the ones I really hate are the ones that like read the text, the user wrote and try to like re-parse it a little bit to figure out what to do. Wow.

D

But this one, I think we have a lot of information already so.

A

um But really like there's plenty of code to write just to get to the point where you're ready to make the edit in the first place. You know, like you a good first pr, I think, would add the lint just using knee drop, not any of the smarter versions, but without a suggestion.

A

So just start giving warnings where the semantics might have changed. Okay, yeah that and you can come back and add the suggestion, and then we can make the suggest light and then we can refine or we can independently add suggestions and make the lint more targeted. Like.

E

That makes sense.

A

Yeah, it could potentially all go in one pr2, but that's how I would implement it at least.

B

I think separate would be easier to get quick quicker review process also.

A

True yeah, I will definitely to the extent that I will work over the break. Like I said I would love to help you all. I don't want you to block, but yeah small pr's like I'll, have smaller bursts of time, so small pr's will be my.

C

Yeah that makes sense uh yeah okay, so I have some somewhat of an idea here. I think that's good enough to kick things off uh yeah. Another issue that I missed was like our issue around uh patterns and uh the I don't know if you like that, it's extendable to like the functional update pattern as well. So if you scroll up a little or if you go on the view thing like the third option, hack md as and then there's the open, bugs and migrations and then there's the first one uh yeah.

C

So we have patterns, we don't have these structured patterns, just don't work uh at all right now, and that is mostly because we expect like we have work around for this. So this is not too big a concern, but at some point I think this would be we have. How much time do we have? Oh, we have terminals. So maybe we can just discuss this a bit more detail because it's patterns and then there's also the struct update syntax, which is like the point doing this.

C

That also doesn't work for the exact same reason, uh which is the place, is completely mentioned, but only partially captured and if it is partially sorry I actually okay yeah. So if it's partially captured also wait, I I feel like okay, never mind. No, I had fun up and down. While I listened to it. No, no sorry, my I got a call and then uh give me one. Second, sorry.

A

Yeah go ahead.

C

Yeah uh yeah, so essentially the issue is the same thing. We have a place, that's completely mentioned, but that's mentioned in the uh uh in our code within our uh closure, but it's the way we capture it does not express it as uh as completely captured yeah so, and this extends outside of just patterns.

A

Right I mean we've talked a lot about these cases and that was sort of part of the motivation for the whole place. Builder refactoring.

A

um Is there.

D

Anything.

A

New there or is it that in terms of patterns or is it that we have to we just haven't tried yet to I, I haven't tried.

C

We haven't tried this yet, and I'm just want to discuss that. We'll probably just have to do this across more in, I think like across the whole, build at this. I don't know if it needs to be across build or not is I guess my concern uh are because now we have this functional syntax one as well.

A

There's this case, there's only two cases.

C

Yes, I'd! Yes, so I don't.

D

Know.

C

This.

B

Is the one.

C

uh Where I don't think this is entirely this is this is a separate issue.

A

This is a separate issue. That's.

C

A separate.

A

Issue, um I think this is probably relatively easy for us to fix. uh Okay, there's an analysis that takes place in right back to figure out and I don't see any reason we can't sort of move that code earlier.

A

Okay, I just didn't have a reason before but like all the types are known: that's all we really need so yeah.

C

So, for the uh mentioned one, we just basically replace most things and place, build uh and more ability to use voice builder, or do we still be now without the ones above? Do we still be a little bit more conservative about it?.

A

I would ignore these for now: okay, they're, just they're, like just refactorings from my view,.

C

Yeah.

A

Okay, I don't have any fears that will run into surprising problems.

C

Okay, and would you want me to submit a worker on pr for this so that it would be nice if people, if they're they're, weird cases that people can there are other people that can think of when they use this? So I'm wondering if we should have uh it is a workaround pr like. Should I create a workaround pr?

C

I again, I just created a comment when I was trying to get the compiler to build with this feature, so I don't know what a workaround pr means by that I just mean well appear that has the workaround, where we, if you look at the comment, we essentially.

A

Oh, you mean like edits to rusty that work around this problem.

C

Yes- uh and I can like this- is the general solution, I can just add functions which are actually just named fake consume for two to nine. uh The first one isn't really relevant. It's just the second file. That's right.

A

I would land this pr. Yes only I like the idea of naming them like fix me pr, fake concerns, yeah. I think that's.

D

Yeah.

A

uh Yeah, I would add that for now and file an issue to to resolve it some future all right. I am much more worried about this.

C

uh

E

Yeah.

C

Again, this comes down to the migration issue like if I.

A

Just add this is a case of migration that isn't covered by what we talked about.

C

uh This would be, or should be from whatever.

A

This would be because well no, I mean it would be, because this would not be oh because of drop. Yes, it won't work because of our drop condition.

B

This exact example.

A

Probably would work because we don't know what the drop or we could. We could probably make a assert unwind unsafe in some way be considered a significant destructor.

C

I don't know if you go in the issues again, I think issue 29 uh issue 29 28.

C

yeah, and there was like another example that I put up there uh like scroll to the bottom, where we first send and sync yeah.

A

So people.

C

Might want to wrap things.

A

Right, I mean I think we can probably make right. We can potentially make some of these examples work, but the general case worries me because it's easy enough for someone to write their own pattern and there's no way we're going to migrate like if uh any trait is implemented by you know like we can't tell that question yeah exactly no. We only we plausibly, we could figure out.

A

Something.

A

No, I don't know I I don't I'm not. I don't really want to get if the migration needs us to be like super smart, smarter than it's already pretty smart if it has to get smarter than what I've already described. I don't I'm worried, so this is part of the reason that I I feel like there's a case for move capturing local variables only.

A

I I still feel weird about it. Also I haven't figured it out, and maybe what we want is just a shorthand syntax for move yeah that you capture only local variables and which is sort of what you suggested already but yeah, but I would tie it into a more general closure capture, syntax and it just has some and then all we do is every move closure like no matter what becomes that shorthand.

C

From now on,.

A

Yes, exactly that that would be a plausible route that I'm happy with.

C

um Yes, uh do we want to offer that shorthand syntax for non-move closures like if someone wants certain things to be just bottomed, completely yeah, I don't know all right.

A

Okay, uh I mean maybe I I.

D

Feel like completely.

A

We have, you have to see it in all right.

A

Like convincing.

C

Yeah, okay I'll see, if I can find some things.

A

But yeah all right, it seems plausible to me that this just doesn't come up as much without move closers but yeah I mean this is an interesting example, because I actually don't think the move is necessary here.

C

I okay. Actually, if we go back to the um maybe I might have just copied this so yeah, I never mind yeah. I think I just copied this over. So it's probably not the different thing. But if you look at 29 again, we.

D

Can confirm.

C

F, I mean.

A

It might move that or.

C

Not okay, no.

A

Bad move in it, but I think it would compile without move yeah and uh same probably test this right. So this might like sort of validate my hypothesis or something um that this won't come up without move.

A

So does this compile.

A

No because of some used stamp.

A

Okay, so I think if I take this out.

A

Yeah, so maybe what I'm saying doesn't make sense- and maybe this is like, but I I would not be happy if we changed every single closure to that new syntax. That's a little. I would want to be a little smarter than that. Every single closure I could live with because those are pretty uncommon.

C

And well, I was going for every move. uh Well, everything.

A

That's moved.

C

Goes into that syntax, not everything! That's in that go goes there. If that makes sense.

A

Yes, yes, so that we could possibly if we had a syntax that was like this a bracket. I don't know what it would like.

C

Yeah yeah, actually, I guess that makes sense, move without an empty list or just a list will move everything and move like that. Like.

A

I could imagine if, if you have a closure like this one, that captures exactly one thing or everything it captures is by move. We could convert it to this syntax, that's probably relatively low impact. um What I'm wondering about are cases where some things are by move and some things are not like. You could make an example.

A

Easily enough here, yeah like this would be a mix, and now we would need some syntax. That's like you know,.

C

Well, I was thinking more around just the things that are um like.

B

If you just do a move f.

C

Then it just like moves up and everything else just automatically follows through, like whatever it would have done earlier.

A

So yeah we'll have to see we. This is all yeah. If I, I think I think, the syntax, how I imagine my head is like this. If you do this, it moves all the local variables.

A

If you do, if you name something you can't capture anything outside of that list and they're moved. If you write dot, then you can capture things and we infer the kind of move. Okay, that's I I don't know if I actually like that, it's just what's I I can't imagine people are gonna push.

A

Let me the one bit in my head is that I sometimes wish I could more easily declare the things. I expect the closure to use every once in a while, and I might want to capture that use case, but.

C

Yeah all right, damn.

A

It.

C

That makes sense. Okay, I think we are about time. I need to head off soon, but yeah. uh This makes sense. um I guess first fridays will still be to get the uh migrations, sorry, uh mutation and all the fixes and sort of small open peers. We have uh well the peers that we are working for diagnostics and stuff, and then we start migrations. uh I don't know if you'll actually get the migrations before next week. Are you available next week.

A

Next week, I'm around.

C

Okay, I'll I'll I'll try to kick some things off then and uh yeah discuss any quick follow-ups. We have all right. Thank.

B

You.
youtube image
From YouTube: 2020-12-10 RFC 2229 Sync

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).