Add a meeting Rate this page

A

Go for it.

A

All right, then, uh let's start going down the agenda. We've got uh a meeting scheduled tomorrow to do the monthly updates for the various project groups we've made pings and several of them have gotten back to us.

A

Then please take a look at any action items that aren't done or just aren't marked as done, and then let's go on to the pending proposals, uh I'm assuming nico, since you have an update right there that you want to say something about this uh eager drop values.

B

uh No, I want to say that I still haven't done this yet, but I expect to do it in a week or two as I've been saying for a while, but it will be true, fair.

A

Enough all right, and then we have a few rfcs open, yeah.

B

So uh I one of my action items was to which I also didn't expect to get to this week anyway, was to improve the script, but for now I figured we can just manually page over here, fair enough.

A

We uh uh you've got listed there that there aren't any nominated uh rfcs uh and then are there any of these. That people want to talk about, or do people just want to check boxes, asynchronously.

C

As a procedural note, I do know that there are a couple that are blocked on boats. uh In some sense, I don't know if we should sort of do something about that.

B

Yeah, usually we just check those.

D

Well, so actually so one of them actually has an outstanding concern and.

A

From boats or did boats register a concern on someone else's behalf.

D

uh The former.

A

Okay, in a few cases, I've seen the latter. That's why I was asking.

B

Sounds like we should read it and make a judgment, and you can always cancel the fcp and restart it. um Maybe we should can someone take an action item to like go through and nominate things on here that seem like they need to be discussed.

D

Right, so generic methods on generic parameters of constants is definitely one.

A

uh Does that one have a concern or just an unchecked box.

D

I believe it has an unchecked box and a concern.

A

Okay,.

C

I I I'm happy to uh you know: do a quick pass over the rc's.

B

Nominator.

C

Or that.

B

Would be.

A

A great action.

C

Yeah.

A

Let's do that, uh is there a concern on 2845 super trade item shadowing as well or just unchecked boxes.

B

Like I might have registered a concern on that, I.

C

Seem to recall concerns.

B

Yeah yeah, okay, which I haven't done yet, but I yeah okay. I have some mild concern about this, but it's sort of like it's just changing it's making something significant that wasn't supposed to be significant before the set of bounds that you write and that will affect the implementation. I'm not sure that I think it's problematic from a user experience. Point of view, though, um like it makes a difference between an elaborated bound and anyway.

B

I should write it in a comment.

B

I'll put an action item for myself or mark. Can you make it actually for nico to write a comment? Sure.

A

I see.

B

2845. thanks.

A

Also uh 84988 is uh I marked that as nominated, but I'm not seeing it show, oh, no, it did show up in the list down under prs uh just was buried, so I may bubble that one up a little higher to make sure we get to it in this meeting.

B

All right should we move on now, though, if.

A

Mark's gonna go over.

B

We'll come back to it: okay,.

A

Yep all right, then there are no nominated rfcs, there's no nominated, there's, no p high issues or nominated reference issues. So let's go on to our list of uh nominated prs. We have the tracking.

E

Story, um it's not nominated, but the keyword, the the reservation, the lexical reservations. Rfc, do we have anything we need to talk about about what the details of what that's semantics are supposed to be. I saw there was a bunch of zulu conversations about.

A

It that may be worth bringing up. Yes, uh there was some discussion about consistency and, in particular, consistency with the current behavior of the r hash lexing.

A

The original proposal effectively said, put a space on either or both sides of the hash in order to avoid the reservation and that we were only reserving uh token hash, some other symbol with very specific uh syntax there, but uh our hash, even with a space after it is not currently allowed, and there was some discussion asynchronously on zulip about the idea that token space should still not lex on the theory that uh that would reserve anything starting with token hash.

A

And then we could decide how we wanted to lex that in the future. Alternatively, we could allow that and decide now that that lexus, the only advantage of allowing that to lex, would be if a macro found it onerous to insert a space on both sides or the left side.

A

But you know wanted to insert a space on the right side only in order to tokenize something, so that doesn't necessarily seem worthwhile. But what do other people think there's currently a proposal to tweak the reservation to just uh prohibit token hash in general.

B

This true dust: we have no known examples where anybody actually cares about this right.

A

Correct the one example we had where anybody cared about token, something with no space was the format string, macro proposal, and I don't know of any example where somebody cares about token space.

A

Something.

B

I think we might as well just be consistent. There was this other point as well after this is done, though, that's maybe worth just about the api. It was more of a lip question, but not exactly.

A

Okay, uh we can talk about that one then, but if anybody, if nobody has any objections about this item- or rather, if you have any objections, there's a zoolip thread going on on the uh edition channel to discuss this. So please go ahead and make it known there. If you have a concern, I always like the well.

E

We can make it work later if we want.

A

Exactly the only question is whether we would be breaking something that people care to have keep working in the next edition, and I don't think we are okay. So concretely, can someone take an action item to report this consensus to the appropriate zoolip thread and say that we discussed it today and nobody had any objections.

E

Sure I can take that thanks brought it up.

B

The other issue that.

A

Could help that.

B

Gun.

A

Block yeah.

B

Okay, there was the was it called two tokens uh here. It is this. Is it um so? I don't think there's necessarily much to do here, but I wanted to make folks aware of it. So there's this api from stir from tokenstream and the problem is this just takes a string uh and doesn't have any way to say what let me link to this. It doesn't have any way to uh indicate the addition from which this string or with which this string should be parsed.

B

um There is the the current behavior of the library. uh I think I think it will use the addition of the invocation site of the procedural macro, if I'm not mistaken, uh which is relevant for well, which is not that relevant until we make changes, I guess because it wasn't really relevant before, uh but that was.

D

I.

B

Can't remember.

D

It seems like that's the right behavior, but we should just deprecate the function.

B

I.

D

Think that's right.

B

It's the, I think, it's I think it's a decent choice, but the function is flood because there are it's not always the right choice. Right.

D

You.

B

Should have to make that.

D

Choice.

E

Right.

A

Yeah, ideally, we would pass into the procedural macro. Here is the addition on which at which you were invoked, and then it could choose to pass that edition through to a from stir function. But you could also choose to pick an arbitrary edition if it wants, but this.

D

Behavior seems.

A

Like a good default.

D

I would have expected it to take a span as an argument.

A

Yeah, that's.

B

What I would expect too,.

A

That works as well something better yeah.

C

It's a trade impulse, so you can't we can.

D

Create a new function.

C

But well it shouldn't.

D

What I'm saying is, I would expect that trade info to just not exist.

B

Yeah yeah sure um the problem, the one interesting sort of gotcha here is that many existing users of this function are procedural. Macros, that wind up being for some reason or another, invoked by a macro rules, macro defined in another crate, and I think that layer of indirection.

D

Of dear lord.

B

Kind of messes up the like the reason this is a decent choice. Is that you get.

B

You would imagine that the if, if you're taking tokens that the user gave to you you're getting the user's edition, that's kind of what you wanted, but if you do that in direction, you're actually getting the addition of the crate which introduced the indirection, which may or may not be the crate that supplied those tokens. So um luckily, this is like you know a pretty small like it only affects this, our hash stuff right. So it's probably a case where we're gonna have some weird addition: migration behavior, but it's pretty small.

C

Some other discussion on.

D

That issue, oh sorry, go ahead.

C

Raise that you know, potentially, the whole idea of addition, dependent lexing is is maybe not a great idea, um but I don't know whether you know we care.

B

Yeah I mean that is the question, um but I like why not. This is the main reason why not, because we didn't design the api with it in mind. I don't know, I didn't think there was another.

A

Argument, don't we already have edition specific lexing in so far as we have things that are key words in 2018 and not in.

D

2015.

D

That is an example of edition specific parsing. The addition specific lexing is a different thing, because it depends on um whether or not separate tokens or not.

A

So we don't determine uh whether something is an identifier or a keyword at lexing time.

B

Well, my oh go ahead. The thing is, the compiler internally does have some stuff, but the token stream api for procedural macros does not.

E

Okay, and even in uh even in macro rules, you can take something that you said is a colon ident and pass structure union and use it as a keyword to declare a struct and things so yeah. The whole idea of what's a key word lexically is a little funky.

E

It's true.

B

Yeah, we don't, I thought the same thing josh, but I think we don't. We kind of we did intentionally design the token stream parsing to sort of be very generic. uh On the other hand, like I don't know,.

C

Yeah for like for what it's.

B

Worth.

C

Petrochenko definitely says that you know the design of the luxor library and the fact that it's shared with rust, analyzer and so forth, like like the current design of the compiler, very intentionally sort of avoids, introducing any global data.

E

Including edition.

C

um And so you know we can say well, you know whatever that's just implementation. um Obviously it can be changed, but I do think it is sort of potentially worth considering, um especially because I think greater returned that maybe there's not too much right.

B

Right, the result might be that we want to just do this across all additions and not make it edition dependent.

D

The impact of which would be that k, hash things and r hash things now get parsed as a single token um and are given to macros as a single token, rather than a separate tokens or a single token, depending on addition.

B

It would make them.

D

Reverse I'm.

B

Sorry, you would actually make them errors today until we give them a defined at least the way we wrote it. uh Oh so they just don't.

D

Lex.

B

Yeah today, under the way the rfc was written to maximize forward compatibility well,.

D

That seems great, then we can just fix this. Then right.

A

Well, the.

E

Problem.

A

Is they lex today and there are a few macros out there, counting on that.

D

Oh, oh I'm sorry, I misunderstood you're saying that going forwards in in future editions they wouldn't lex correct, correct.

A

uh

D

Okay, sorry I had it. I had that backwards.

A

Yeah we did determine from a crater run that k hash will not break any existing code, and so we can make k hash for keyword usage, be reserved in all editions and always turn into a keyword which is ideal. It means we don't have to come up with some unusual, our hash dollar or something for old editions, but we did run into conflicts when we tried to do the uh general syntax reservation.

B

Yeah, I'm thinking about it. I mean the original reason to put additions in cargo. Tamil, for example, was precisely so that we could have lexing, dependent and parser-dependent stuff, where we didn't have to we sort of knew from the beginning. What the addition was.

A

In an ideal world uh like proc macro, it would be nice if you had to declare a version of that like actually write a dependency because, unlike stood, it wouldn't be the end of the world. If proc macro had a uh major rev to drop an api.

B

Well, I think.

D

I don't think that solves.

B

This, I feel like you would want for the part of this problem I feel like the ideal is to track, is to know what spanish came from and thus know what lexing rules to apply.

D

I feel like the real problem here is that people shouldn't be creating token streams from raw strings like we just shouldn't have an api.

D

It's mostly.

B

Fair, that was my point. Yeah.

D

I know we can't but like I would like to.

A

Well, we could at least deprecate that we can't remove it, but we can deprecate it.

B

Yeah, I'm.

C

Thinking of the way things are written, though, like I don't know, token streams from raw string seems like the sort of easy way to write. Proc macros in some sense.

D

No, it's token strings from raw token streams from raw strings and a span, and if you just want to specify span, you know call site or spam death site everywhere. That's fine!.

C

Okay, yeah: I guess that that's true.

D

But then you're you're opting into some behavior.

E

Yeah, I guess we could deprecate this and say: fromster is always edition 2018., but it wouldn't and nothing breaks right. I.

D

Guess that doesn't avoid the issue of that you still have edition dependent lexington. So if.

E

Your goal is not.

D

Having an independent listing at all that doesn't that doesn't actually help yeah.

B

I think that's the interesting question is: should we like the procedural macros are? Definitely it it's definitely a nice simplifying thing if the lexer is just behaves, how it behaves um and that's that.

C

um Yeah, it's also nice for stuff, like code uh highlighting and stuff in various places, and I think some of.

E

The.

C

Work that I've been doing on reduction also enjoys the fact that you can um sort of lex russ code independent of knowing anything about it.

B

Yeah, I can see that, although it seems it's I mean it's all solid, cornery.

E

Yeah, but it's nicer, if you don't have to yeah like outside of a macro invocation, it's still completely doable right, it's only in places where you're stuck not really knowing what's going on.

E

Well, I guess no construing literals and preparing matching.

D

Yeah, although I guess the set of ides that um one do something more than regex parsing for lexing and to um do do something that that couldn't relatively easily be addition dependent, I think, is small or non-existent, but maybe I maybe I'm wrong. I don't know.

E

So I have a silly question: what do we do for our hash for all this stuff? Is that kept as part of the token.

E

Or tell you what our hash async in these apis? Does it just give you a token that is still r hash, async.

C

I'm not sure about that specific case, but in terms of our hash handling and the compiler in general, we have quite a few places where we sort of guess, um depending on various factors, whether the thing is a raw uh identifier or it was actually written as async in a previous edition, and we just sort of genuinely guess we insert the our hash or not one party print, for example,.

B

I think there's um I I thought the token carried that information, but.

C

We don't always right, but we don't always have like right.

A

Well, uh I don't think we're going to solve this. The api version of the problem in this meeting. I think the only question is: does anybody feel like there's a a fatal flaw with doing edition dependent lexing that is worth hashing out right now, no pun intended or, uh if not, then we may want to take it async to discuss what the right api for that would look like, because, as far as I can tell, proc macro doesn't currently have that api.

D

Do do we think it's worth surveying like users of existing tools to see if, like in what ways they would be impacted by addition, dependent lexington.

A

Yeah users of or tool developers.

D

Sorry tool developers.

B

I think it makes sense to get some folks opinions.

D

Like I at least would want, like matt.

E

It's a comparatively small list, so it seems feasible right.

B

Yeah, it seems useful to gather a little data.

C

I I would be happy to write up a comment on the issue uh that sparked this discussion: uh eight, four, nine, seven, nine asking peter chenkov matt clatt- uh and I guess that's about all I can think of um sort of off the top of the head for sort of a discussion of why we don't want this state in the lecture beyond just sort of you know it's not there. Now. Maybe we don't want to introduce extra stuff.

E

Sure so would there be a? Is there a easy sort of thing that we could ask or talk about at a higher level of like? If we don't do edition dependent lexing? How could we ever introduce new tokens.

C

Find find lexical forms that currently don't lex.

E

Right, there's just not very many of those and they seem identifiers, starting with orders.

C

I guess maybe not enough.

E

That.

E

Well,.

E

Yeah, I I don't know like, rather than the specific do we really want this, for this particular thing is like if we ever wanted to do f strings or whatever. What would we just be saying? Well, no, we've decided we have to do these as syntax forever and they can never be lexical or.

B

I think um which I remember how I think that the procedural macros work by white space hacks right, um it's plausible.

B

To me, at least, to imagine a sort of parser library level that introduces new interpretations of older tokens, but.

C

Yeah.

B

I don't know, I think it is kind of hard to introduce new tokens if you don't do addition to finalizing right.

A

I would also, as a procedural note, I would observe we should ask uh tool developers to elaborate on the potential downsides of addition dependent lexing, but I would also observe uh the default there seems likely to be. This will make things more difficult and the question is more: it's a trade-off rather than a uh a full. You know if they're, not thinking we should do it, then we should consider that feedback. Rather than that, we should treat that as a veto.

D

I actually would definitely trust at least matt clad to give an honest response about like whether more difficult means like we have an extra. If statement in two places or like a match statement somewhere versus like this, you know destroys laziness or something in some critical way. Right, surely.

A

No, I completely agree. I think that we could get some good feedback in that regard. I think I'm just suggesting I would want to know what the trade-off is, and I think I agree that uh matt cloud is very likely to give us the trade-offs there.

B

It's also true that, like we discovered the k, hash foo has no real impact. uh There is we could explore the the alternatives are to. We could reserve all ident hash ident, for example, and across.

C

All addition.

B

Across all editions just break it, since it's not supposed to break anything, uh we haven't tested that you only tested k hash. I think, but we could test that.

A

No, we did actually test everything first and that's why we narrowed the crater to just k hash the initial crater run picked up on things like the macros that do f strings. We should go back and double check if there was anything that was caused by uh I did rather than I didn't quote, but yeah.

B

I see okay. Well, where can someone point find that link at some point and that's another action item? I guess.

A

I believe that maybe.

A

84037.

A

Okay, uh that doesn't that may have not been the correct.

A

Item.

B

uh

B

That doesn't seem right, but it's okay. Let's do it offline.

A

Yeah often uh so, let's, uh if anybody has anything to add on this, then uh please speak now and otherwise I think we should move on to the next item.

B

Okay,.

A

And as a standing reminder, this is an item that is desired for the edition, so, if we're going to make any changes to it, this is already very late for that.

E

Yeah, that was not.

A

Meant to suggest we should do it wrong for time pressure reasons, but rather, if there is substantial new design that someone wants to do, then it would need to happen in a hurry.

B

Yeah, I think yeah.

A

That's right uh so nominated prs and issues. We have the tracking issue for rfc 2345 allow panicking in constants.

A

uh It looks like the nomination was actually moved to 85 194.

B

Yeah I moved it there. This is the this is a stabilization issue that I created. um I think the current status there's been some discussion.

B

uh You can see it here and it's kind of waiting for one of us to fcp, merge or do something else.

A

Seems reasonable, I would.

B

Love to.

A

Have static, assert.

B

I think the I'll have to go double check the one issue that was raised, which doesn't bother me, but it's a thing as if we ever allowed catching panics in constants and people might catch panics. So if you were using them to signal some kind of thing that should definitely abort compilation, it might not work uh seems like okay, I don't know I I feel like. I would just document that you should be aware of that and move on.

B

um I don't remember if there were other major issues, but I would be okay to take an action item to tp, merge.

C

Yeah, I I know that I at least had brought up. I haven't had time to follow up on on the thread too much, but there was some discussion around sort of my.

C

My impression is that currently ralph at least feels that panics should always sort of abort compilation, um or at least like that's, the current implemented behavior, uh and I do think it's interesting to contrast this with what we recently discussed with the to do macro and unused warnings and stuff where, like it, it does seem potentially helpful to have some way of saying you know I have a content, maybe it's not being used or it's used, but, like I don't care about its value.

C

um I just don't want to implement the function for now um and it's interesting that sort of you know there could be a concern there. I guess.

A

I see you're talking about the idea of like const something equals to do.

C

Essentially, yeah, um basically, like you know I, this will eventually be a string, um but it you know the computation is hard and I don't want to implement it for now.

E

And.

C

You know if, if we stabilize then potentially there's people relying on the the fact that those are not right.

B

I would like to get well.

A

If we ever stabilize never type, then you could do const foo of something equals. Never.

C

Could you well I'm.

A

Not.

E

Sure there you go equals little everybody loops.

B

Well, that'll take the compiler a little while to get upset, but um I think like I'd like a that's at least a. I guess that is a concrete use case, um but I also feel like in that case you could. You could just write like this.

B

You could just write this, get your compilation, error and move on with your life until you're ready to fix it right, but.

C

Yeah it yeah, I mean it's sort of always true that you can not use to do and use, or at least most of the time it's true. You can always produce some sort of dummy value, but it's not always trivial and.

B

Yeah yeah, I feel like that, doesn't well okay. We should we should have that discussion now, but I it doesn't uh persuade me too much. I mean I use. The utility of panic is pretty high, so.

A

Right, I think it would be reasonable to have a way to specify a co, so I would like to phrase it slightly differently. I think that the thing that uh you're proposing that would have a not yet defined constant would be useful, and I think maybe we should have a proposal for that. I don't think that should be a blocker for being able to panic in a constant.

C

Yeah that that might well be, I think that it is worth noting that you know with the concern with catching panics. Maybe the thing that you know to some extent could be desirable is some sort of like const panic. That does actually guarantee a compilation report, um but that you know has its own complexity. So you know I I don't object to stabilizing.

B

Yeah I'd like to know an example of someone who would catch like. First of all, we don't catch panics yet, but I don't think there's any concrete example of like a panic that would be caught in where it's reasonable to do so and an era where you would be upset that the panic got caught.

E

I feel, like all the good examples of catching panics, don't apply at compile time right, because all those quote unquote panics compile time are already caught in the same sort of sense of like oh, I don't want the different requests interrupting each other. All of the const panics are caught by the compiler conceptually and don't interrupt the rest of compilation or anything so.

A

I could imagine someone writing like a complex function inside of the value of a const and throwing a panic and then higher up catching the panic and the rule could simply be.

A

We will error out if your panic bubbles up to the level of being the value of the constant as opposed to being caught while you haven't yet finished evaluating the constant that would be forward compatible with this proposal. I think right. I.

B

Think that's the proposed, that's the obvious semantics and then the question is just would somebody be upset about like? Would that be a problem.

E

But I.

B

Guess that's.

E

Your that goes back to the well. We can have a macro. That is, if you run this, this is like a panic at runtime, but it's a hard compilation error that can't be caught it. It's constant board. You can.

B

Make.

E

Cis exit.

A

There you go, that's actually a great.

B

Thought yeah, okay, well, does someone want to take? uh Is there any concrete, I mean move here, somebody could move to merge up or migrate.

E

The.

B

Concerns or.

E

I I think I still have a item to an action item to mur to propose merge. So, okay.

C

If.

A

You hadn't.

C

Yeah scott scott's action item stands.

E

With the, uh if the com, if all this conversation is resolved to yeah it's okay, let's do it then I'll propose merge.

A

And uh mark, do you want to take an action item to write up a separate proposal for uh what you're proposing for being able to do? I.

C

Don't.

B

Think.

C

I care about it that much okay.

B

I was gonna say, I'm not sure I think it's worth it.

A

So I meant that as a question not as a.

E

uh

A

Okay, all right, then, I think, let's move on to the next item and in the meantime, when scott uh files, the fcp on that, then people have more boxes to check. So next up we have tracking issue for unsizing casts in const fns there's an.

B

Sp waiting on fcp here.

A

85078, unless there's.

B

Any reason I think we can move on.

C

No, I don't think so. uh I I can uh nominate yeah.

A

That'd be good, oh, I see this one is marked to fcp and actually it has entered its final comment period seven days ago. So.

B

uh Similarly, I don't think there's any real updates here unless there was some lib discussion. This is the buggy point.

C

I think the only thing is whether we care to keep checking in. uh I think that it is potentially reasonable that we just nominate unless there's further activity, which I think the loose next step here from my perspective, is that you know there's a lib discussion. Potentially some pr's are filed and once those uh casts are added, um the lint would likely be sort of in a better place to recommend the casts in more cases, um and we can actually.

A

The libs discussion did happen and I can give the very brief summary there.

A

The response from libs was that we are very amenable to getting proposals for concrete functions that serve specific subsets of as and it would be fine to have those proposed individually, and it would also be nice if somebody had a more comprehensive list of here are the uses of as and we'd like to propose functions for almost all of those, but uh that isn't a blocker, it's more of a nice to have, and we would take patches for individual functions for portions of, as as as they are today,.

C

Sure yeah, I I just meant not that discussion but the like actual you know, proposal for specific functions and then once those functions exist, then a laying discussion or whatever can happen to say we're deprecating this bit of as in favor of this set of functions. This.

B

Sounds like a to me. This sounds like a project group. I.

A

Think it is.

B

I think we should close this and say we would. We would entertain a project proposal to with the goal of deprecating asks and this right outline, because it's it's a unit of work that needs to be sort of chased.

A

And then giving them.

B

A summary.

A

That libs is amenable to taking prs to add those functions and that lang is amenable to taking a lint proposal when it has concrete functions to recommend, rather than as x as y.

B

Yeah I mean, I guess, I'm placed I'm fine with people adding those functions piecemeal, but.

B

I would in terms of deprecating as that's a language change in my view, and I would like to see it done in conjunction with when we know the full set of functions or a reasonable set of functions exist.

A

Also, uh as a caveat there, I don't know that we'd want to position that as deprecating as because one possible.

B

Limiting as.

A

Right exactly uh one bit of feedback from the libs team was that, as is really convenient for short pithy code, and so it would be nice if it were limited to reasonably safe cases that did not lose information rather than getting rid of it entirely.

B

Yeah, no, I take back what I said. I do think a project group would be fine, but I also think I'm trying to think how we can. I would like to document our intention to do this and it would be fine by my view. That seems like a good quest issue too right of like there's some work to write out the set of things to be done and then there's a set of pr's to add those apis and deprecate those slices of ads. They don't have to all happen at once. They can happen. It.

C

Does sound like a potentially.

B

Good fit.

C

For a design note basically saying that yeah, you know we discussed um here's the loose state, but maybe you know there's not actually someone who is willing to drive right, but also you know, maybe there is, and they literally copy paste the design note essentially into a project proposal and say I want to do this.

B

Yeah I I like that. I think we should have this sort of it's not a pre-approved proposal, but it's a suggested proposal.

E

Yeah, I sort of feel like this, isn't quite as holistic in design. Necessity as like, I feel, like a project group, is sort of more focused on that like adding individual apis, for this is a particular use, might be sufficient to sort of do it as it goes along yeah and then.

B

It's up to you to make.

E

Sure that those lit those apis are all logical and coherent and makes sense.

B

Basically,.

A

There's value in a project group doing the design work to figure out what seems they should carve along to provide orthogonal functions for uses of as.

B

Yeah, I can see it too, like.

A

I could see.

B

Us if we do a piecemeal, I'm kind of okay either way, but I could see that doing a piecemeal winds up with like inconsistent names and just sort of strange coverage that could have been nicer.

A

If nothing else having a project group like even if they don't write the net the code themselves, it would be helpful if someone else wanted to shepherd the proposed items into the language and like go solicit patches either way. I don't think we have the bandwidth to do so.

E

I guess my sort of thought here is that, like if someone just went and wrote a libs rfc with all of these things, then it wouldn't really need a project group because it would yeah that's like once the api is defined. You write a pr, and this is fair.

B

It could go straight to rfc.

A

Yeah, we could note that that like, if you want to do this as a project group and do it incrementally or if you want to do it as an rfc and propose a comprehensive change all at once, either way is okay.

E

Yeah and I sort of feel like a lot of the hard part here- is that lib's side of what is the right way to represent all of these things? Are there traits for them? Is it extensible? How does how do consistent names look, etc?

E

And once all that has happened, the sort of lang side of this of hey? We can write lints. That recommend you call. Those library functions is not very exciting. It's good and I would like to have it, but I agree: it's not a laying team, complicated design, question.

C

I absolutely agree.

E

Yeah.

B

Okay, so let's write up that so meeting consensus. I think we should close this pr personally, because we've kind of concluded, we don't want it, as is right. Now, right we want to suggest, is so close. The pr suggest adding apis to carve to the standard lib for these sorts of casts.

B

Per libstein process.

B

Right ideally do this comprehensively, but this is a libsteam approval question uh and then once apis exist. Lints are welcome.

A

Okay, I would be happy to take the action item to write this up, since I can do so with both lang and libs hats on.

B

I would yeah, I would say, do it. I would also like to, if you don't mind, to copy and paste that into a design note um in the laying team, repo.

A

Sure I think the structure for a design note would be slightly different than the structure of a comment. But yes, I could try to put a design note together as well.

B

Yeah just try something I feel like we should have. This should be documented somewhere. That's not like a comment on a pr.

A

No, I think, that's sensible.

B

So.

A

I can take both of those action items. Sure, okay, great.

A

All right, let's move on to stabilizing range from patterns. This is eight three, nine one, eight.

A

uh As the summary notes here, we have a complete fcp, but we also have a comment, noting that there's a unfortunate ambiguity where people may expect something to work differently, either based on experience with other languages or just based on logical semantics.

B

Yeah yeah, I.

E

Feel like we discussed this when we stabilize dot dot, though.

B

Yeah, I also think we did I I don't.

B

I could see people being confused but also like when you do know what it means. There's, no other.

B

I guess the question is: did you mean there's like a typo potential right where you meant this, but you you wound up getting this weird thing, but then you're going to get type errors. It just seems kind of unlikely. This will actually compile and successfully pattern match when it's not what you wanted.

A

So I agree: on the other hand, it seems so unlikely to be what you wanted. Oh.

B

I take that back. I take back what I said. I keep forgetting that this like because this would match an array of integers, and so would this.

A

So right yeah, um it seems so unlikely to be what you want that it seems reasonable. We could take bistri's suggestion here to uh not allow the specific case of integer ranges, and then it would be trivial to say unless you parenthesize them or similar like if you, if what you mean is really, I want to match uh a one element array that has a number zero or greater in it. You could write that this way.

B

Yeah, it doesn't seem that unlikely to me, but I do see the value.

E

Of requiring you to be sure, is this a that's? What I was about to say is this a parser error, or is this a lint.

A

I don't think it's a hard error. I think it's a worn by default lint. This is probably not what you know. This may not have been what you wanted use a parenthesis if it is what you wanted and we would only need to lint here, I think on uh single element cases, because if what you write is something like this.

E

I mean if you're matching a.

C

Single.

E

Element, I feel like we should say if you want to match a single element, extract the single element and then match on it, but.

A

Well, that would be a two level match, though it is.

B

Convenient to do yeah sorry, I agree. I agree with josh. I'd want parents.

A

Yeah, I think that requiring parents here to avoid the ambiguity, is not unreasonable, since people seem very likely to assume that this might be something else.

B

I'm persuaded by lint for single element like the single element. That's a pretty crucial observation but yeah. That makes it very much lint to me right.

A

I will say I do commonly wish to use uh slice patterns because I'm matching some a slice, and I want to say for the single element case. Do this, but the idea of combining that with a range I think, having to use a parenthesis. There seems like what I would want to write anyway.

E

Yeah, it feels like the frequency at which you'd have to add. These extra pairings is low enough that I don't feel bad about them. Yeah.

B

Okay, so I think our consensus is, we would like to request a lint for the single element case.

A

A worn by default, lint, concretely yeah.

E

Does this need to block the pr so.

B

Fcp stands, I don't think it blocks the pier.

B

Maybe we can open an issue, that's what I would do.

A

Or we could ask you.

A

Yeah, this would likely be a good uh like first issue for somebody delving into compiler lintz.

B

Yeah somebody somebody will close this in a day if we open it. Okay,.

A

uh Does somebody want.

C

To take.

A

The item to open the issue or do we want to suggest to b street, to open the issue.

C

I think maybe a good good next step is to say uh I I can leave a comment, basically saying that you know we discuss this. We think that a worm by default lamp for the single element case addresses this concern. um You know, maybe, if you agree, please file an issue uh suggesting a lint. For that case, we would be happy to you, know, see it implemented and approve it.

B

Yeah, that seems, okay.

A

Sounds fine.

C

And that also leaves it open to you know, maybe uh they disagree and say. Actually you know you completely misread my concern um versus insufficient.

B

Yeah, if he feels that way, he can make the case.

A

Okay, I think that that addresses eight three nine one eight, unless anybody has anything to add.

A

Okay, then, moving on to eight four nine, eight eight, we discussed.

B

Are you taking that action item.

A

Yes,.

A

Sorry, no problem, so we discussed eight four nine eight eight uh previously, but um there was a follow-up here, so this is proposed for merge to make target feature safe on webassembly and the there are three outstanding check boxes on it. But in particular I wanted to follow up because ralph raised a concern and then alex addressed that concern.

A

It sounded like the question was: would llvm ever do optimizations on the basis of you're calling a function that has a different target feature and I think it's fairly self-evident and alex is making the case that, like llvm, can't make that assumption. That's a rust specific assumption that for rust safety purposes, llvm absolutely allows you to call a function with a different target feature after you've. Checked that you have that target feature.

A

So I don't think that that concern is something that we need to block on, but please feel free to take a look at alex's, most recent comment from two hours ago and see if that addresses anything and then we're looking, I think for well. I think only one person in this meeting has the checkbox uh still unchecked and then taylor and felix are not here but nico. If you want to take a look at that.

B

I remember feeling vaguely weird about this. It's like what's the motivation is again I mean, I know.

D

That, like.

C

You can't have more.

B

Than one instruction set on webassembly.

A

Right well, or even if you could, it would not be unsafe to call. The premise is that uh we have this unsafe on platforms like x86, because there are legitimate cases where old processors misinterpret new instructions and could do arbitrary, undefined behavior that will never apply on web assembly. Even if there were a mechanism for differing instruction sets, there would be validation of uh like either it understands it or it doesn't, but it won't do undefined behavior.

A

So.

B

This is just saying if your target is specific to wasm, if you, if you're, if you use target feature with a wasm target,.

A

Right exactly, it would only be unsafe to call target feature if you're not on a wasm target.

B

I see so if you're on a wasm target and if you're targeting wasm and the target feature is for wasm or some wasm target feature. Then it's okay right, okay,.

A

And the premise for this is wanting to make wasm's intrinsics, not unsafe, or rather the ones that don't have to do with things like raw pointers. There are still intrinsics that will be unsafe because they touch raw pointers, for example, but regular, like math, intrinsic cindy, intrinsics, etc, should not be unsafe. Right.

B

I have a question then, which is this seems related to our discussion about apis like.

B

Why do you have those target features in the first place, and uh why is there more than one kind of, and we know that the wasm spec is evolving, and so are we just not? I are we just not concerned about like I'm targeting wasm 1.0, or we expect sort of some other semver to to play that role. Do you see what I'm saying.

A

Right so we do. I think that is the rationale for having target features on wasm is that you may not wish to require a new wasm interpreter that understands semdi, for example, and so though, so this note here is not actually the case. There are wasm features that are not understood by some wasm targets.

A

However, they will not misinterpret them, they will do validation and they'll say: oh, I don't understand that, so you don't get to run it all.

A

So you can never break an old wasm interpreter, but you can prevent.

C

Yourself.

A

From running on an old wasm interpreter- and you may wish to not call a function with a target feature, if that's the property that you, if you want to run on an older interpreter, so.

E

One of the things so I have my box checked, but I wanted to. There was one thing that came up that I thought was interesting is the whole target feature 1.1 discussion, because people want.

C

This.

E

For non-wasm too, like the target feature sse on x64, wouldn't have to be unsafe, either. Hypothetically.

A

Well, that's interesting, so I think those are two different things. There's target feature 1.1 where you should be able to call safely call a function that requires like avx in a function that already has required. Avx, then separately, there is, should you be able to safely call a function that requires sse on a platform that always makes sse mandatory like on x864? You always have ssc and ssd2.

A

uh I don't think that's target feature 1.1, I'm not sure there even is an sse in sse2 target feature available on x8664, but.

B

Sure it I'm just thinking now didn't we decide recently we sort of decided we wanted to avoid target specific errors and stuff like that target.

C

Features are already target specific, so you can't ever use them in non-target specific code. So it's kind of.

A

Yeah, okay, we don't need it, we don't need a portability lint here. You already know you're not being portable. If you write target feature.

C

Well, there's no name spacing or anything, so it's like it's literally, if you're not doing some sort of config by the target or only compiling for one target you're almost certainly doing it wrong.

B

Okay,.

C

Right.

E

So all right to your comment, there josh, um I assume there is a target, feature sse or pick one that actually works, because I'm not very good at remembering target features on x86 and that one's just always. So what happens if you have tart one of those target features and you're compiling for a x64 target.

A

um I don't know if it necessarily even compiles, but if it does, then it should probably just be ignored like there is. You always have ssc and ssc2 on x8664. So if it even allowed you to write target feature sse, then it should just be a no up.

E

Okay and that's different, but I think.

A

Wasm.

E

Case because wasm, you don't necessarily have the target feature in your target right. It's just.

A

Safe to call.

E

It because it won't be you be okay, thank you that explains.

A

The difference to.

E

Me.

A

You also raised a point on the issue which I think is worth reiterating here, which is uh like a lot of things are safe-ish in webassembly, in that they don't def have undefined behavior, but we still don't necessarily want to make them safe, like we don't make raw pointer, intrinsics safe on web assembly, even though you can't actually cause ub by invoking them. You can just go scribble on things, but that isn't the same thing here. This is more. The underlying reason we had to make it unsafe just doesn't apply.

A

Yeah.

E

I would also argue.

A

Just not this.

B

I would also argue that is still undefined behavior, just with a somewhat narrower scope like.

E

It can't yeah it's rust, abstract machine, undefined, behavior right in the same way that ralph has written 17 blog posts now about know what the machine does isn't. What russ does.

B

Right all right, I have to drop another call, but we'll oh yeah, we'll move on thanks all. uh Is there an action? I'm here as me check my box. Okay, I'll just do that. Thank.

A

You well uh also felix and uh taylor sure they're, not here.

B

Sure, um okay, thanks everyone all right! Thanks all.

B

Bye.
youtube image
From YouTube: 2021-05-18 Triage Meeting

Description

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