Add a meeting Rate this page

A

Okay, welcome uh please sign in and who would like? Can one of you take notes today.

A

Or should I pick.

B

I'll take notes we'll find out how bad.

A

It goes all right: okay, um upcoming, scheduled meetings. Tomorrow we have the rfc backlog. Bonanza recap um the document for this I'll post it in the issue, but it's the paper doc from before the plan was to go over and check how well we did or did not do at um following through on that, so I'll, just post it right now, paper document, okay, um and after that, these two I will.

A

This proposal is kind of close, so I'll, probably post that soon um I don't know felix. If you've, I know you were doing some work towards working on the atomic bomb.

B

Yeah yeah, I have something, but I realize there's more stuff. I need to probably get into depth about, or I might want to ralph to be honest, um but I should have something in time sounds good.

A

um Action items I at least got. I don't know what happened last week, something I didn't check a lot of my boxes. I don't know about the rest. Y'all um looks like we need to follow up on khan's 2b uh and do a few other things, but if you're on that list, do it um so let's go move forward. We have this pending proposal allowing the compiler to eagerly drop values.

A

uh I don't we had some discussion about it last time. um I think there was a request to move some of that content into the proposal. I can't remember where we landed on this. Has anyone been keeping up with it?

A

The discussion.

A

Okay,.

A

It feels like there's a lot of design work here. I guess the question is.

A

My feeling is, this is probably useful and important, but I don't know who's going to don't know what the best way is for it to make progress, especially if nobody in this meeting is kind of eager to help lead it along.

A

So it might be that it gets postponed for that reason, and we come back to it.

A

I would like to at least see like a design notes right up or something so we have some context.

C

To.

A

Pick it up again.

C

Yeah postponing it seems like a reasonable step and yes, asking one of the people proposing it to uh um summarize, the discussion so far might be potentially viable.

C

I think there's a few different approaches that were discussed here, ranging from what would it take to change the default to what would it take to opt into this, and I don't I would agree. No, there aren't enough people wildly excited about trying to push forward with such a change right now,.

A

I guess what I'm looking for, I'm wondering also about is: are there what are they like? The steps? Are there baby steps along the way I mean the opt-in is an example. It doesn't seem quite so baby, but it's certainly smaller than changing a default.

A

um You know giving the ability to tag a tag, a drop in bowl, let's say as potentially eager and the compiler can opt to move it forward. um Are there other kinds of steps I mean a lint is the obvious one linting against potentially surprising temporary lifetimes, and things like that.

A

One could imagine a lint that says you should explicitly drop guards of this kind under some circumstances, which would then encourage people to move it up themselves.

A

I don't know, I think we should encourage people. I guess I think we should encourage people to write up the thoughts and to look for kind of small steps. We could take to start exploring.

A

Without needing to like, I definitely think changing the defaults is out of scope right.

A

Now but yeah, but I'd like to be in a place where we have data that we could use to argue in favor or against changing the defaults. That's my my point. I.

A

Guess um so, there's an action item to follow up. Is anyone involved in this conversation who wants to take that on.

A

Okay, I will, since I said, a lot of things.

A

um Okay, constaby rfc.

A

um Has there been any follow-up here? I did not do my homework. I know other boxes were unchecked of people to do our homework of leaving comments.

B

So ralph responded to some of the feedback. um Mostly in terms of uh you know, I tried to reiterate like be good to answer the questions that mark posed and ralph um basically confirmed my hypothesized summary of what the actual effect of this is.

C

Ralph also updated the rfc to make it abundantly clear what some of those things were that uh I don't I understand where he's coming from that it felt like it was saying those things already, but I think he's updated it to the point that it restates it in enough places it's hard to miss.

C

So I think that the request of making the rfc self-contained, rather than relying on some discussions from the thread, is now done.

A

Okay,.

D

Dude I I I haven't. I see that there are still comp like new comments as of like a day ago and today and hours ago, um so I'm not caught up now really.

B

Wait, let me reload.

D

uh I I see ralph left the comment an hour ago. um I.

B

See three days ago, that's weird.

D

There's another response further up in the thread to you. Oh.

B

Oh github.

D

Yeah um yeah, the threading, the threading, okay,.

B

I can summarize that, though I can definitely tell.

D

You what this.

B

Was this this is just me I was. I was complaining saying, like you're, making statements about like the obvious okay, so there's some in case just everyone on the same page. The the basic summary here is, I understand that ralph has confirmed. Is that what this rf rfc is really saying? Is that all detect all undetected, undefined behavior versus during compile time function?

B

Evaluation will be quote unquote, non-consequential and what that's supposed to mean is basically that there's going to be an obvious semantics to what those constructs actually evaluate to, and we will follow that obvious semantics and my complaint, then, was to say I don't think the semantics is necessarily obvious, and I gave the concrete example of unaligned um addresses and gave two different interpretations of what uh that could mean to evaluate that, and so ralph has now said what the interpretation would be in such a specification.

B

um So if that's the point like just that yeah there will be some obvious interpretation and we will say what it is it'll be part of the language.

B

Okay, I guess.

D

This is actually that's actually interesting, because that's a stronger statement than I thought the rfc was making before what it sounds like from. What you're saying is that we get we're, guaranteeing that there won't be any undefined behavior uh of compile time in code.

B

Really, if it is it'll, be signal, I think, is what rob is claiming.

D

Right, which is not right, so I'm considering that not not undefined because we're defining it like undefined behavior in the sense of like like we, you know we might blow up your code right. Who knows, what's going to happen like we're saying we will provide a guaranteed behavior in response to all codes.

B

Yes, but but at the same time it's not stable. I think it's the other point that there's no stability guarantees being made it'll, be undefined behavior, but also be completely unstable. I think.

A

I thought that the rfc was saying it is undefined in some sense of the term undefined, but we have chosen the set of behavior to be the set. That has obvious semantics, which is a little bit inconsistent like it's.

E

Like.

A

The message here is very subtle. I think this is the fundamental like dispute. As far as I can tell right,.

F

Is.

A

That that taylor, your point is kind of this- is uh there's sort of mixed messaging around. How undefined is it and what exactly are we guaranteeing and not guaranteeing, and um if we have it, it's not a simple story that you can easily explain.

D

Right I feel like this is.

D

This is extraordinarily subtle to the point that, like I still don't, I'm still not sure like what exactly like like who is allowed to rely on what behavior, where or or if it seems like that we're trying to like make guarantees without anybody relying on them, and we want to say that things have enough like an obvious semantics, but not describe what that semantics is, um except where we throw an error and the places we throw in error is undefined, but except for some places where we throw an error that are guaranteed.

D

I I don't know I I feel like I'm coming off really negatively on this, which maybe is like I don't know, maybe is how I'm feeling. But I I like really respect that. There are a lot of people who put a lot of thought into this and know much more about this space than I do. uh But, but it seems like a really non-obvious thing to like the advantages of providing. This guarantee to users seem really non-obvious to me.

A

Okay, I think we're left with the same action items unless we want to talk about it more here.

A

I guess I not. I would like to drill a little, but on the thread not live unless ralph we're here or something into what what advantage this rfc offers over sort of the tool. I know what the advantage is over, guaranteeing that we detect all ub, which seems to be compile time from what I can tell or that plus the ability to do optimizations.

A

I don't fully understand the advantage of not giving any guarantees at all. It seems like it's kind of a messaging. It's the main thing that's been said. Like c bus plus gives some guarantees, so we should too.

A

Is that correct? Is that the only does anyone have any other reasons.

D

That was the primary thing that was brought up to me on the threat that it seemed like. Initially, the plan when we discussed this before in the lane team meeting right when they brought it in front of us, like speaking with ollie and ralph, was, was that we were not going to guarantee anything.

D

And then it sounded like from ollie's comment further up in the thread in response to me that that plan sort of changed in their minds in response to finding out that c, plus plus did a different thing and that we should be sort of at least as safe as c plus.

A

Which you know I understand: okay,.

A

All right, let's take it to the thread, then, unless there's more to say.

A

I guess my final comment is: does everyone agree that, like fundamentally we're not arguing about what the code will do we seem to be arguing about how we're going to sell it like describe it publicly, not sell it in the picture.

F

I think that's not true in the sense that I think that there is, at least in my mind, two possible implementations, depending on what we define of like.

F

We can make the code simple and only detect ub when sort of the the evaluation detects it, but we could also do sort of a more invasive right like what we discussed. I think last meeting um in terms of whether we are permitted to do any optimizations on uh mirror before running constable and and whether we can even run constable sort of on unoptimized versus optimized mirror, because they could have. You know different semantics.

A

I mean but no one's arguing in favor of that variant. Right now,.

D

I think I'd like to argue in favor of eventually running consti val on nrvode mir.

F

Like I guess, I'm not sure what variant you mean niko, but I think that there has been arguments in favor of both made.

A

I think well, there's the three variants I enabled I described the like. Nothing is guaranteed. We guarantee we'll detect it all the time and this version, which says we guarantee we detect certain kinds, but not others. At least that's how I understand it.

F

Right but certain kinds like to me that implies that we can't do at least some optimizations.

F

That's true and.

A

So, in some sense.

F

It's splitting mirror like there's multiple stages of mirror, and some are you know useful for some things and some are useful for other things and.

A

I don't know if we had optimizations that masked those. That would be true. Yes sure I don't know if we do.

A

uh I'm just looking.

D

Okay, I.

A

Mean like.

D

The obvious semantics for like accessing like a local variable after it's been, you know, moved from or something like that, like a pointer to it or like it doesn't have an obvious semantics right, and so that's a case where, like you, could make up one. But it's probably not going to be the thing that matches what you get if you're doing an nrvo past right.

A

Okay,.

F

Yeah but- but I think I think discussing on thread personally is is the thing that I would expect is the right next step here. I I just haven't gotten around to I.

A

Think so too, it's just yeah! So all right! Let's, let's do that.

B

All right.

F

Before.

B

Before we agree to that, I I still feel like like ralph is pretty, it seems like ralph is at least annoyed by the process. This point, or has been for a little while and doesn't know how to further approve the dock. To like respond to what we've said, are we expecting to have from the discussion on thread something some sort of concrete feedback for ralph to move this forward or, what's going to happen.

A

I I'm expecting that reading the document again looking over the thread will, at least for myself, help me to take a position between those three alternatives and argue with ralph. If it's not the one that ralph landed on, but.

F

And I think at this point, my feeling at least is that one thing that might be helpful is to tell ralph that I think it is true that there is not at least explicit alignment within the link team um in the sense that, like the comments being given, are not necessarily in the sense of saying no here in the sense of trying to you, know, continue discussion.

C

Right.

C

Yeah, I I think, on balance, it is safe to say, nobody's, saying we absolutely shouldn't do this, we're just trying to get a very clear picture of exactly what this is and uh it seems like we're not necessarily disagreeing on principle. Nobody's j, for example, uh taylor's comment about uh wanting to make sure that we're not promising these under all circumstances as a guarantee, nobody jumped up and said no, we should absolutely promise these under all circumstances. The question was whether the rfc was claiming that we were.

A

Yeah, although I kind of think we should but I haven't, I haven't fully decided: okay.

C

Nobody previously jumped up to say that we should.

A

I sort of like going on one side or the other. I see taylor's point so I haven't.

F

A message of we detect.

A

You be, or we don't make sense to me, yeah.

D

I would be fine with like being in the minority here and saying, like there are a bunch of smart people involved in this discussion. Who disagree with me and, like I like, I will, like you know, trust them um to have made to look like thought about this carefully, but I I actually think I'm at the point now where I don't think that additional clarifications on the rfc are what I need. I think I actually just disagree with what this rfc is doing.

D

I think that I actually like would prefer a world in which some things that you did in const eval that were undefined behavior. We we didn't guarantee a behavior for even if that means that we in practice we detect them and and don't provide you know mere optimizations on ctfe I would prefer a world in which, like we, we left ourselves the option of doing those things.

C

So I think that is what the rfc is proposing taylor. As far as.

D

I can tell the arts it isn't. I don't, I think, that's wrong, like.

A

I agree with with.

C

Interesting, it seemed to me, like the rfc was stating that we try to detect these things, but we don't guarantee that we will detect these things, and that seems and what.

B

Happens when we don't detect them, though, and what happens when we don't detect them? Because that's the crucial detail, I think that differs between what creates.

A

Taylor, swift states explicitly no there's. It also does identify certain classes of things that we do detect, guaranteed and cause compilation to stop within error. So it's it does both.

C

What do you mean by guaranteed, though it.

A

Says the following kinds of ub are detected by ctfe and will cause compilation to stop with an error, dereferencing dangling pointers using an invalid value and an arithmetic logic or control flow operation. So that sounds like a guarantee to me. If that's not a guarantee, then I don't know.

D

And, interestingly, it's a guarantee about what the rust compiler will do and not a guarantee that users are allowed to rely on in rust code, which is, I don't think the thing that we have a precedent for before, like I think.

A

I don't know that situation certainly arises to some extent but in weird ways, but.

A

Okay, we have to move on, I mean I don't know, are we well? I guess there is some legit disagreement denim or at least josh. You don't agree with taylor's summary of what the rfc says, which is interesting.

C

I think that's worth a further conversation offline, yes, yeah taylor. Do you want to follow up after this meeting and we can try to talk through some of that.

D

All right sure, I'm actually gonna have to drop off this meeting midway, but I'm happy to follow up on the zoo afterwards I'll stay in there.

C

Okay, see you this afternoon: okay,.

A

Change visibility, scoping rules for macro removals macros, um I kind of think we should just close this rfc at present. It's mostly talking about. I think we decided not to do it for this edition and whatever is going to happen, it's going to require some changes right.

E

Yes,.

C

We said that the last time.

A

Great okay: let's move on declaring macro metavariable expressions.

E

That one already passed fcp did it did.

A

Cool.

A

Okay, we had talked about giving lane team a heads up, as I recall, the liberty, the libs team. Sorry.

C

Okay, yes, I just did that today.

A

All right, so this is in fcp great, then, let's move on with that wrapper c is unsound.

A

Any updates.

A

Here.

C

No movement since the previous summary of people are trying to figure out if it's possible to modify rep c without breaking existing code. Yeah.

A

There aren't even any comments. Is it worth us inserting a like? Do we need to provide any guidance, or do we feel the thread is answering the questions we want answered.

B

And doesn't need an owner from our team, probably not.

A

The current status I.

C

Don't think it needs an owner from our team, it couldn't hurt for us to summarize that we're expecting this is the current blocker and we would like someone to uh determine that definitively one way or another.

A

That sounds useful to summarize our understanding and make sure that people on thread agree with it. So can someone josh? Can you write.

D

It in the notes actually.

A

But can we say it out loud to make sure we're on the same page, like our understanding is I'll? Tell you what I think it is we wanted to have. We, as the link team, wanted to have rep or c match the c compiler, but there is investigation as to whether that's possible or would break too much existing code because of binden behavior.

A

Is that right.

C

uh Correct.

C

Not just bind-gen potentially other code, but bind-gen is a good case study in seeming to use and rely on that behavior. So.

A

It seems like what we're asking for is probably not a judgment of like not the answer to that question, but the data we would need to answer that question right.

C

It's also worth noting bind gin itself is not necessarily a show stopper. As long as there is a way to get the appropriate behavior that bind jen is expecting. We have had cases in the past where there was a missing feature in the language. Bind-Gen worked around it and then the feature became available and there was a migration required for when do people want to use that, so there may potentially be a churn in bind gen as long as we don't actively break existing.

A

Code, um okay, I see so you're saying we can change what codebind generates as long as the code that we know it has already been generated is like mostly still going to work. Is that what you're saying uh right?

A

Okay, all right, good, then action item for josh to write that comment, so next issue function, arrow out is valid for unsized types.

A

Seems ungreat.

A

So here's the code.

A

Example,.

A

Or a code example.

B

Yeah I posted yeah. I guess you can write your code example. First I mean, I think the person posting this or someone give feedback said they're. Basically, in short, that we should, you know, disallow types, uh first class function, types with an unsized return value in general, um though I guess there might be some cases where that can work. I don't know if there's cases that actually can work and like I don't know, if there's we, since they can't compile it today anyway, there's no harm in just allowing it right.

A

I think that's right. We intentionally I'm trying to remember we intentionally permitted unsized types.

A

For the.

A

Arguments this is sort of an interesting the fact that output is sized.

A

Okay, sorry, so we intentionally left space for the argument, types to be unsized, because we wanted to enable a future extension wherein they were allowed to be unsized so that you could pass data down without boxing it.

A

The return type there have been proposals for what an unsized type might mean there, but not none that have gotten that seem to me to sort of they're all kind of complicated. I don't think we've found the the right combination, yet uh the fact that output has a size, bound kind of boxes, our kind of blocks, our ability to do. That, though, now that we think about it, um because there's no doubt existing code, that assumes that the output is sized. ah That may not be true. There may not be stable code.

A

That makes that assumption, because you can't write function, bounds in stable code.

A

Without um using the shorthand notation- and that requires you to specify an explicit return type so plausibly- we could remove the bound from output. That would be another possible fix.

A

I not 100 sure, but I think that would be. That would not affect any stable code.

F

Wouldn't it stop compiling, if I, I guess no, that would be overrestricting yeah. um I think you could maybe rely on it today, but it feels difficult to come up with an example.

A

It wouldn't surprise me if there's some way, but I'm not sure what that way is because, specifically because to write the bound.

A

You have to do uh something like this right, and that means that r sort of r will have a size bound.

A

We could test it.

E

If we just add, question mark size to output in f and once and stuff, then you get a whole lot of errors. If you run x by check.

A

Yeah, it might be that unstable code breaks, but I'm not sure whether stable code breaks. I.

A

Oh, the traits themselves, don't even compile oh yeah. Okay, I can see why.

E

I mean I just added another one exit by check and it gave a lot of errors.

A

Yeah, it would be a little work to remove that all right.

A

It seems okay to require function, types to be sized.

A

I think we can plausibly.

A

All right, I don't know I'm trying to think how we should follow.

B

Up how originally on this and who should own it, so I was assuming that the obvious best was to have the restriction, but you're saying you prefer to explore removing it.

B

I'm.

A

Using about it all right, I don't know which I think is better. I I'm not sure how much work I want to do to remove to remove it.

A

The reason I I'm told about it is that I feel like that might be a future direction. We wanted to go, and I don't know what we, if we don't get a lot from requiring the things are sized. Maybe I'd rather have less requirements, but we get at least something probably the default. I'm assuming the traits have some code in them. That's assuming that output is.

A

Sized.

A

I think we should take it offline, but it needs to be assigned to someone. I don't know if I have time to follow up on it or I mean how high priority do we think it is it's p high for decompiler, not p critical, it doesn't seem especially worse than other unsound bugs do we know if there's even stable code that can be affected by this.

B

That's the uh that's one of the questions. People were like searching for ways that it could break stable, but I don't think I mean there's claims there there's a comment in the middle, where someone says you can observe the unsoundness and then there's like feedback like wait. This isn't actually observing them soundness. It's just a case you might expect to compile but shouldn't, but it's not it sort of depends on what you define as observe the unsoundness.

B

I guess the point um like it might not match expectations about what's being allowed to compile, but it's not like, as far as we know, causing uv.

A

Yeah, I see.

B

um I take it that if we tried to add the restriction, your your point is going down. That path would basically make it even harder for us to remove this restriction in the future.

A

That's my theory, but I'm not sure that's true.

A

I guess not without implied bounds or something I think it's probably. The right path is to require that return types are sized and if we're going to change it, we're going to have to deal.

B

But.

B

Well, I would be willing to own just adding the uh restriction or making sure that it happens, or rather esteban is volunteered to add the restrictions for that matter. So I think we have all right. Let's do that.

A

Pr and see what happens, I guess.

B

Okay,.

B

Okay, you can own up the post news owner I'll just decide myself.

A

Okay,.

B

And I'll post a comment.

A

All right next, one define field element, reference number 933. This is a reference issue that was nominated for us. um The question is: how do we want to handle terminal? There's a specific comment from javi.

A

How do we want to handle terminology for accessing the values in tuples, tuple, structs and arrays.

A

The reference currently says, field and element field for alphabetical names, an element for numerical names or array, values.

A

I don't know this is a pretty uh detailed.

A

Terminology question: I'm gonna copy and paste the options rather than just reading them out loud.

G

I don't know.

C

This is absolutely the ultimate bike, shed kind of thing, we're literally being asked what color would you like? The bike should be to be painted. I.

B

Mean I.

C

Think there's.

B

Strong precedent against, I don't know what languages would refer to array elements as fields, so I think we can work like incrementally, just like ruling out cases. Yes,.

C

Yeah, I was, I was gonna agree with that as well. I don't think that case three or for that matter case four is appropriate. uh We want to use field for struts and we want to use element for arrays. I think the only question is: what is the name of the thing in a tuple? Is it an element or a field.

C

Do we think of a tuple as a struct, with unnamed fields or as an array of a fixed size and.

G

We have an rfc games, both.

C

Depending on what you're doing.

G

We have an rfc. Actually that says that double structs are strucks with field named by integers, so precedent.

C

Helpful, what's which rfc.

G

um

G

15 something I don't know why my brain remembers that 1506.

A

I'm gonna say.

C

Option.

A

Two yeah.

C

Yeah, I I think that, citing that as precedent and saying, here's why we're calling them fields seems uh completely reasonable uh scott. Do you want to summarize that and point to the rfc that you just uh impressively remembered.

B

Sure.

A

Yeah there's lots of places where we treat tuples like their structs, so that seems like reason enough: okay, great. Let's move on uh next issue; rename value, expressions and place expression section to evaluation categories.

A

uh This is about I don't. This is about the section of describing kinds of expressions I feel like we've had this discussion so many times. um I don't really like evaluation categories to me, because it's maybe I do it doesn't sound.

A

I guess because it evaluates.

F

To a place in.

A

Memory is the reason, but I feel like it's more like a syntactic restriction and that sounds very semantics. But.

C

So, as far as I can tell the proposal isn't to rename either a value, expression or place expression. It's what do we call the category of those things? What uh whether something is an l value or an r value effectively.

A

I see I see I feel like, wouldn't we call it categories of expressions.

A

But.

C

Yeah, I think evaluation is the term the unusual term. Here, I think expression- is appropriate because they're both types of expressions.

A

Yeah, I don't know I have to look at precedent too, but.

B

All right, why don't we leave comments? Suggestion then wait? Is it like expression categories, though I just heard.

A

That's my suggestion, but I'll just post it as a comment on the issue.

C

Yeah since they're, both x expression and y expression, then having it be expression, categories seems pretty.

C

Reasonable.

A

Okay, consider deprecating weird nesting of items. Oh we've been over this a few times. We decided not to do this in the current edition. I think probably this can be on like we decided at some point. If we're going to do it, we should just oh pink felix even proposed to close it and we all fcp did it uh so really. We can just uh nominate this. I think scott did leave a comment. What's the right way to go forward with 2024 scott, I think the answer is implement a deprecation write.

G

A project proposal.

A

Yeah and implement a deprecation as a lint now and then we can up the severity of that down. The line essentially like there's still value whether or not yeah.

G

It's a someone needs to write a concrete proposal of what we'd actually be trying to defecate and then yeah, because we have a bunch of vague ideas about it, but I don't think there's a concrete description of it. So that would be needed and then a limp for it. And then we can talk about the things so yeah.

A

Okay, I can write a comment saying closing the issue and saying: if anyone wants to pursue this, the way forward is to propose a concrete lint uh as a either as a pr or project proposal.

A

That's an action item. Okay, const, precise live, drops tracking issue.

A

73255 this was nominated by ali three days ago for stabilization.

A

I'm trying to remember this, I remember when it was implemented.

A

Check it seems like this was the pr number 71824 uh check for live, drops and constants after drop elaboration.

A

The idea was to get more precise so that if you had code that doesn't need to be dropped because it's been moved or something else, you won't give errors.

F

Did we ever get clarity on whether this does the like weird exposing like internal semantics stuff or is it matching borrow check now? I remember some comments about it.

A

I'm rereading.

A

I think our conclusion was.

A

We don't think it is today.

A

But uh the my opinion is that the way it's implemented could allow that to happen, but that would be a breaking change right.

A

Well, it might accept more code than we want to, for example,.

F

You mean the current implementation.

A

Right basically, what's happening is it's being as long as it happens immediately after drop elaboration.

A

It's probably fine, I think my concern was that the movie might do some optimizations in between or something else that would like, remove some dead code or make it accept things that you wouldn't have accepted. Otherwise,.

F

Yeah, I guess it feels to me like we should match drop check, but I admit that I don't care.

F

Much weird to have separate rules.

A

Well, sort of the borrow check has its own rules, but yeah.

F

Yeah, I don't know, I don't feel strongly.

A

I'll take a look and make an opinion.

A

All right, stabilize or patterns.

G

This, I think, got the concern resolved, so it's got three open check boxes.

A

Oh well, then, I'm gonna put my comment right now.

A

One thing that uh we were discussing is what kind of in the 2021 edition discussions, what kind of migration we want here and if any and there's not that much breakage so like on zulip josh, for example, we were saying: maybe we don't need any, but we were thinking we aren't ready to give up yet on giving at least giving users some warnings.

A

It's pretty easy migration to warn about in theory, so I'm going to try to take a stab at writing up some mentoring instructions and finding someone to issue a lint that basically says your use of the basically suggest changing pat to pat 20.

A

Oh, you know what there was one other thing uh minor thing, but I suggest changing pat to pat 2015 um 18 20 yeah, that's the minor thing. It should probably be 2015, because that's when the behavior started.

E

At least.

A

For the.

E

Pendings, I called them 2015 and 2021, and I saw here we call this 18 and 21, so you should change one to two.

C

That's fair.

A

Want to throw a concern for that.

A

Can we rename to pat 2015 instead of pet 2018, because the president, from elsewhere,.

C

um um For what it's worth, though, as far as I can tell, this is not currently proposing to stabilize either of those names, 2018 or 2021,.

F

Which means.

C

That doesn't actually need to be a blocker on stabilizing or patterns themselves. It's just a blocker on stabilizing the new pat matchers and therefore on stabilizing any kind of transition.

E

Yeah, but I think it would be weird to stabilize the new or patterns if that means that there is no way to write code that behaves the same in both editions in both the current and the next edition right. I think.

A

We should go ahead and well if we go ahead and land the new matchers. Now it seems okay.

C

I'm not arguing with that. I was just observing that we specifically asked for those to not be included, and so.

A

Yeah, let's just do it in a separate pr just to not be annoying but back then I was more dubious now, I'm now I think we're ready to go so.

E

I just think it would be really bad state if we do change the behavior of just that in the edition and not have.

A

I don't think we've changed the behavior of pat, yet in this pr.

E

uh

A

I feel like we should change the behavior and introduce the matchers in the same period.

E

Okay, it's already changed in the new edition that what happened the first of january.

A

Oh okay, well whatever and never mind, then all right. Take it. Give me an action name to talk to mark about this and figure it out.

A

Since that's my liaison issue, okay include adjustments to allow unsizing coercions for raw slice pointers in receiver position.

A

I have no memory of this. I may have volunteered to figure something out and I think I didn't get to it sort of remember taking an action item for that.

A

Oh right, this is the raw slice pointers.

G

Thing.

A

Let me review this and come back to the meeting after that.

A

I want to review it anyway.

A

Okay,.

A

We make unaligned references future incompatible, worn by default.

A

Okay, so the context is we were making accessing taking the address of packed fields unsafe, but we now have a safe way to do it using adder of and the proposal is to start warning as a future compatibility warning that will eventually become in principle, an error across all of rust to access fields. In that way, although it seems like the kind of thing that may go to this to a hybrid state,.

A

Does this mean we're going to make it safe just warn, I think it does.

B

Apparently so, and which is I I mean if somebody else complained about that, and I find it really strange.

B

Yeah, it seems strange, I mean I can understand the sort of long-term logic of being like well, if you're going to forbid it, why bother even having required unsafe block, but that's but we're not in that state of forbidding. It.

F

Yet I guess I'm confused before we we required an unsafe block, but that really had no effect. It just silenced. The error.

F

Which.

B

Is like always.

F

Sure about unsafe, but um I don't know.

B

I don't know.

F

If the effect was.

B

The person was making a proof obligation that what they were doing actually made sense, even though it right like as an ensure your structures, could be aligned to satisfy the guarantee that you need to be meeting. Yes.

F

I think right, but I think ralph is making the argument that in practice, the unsafe block is not necessary. If you do it correctly right, you want to always go through a raw pointer, and then you will need an unsafe block um when you reference that, but the creation of the raw pointer, which is the correct action. It never requires an unsafe block and we don't actually want to support. Taking a reference directly. Even inside unsafe blocks is the claim being made.

B

Sure I I think I buy all of that, I'm just saying if if there was any way in which this could have made sense before and the only issue is you had a proof obligation, then it seems to me like you should continue allow. You should continue forcing the proof obligation, even with a warning.

A

The major reason to not do that is just less code. I guess.

A

That's like.

B

Basically,.

A

Less code in the unsafe code, checker like I'm, trying to figure out what is the reason.

A

So here's how I here's my summary of of what felix is saying felix tell me if I'm correct, we want this to be a hard error and we're all on board with that, but in the meantime, why not also make it unsafe.

A

So it's unsafe code that you will not be allowed to write in the future instead of safe code, you will not be allowed to write in the future.

B

Is that correct?

B

Essentially, I mean I still regard as a simplification that, if this ever, if this ever made sense in the past, if you actually could have a proof obligation that would make the code make sense, then- and we just are saying- there's a better way to do it going forward in terms of the point or adder of then I I think the form that is the old form should still require unsafe. I just I don't see the benefit to anyone. Everything unsafe. I can understand you're saying about it.

B

If it's simplifying the implementation of the unsafe checker. That's a that's an argument. I just think it's a pretty weak one.

F

Yeah, I I I think that it makes you know not a lot of sense personally to tell people to use unsafe, because I think it actually in some sense hurts our message in the sense that if they can move to utter of.

F

Yeah, I I don't know I I don't feel strongly. I guess, but I feel like the argument is being made, and I think correctly that people currently using the unsafe may think that that is sufficient to get what they want, because that is usually in some sense. True about unsafe, like they think the proof obligation is is just you know, actually exist.

B

But that is not I mean I don't know how to fix our messaging to fix that interpretation of an unsafe keyword, but well.

C

I'm trying to understand the current proposal.

C

If I'm reading this proposal correctly, it's saying that right now we're proposing to warn if you do this in safe code, and we don't currently have such a warning, if you do it in unsafe code and the new proposed behavior is to just always warn because this is never a good idea in either safe or unsafe code. So it's not that we're making it not depend on unsafe. It's just that. We are saying we need to complain at you either way to not do this.

C

That doesn't seem unreasonable, or am I misunderstanding. This that's.

F

My understanding of the proposal as well.

A

That's definitely what it's saying.

G

This, so I think the thing this this feels to me is that, if this does, if this removes the need for unsafe in code, that can do this, it ought to at least you know, put it in the un forbid, unsafe code or something.

F

Right, maybe I'm not following you: it doesn't because.

G

It can be unsound and safe code if.

F

You mean taking a raw pointer to it.

G

No, a normal reference.

F

A normal reference we.

A

Don't always put future compatibility warnings in unsafe code group like there's lots of ways to make unsound yeah or there are bugs that we have fixed that we don't right.

B

Yeah all right, all right, I I'm willing to after this discussion I now realize I misinterpret the current state of things. I didn't realize that we actually were requiring an unsafe code block in every usage. Before I see now, it's that we were warning and saying you should have an unsafe code block, but without that I.

C

Only got a warning.

B

All right, I would.

C

Draw.

G

Yeah, just a little confused by the mixing of the two parts.

C

Yeah.

G

We were always.

B

Issuing a little confusing.

C

But.

B

Right if the link that was sounds betting on safe before and now it sounds a different way. Okay,.

C

I see okay.

B

Yeah right right about that at least.

C

That's my interpretation: yeah yeah, we're not making unsafe unnecessary, we're just no longer making it suppress a warning.

A

This matter of actually stable.

F

It's stable on nightly and beta and we'll hit uh stable in like 10 days or something.

A

Okay, let's do it I'm in favor, um but okay. So to summarize we this conclusion was: we believe the concurrent state is. There is a lint against this, which is silenced by using unsafe. I have a heart out everyone. I have to go. Okay, oh yeah. That's all right! I'll finish! This up.

A

uh There's a length of science by using unsafe. This pr um makes this a future compatibility warning lint um and recommends the use of adder of maybe it does maybe it doesn't. I should check that.

A

um And we are in favor.

A

uh Roughly that right.

F

Yeah, I think, that's the conclusion all.

A

Right, I will leave it. Give me an action item. I'm going to make myself a reviewer for.

F

Spr.

A

I care about the I'm, not convinced that we have the great suggestions, so I want to take a look: okay, um cool.

A

We did pretty good next time. I might reorder some of these newer things. First, all right. Thanks.

A

Everyone.
youtube image
From YouTube: 2021-03-16 Lang team triage

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