Rust Programming Language Language Design Team, 29 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Design meeting 2020-07-29: WF checks and type aliases

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

A

So I guess I'm running this meeting. It's been one that we delayed for a while and we can discuss that reasons for that and whether in particular like whether we care enough to make oh I'm trying to get share this document and I'm feeling because.

A

Reasons: um okay, so let's have it right. So the topic of this meeting is around the well-formeness checks of tight, aliases and there's been a lot of this has come up again and again, so I don't want to talk it over and decide if and what we want to do about it. Most recent case that it came up was this pr, but before I get into that, let me just dial back one second for context.

A

um Basically, the problem here is that, where the way that rusty implements type aliases is doesn't enforce a lot of constraints on them effectively, what happens is the type checker and the trade checker they never see the type alias at all.

A

uh Instead, there's like a front end, part of rusty that expands type aliases very early, and so, if you have like type meleus type, my alias is u32 and a function that uses my alias the way the type checker sees it. It just sees u32 it kind of never sees the my alias and it also it does. It can see this definition, but we today we ignore them um and so some consequences of that.

A

Well, let me reorder this one of them is that.

A

Unless the type alias is used, we never look at whether this type is well formed right. So if we have, for example, my type which requires the debug and then we try to give it a dim display, that's not well formed in two different ways: we're never going to report an error here today.

A

If we, unless you happen to use it in a function, and in that case the compiler will see this type.

A

And it'll check this type and decide that it's not well formed and issue you an error, and so it doesn't get it's not because the alias sort of is not well formed, but because the use site and that's pretty different from like, like, for example, struct fields.

A

If you had a struct field like this, when we checked the struct definition, we checked that all of its fields have well-formed types. We don't wait until you use the field to do that check. So it's a little anomalous.

A

um Another consequence of this is that there can be tight parameters and we basically just ignore these, where clauses almost completely not entirely um in the way we don't, but instead we just substitute the types in and if the, where clauses happen, to match what the struct requires, then that's. Okay,.

B

A

That sort of lines up with the air, you will get the errors you expect, but otherwise you you might or might not so like if you have just right, alias here as long as that alias is used, then any or any attempt to use. Just. Let me rephrase that any attempt to use just write, alias with with a type x, will error if x, debug is not true, but not because we're checking the alias, but because that constraint comes from my type.

A

The problem here is that this you might be surprised by this example, because here, if you just look at the type alias in isolation, we don't know enough about t to know that my type t is well formed, and here the problem is that too many alias of vac of u32 is not an error, and that's because even though vector u32 doesn't implement display, we don't actually look at those where clauses.

A

So the one, the one way that we do look at those where clauses is that very early in the compiler another thing which probably wants to change at some point we handle, if you have an expression like a colon colon, an associated type like um like this, you will get an error because the compiler doesn't know what trait item comes from and if you're right, so you can. You can avoid that error in two ways. You can write this, in which case, depending on exactly what rules.

A

This is something I don't actually know how well we've defined it, but you know this. This might be an example of having too few bounds, because in principle you shouldn't be able to write t as iterator item without knowing the t as an iterator, but you can also write this and the compiler uh knows that does take the where clause into account in that case, um and that's because this expansion happens kind of in that same very early phase. That's the context.

A

I guess the only other bit of context is for a time, and I don't remember if we're still doing this, let's find out uh for a time we were giving warnings if you had any where clauses at all. Let's see if that's still true.

A

Yes, that's still true, so we give a warning saying the bound is not enforced, which is true, and then we give some helpful hints, because the problem is. If I just take this bound away, then I get an error because it doesn't know what to do so. We give a hint saying you can write this in this more painful way, um although in basically every crate that I've ever had. I just disable this annoying link, because I don't want to write that more explicit way.

A

So we're the problem with this okay, um I think so. The question is: what behavior do we ultimately expect given where we are today? That's, I guess the questions I would like to settle down today is sort of.

A

If we can, we can maybe decide what we think the behavior ought to be. We could also decide how important it is and if we want to do any incremental steps towards that behavior like take it around the edition, especially if so I'd prefer to think about it. Now, because last time eddie b decided to do some experiments close to the rust 2018 timeline that just didn't work. We just we wound up not doing them, because it was too stressful to try it like it's, not that important to land uh compared to like nll.

A

um So I think if we are going to think about this, we want to be thinking about it on the earlier side. uh So I'll stop there for a second, because I've been lecturing for a while. Does that all make sense, any questions.

A

B

B

Makes sense so far, um it seems particularly problematic that we have a case where we error. If you uh do one thing and warn, if you do it correctly, that's definitely something we should try to avoid in the compiler anywhere anywhere we can, but the general problem seems relevant as well. That one just seems like a case study in how bad this is.

A

Yeah, so I think in terms of the expected behavior, I'm curious if other people's intuitions match mine, but I would expect naively that a type alias is legal if a corresponding struct, if that type were legal as the field of destruct, essentially.

A

In other words, I would expect that you have to. We have to check that you is legal given what we know about the generic types at the declaration, and then, if we know that, then we automatically know that all uses of who must be legal, because unless as long as they meet whatever, where clauses are in scope,.

C

You won't really want me just to rule or be like. Oh, I mean obviously there's size in this too. Right types are type at least, presumably sized.

A

uh C: yeah, okay, yes, I don't mean you're right, I don't well. The last field of a struct is not required to be sized actually, but um I don't mean it that literally.

A

I suppose, although I did write it very literally, but I meant like basically, I would expect us to check the type at the point of declaration that it's valid, given the where clauses that are declared on the type, I think that's my naive expectation, I'm not sure that actually has great user experience uh like for the same reason that we wanted to do implied bounds, which we haven't kind of gotten around to yet.

A

But you know that it seems like that, will have the experience of copying and pasting a lot of where clauses potentially, and so it might not actually be what we want. We actually want. That was my naive expectation.

A

Did I understand you correctly felix, like you were saying that strucks may have additional requirements around yeah.

C

That's basically what I was getting at the if and only if it gave me a pause. That's all yeah.

A

A

uh Yeah, maybe I should just say if I guess it's not only if.

A

So one thing that.

A

Yeah I'll say, but nico has usability, concerns related to implied bounds, and that brings to the next example, which is that.

A

A

I guess I guess to elaborate this a bit more.

A

If we had we've been saying that we want something, at least in some contexts, we want to be able to say.

A

That you know you've been saying we want to be able to assume in like an impul. That t is a debug. uh Maybe you could make a case for type aliases behaving in a similar way. I don't know which I guess is the next point. um So one thing I was thinking about is that we could rationalize the current behavior in a sense like right. Now it has no. I don't think you can explain it in terms of a traditional type system.

A

You have to explain it in terms of like macro expansion in the compiler, um but I think you could explain it in terms of a more chalk like type system, if you assume that when you see this syntax of a type alias it's kind of short for this, which is not actual syntax, but it is something that chalk can represent and it's the basis of how you do implied bounds, uh which is to say that you have this, like you, add, essentially a where clause saying that this type alias gets to assume that the right hand side is valid, and then now it's on the user to prove that, where cause is true, that's effectively what our behavior is de facto right, um and I would note that we are going to have to do something similar around functions.

A

C

I want to pause here because I I want to make sure that I'm understanding that the point you're making here about the what comes from the implied bounds, because that there's two ways to interpret it in terms of the point you're making about the same thing arising for type aliases.

C

I wasn't sure if you were talking about initially the type definition, the type alice itself, somehow causing implied balance somewhere downstream to be inferred. But I don't think that's what you're talking about you're talking about a struct upstream, it's implied bounce affecting a type alias that uses that struct right.

A

Actually so what I think I'm trying to, let me think what was I exactly saying. I think all I was saying is that, like the most narrow version of what I was saying, is that if I have some structure like this, and I want to have like an alias like.

A

This, it just seems like kind of annoying boilerplate that I have to copy and paste all these wear closes, uh and so it might be nice if I didn't have to do that, um and this would be one way that you could sort of avoid doing that now. There's another question: that's like relating to implied bounds, which is like if I, if I wrote this in some function,.

A

Can I assume t debug here, which is what I would be able to assume if I had written it? If I had the fuller version of implied bounds.

A

And I had written it by hand, and I think the answer should probably be yes.

A

um And that seems a bit orthogonal, but it actually would probably fall out from the machinery that the way talk had the stuff set up um like what it's worth.

A

A

Anyway, so I was saying.

C

Then, with that clarification in mind, then does that I mean? Can you help? Does that? Can you help explain then what the example you give in the rationalizing the current behavior with the where well-formed like how those tied together or is that not what you're getting at.

A

uh Yeah, I can explain how that would tie together. So the way that implied bounds worked was that in the way it's sort of designed in chalk, at least, is that you have these well-formed predicates, like I wrote there, that we don't no one ever writes them explicitly at least not today, but they come from.

A

The context where you are so functions get to assume that their parameters are well formed and impulse get to assume that the types in the trait are well formed, and we know, and chalk has some rules that say like if I get to assume that this type is well formed. That implies that I can assume some other things similar to super traits the same.

A

In fact it subsumes the super trade mechanism, so we're saying like in the same way that if I know that t is- or I know that it's partial ord, if I know that my type t is well formed- I know that t is debug, because that's the requirement for t to be for my tech to be well from um so there's kind of a bi-directional relationship.

A

I guess, and so if you set it up that way, the way that this would fall out, this function would get to assume that this type, alias is well-formed, which would in turn imply that the right-hand side is well-formed, which would in turn imply whatever that implies. I guess that csd or something um I think you could. You could make that all fall out reasonably well. um Does that answer your question.

A

C

I guess let's, let's keep going yeah. I think it's not.

A

The higher the bit, although it's relevant there is a catch, however, that I want to point out, uh which is that.

A

This explains why we can accept examples like too few, but because we get to assume that the right hand side is well formed, even if we don't have enough, where clauses to justify that, but it doesn't prevent you from adding extra bounds and the way I had sort of expected to do. That is that we would move the handling of aliases so that they're part of like chalks, they're kind of more, like associated types and chalk, is chalk and the type checker or know about them as they're.

A

Just a they're, just another type that we happen to know is equal to its right-hand side and we propagate that through. But um in which case we could enforce the bounds.

A

However, that would be backwards incompatible because now code that exists today. That uses too many bounds and doesn't get any errors, for it would start to get errors, and I don't know how well we could probably handle that over. In addition with some thought, but there is one particular case- that's really relevant that I want to bring up uh because eddie with all that context. Eddie did some experiments and I I didn't have time to write down all the experiments they did.

A

I think we can go look them up, but one of the ones was looking for cases where there were too many bounds kind of similar to the drop check code that you wrote so long ago. Felix um and the one case that was really common was a type alias like this, where actually there's too many bounds, because this would be the strictly most general version of that cybilius, um and so this, I think, is a good example of like a kind of ergonomic regression hiding inside the implied bounds approach where, if you assume that.

A

The use the user doesn't have to write all the bounds. They would need for the right hand, side, but any bounds they do write are respected. Then they're implicitly writing a bound here. They may not have written. I guess is the point, uh and maybe that's okay and we just like that's what we do everywhere else. Where this happens. You have a struct declaration, you have to propagate the question mark size and but it's something we would have to manage intelligently.

C

Or we could, uh this may be bonkers, we could make type, aliases implicitly have um question mark sized and if you want to enforce size in this bound, you have to say it's an interesting point. So.

A

Well, but if we have the implied bounds approach, actually that's not as bonkers right, because now you start out with the fewest bounds possible and we just imply all the ones you need, so in particular, you would get sized if you needed sized right and that's kind of what the code does today.

A

If you think about it, uh just does that check? That's exactly what the code is today.

C

What do you mean that that's what code does today? If that's I mean eddie, obviously ran into this problem, so can't be what the code did at the time of eddie's experiments.

A

C

Sorry, what I.

A

Mean is well eddie's. Experiment is not what the code like was a change to the code. They never landed, but by enforcing, by only looking at the expanded form of type aliases and and checking those for welfare.

C

But then you don't get the enforcement of the pounds. People do declare, which is what we're trying to.

A

Yes, exactly we're losing that as a size. That's a really good point so I'll, so that might be like the the sweet spot. In terms of I have to write as little as possible. At least is you don't get any question marks high? You get question mark size by default and we assume the right-hand side is valid.

A

A

Given that, let me jump back to this context of what was esteban's pr, so esteban's pr said: let's produce an error if you have a non-generic type, alias with nowhere clauses- I guess probably I don't know if it's actually in the pr, but I think that would fit the spirit of it and the right hand side is not well formed.

A

So like what's an example of uh I don't know, I guess something like this.

A

This would become an error today, it's not an error. Unless foo is used.

A

Now this is okay. I guess this is heading towards, in my view, the naive rules, like not the implied, bounds variation, um because it's a sort of subset of the errors we would ultimately want, whereas in the implied balance variation that I was describing, there would never be an error here um unless it was used to sort of meet the behavior we have today.

A

I think the idea was, I don't know if we did a crater run, we didn't probably should have.

B

Have we done a crater run on the full, like just enforce wealth formidness on all type aliases, I'm assuming the answer is, it would be horrible.

A

We well, we can't actually do.

A

So yes, the answer is yes and I didn't get to get around to fully collecting all the results and they're pretty dated they're like years old by now, but even at that time, eddie did a number of experiments and we can probably dig some of them up uh and what they found was that some parts of it were not particularly didn't affect a lot of crates, but I think the biggest, but some parts did that's what all these pr's were.

A

They were like checking different things, different slices, like look for cases where there's too many bounds or look for cases where there are too few bounds. um It seemed like I think sized was.

A

Okay, there's some overflow, I don't remember what that is, and the size was the most common case, but the short version is yes just doing. The full thing has a big impact.

A

Particularly because of certain specific patterns.

A

Unfortunately,.

C

It's clear to just comment here that eddie did consider where consider what we were just what we were talking about about making uh sizedness, not implicit in a type alias, although it maybe didn't go as far as what you were talking about with implied bounds. So yeah.

A

I think if we were just looking for cases where there are two like, if we were saying that we want to move towards this implied bounds, this so-called sweet spot, then I guess the only difference between the current code and that code is the too many bounds cases where, where there are bounds that are not required for the type to be well formed and of those cases, the only ones we care about, or we don't.

A

We don't care about size bounds because we said that we're going to change that default and that, I think, was the most common case. So that's kind of interesting. So if we look at like, let's see if I can find the numbers for that ensure type, this is.

A

A

So right most of the failures come from diesel. I don't really know what that's about. We have to look into that, but there are a few legitimate, not a huge dent.

A

Yeah, that's not a very detailed analysis, but 56 regressions, but yeah I can see a lot of them aren't easy. I think this already was ignoring sized cases yeah. So here's an example where this requires clone, where the right-hand side doesn't require a clone.

A

um On the other hand, like we did it as a a migration.

A

I don't know this is the kind of thing I would prefer not to keep. I don't. I don't particularly want this to be across additions if we can avoid it, but.

A

So still that's an interesting thing. So observation.

C

But you know, under the definition only the hypothetical semantics that we're talking about it shouldn't be wrong to have extra bounds right in terms of like using the struct based samantha, their uh struck base analogy earlier. It's only wrong if there are uses that don't meet those right, but it seemed like eddie's code that experiments pointed at was not was going further right, that's what the he was enforcing it at the declaration.

A

C

A

I guess the yeah, and so it's quite possible that if we just changed to the side, like it's quite possible that although the declaration site has extra bounds, all the uses meet them, even though we're not enforcing it, and so there would actually be a silent like if we actually just changed it. It would have less impact or there'd be no in there.

A

That's really interesting.

A

Yeah, so I guess what I was saying was: if we wanted to do a future compatibility thing where we don't actually move yet to the new system, but we just rule out code make sure that all code would be compatible the only way I know to do that.

A

One way to do that would be to enforce it at the declaration site. That's too conservative, as you point out, but we did run that test. We saw that it has some impact, but not monstrous. I guess I don't know. 61 is not nothing also.

A

A

I guess the bigger question for me is like: how much do we care about this? Do we want to be moving.

A

Incrementally towards something or just wait, figure out the implied, bound story and uh leave it as is basically it's not getting any worse or better than it currently is until we have so we're in a better position. But I have.

B

A

Bathroom, so you all can discuss amongst yourselves. I.

C

C

There was one subtlety earlier josh I figured, I wouldn't bring it up, but you know you made the point that the warning given by the current system is, you know, warning you about the ballot version of the code. I think that what what's the right word, uh I'm being pedantic, I think it does tell you. The warning tells you a third variant of the code that I think would be accepted and um isn't the one that leaves out the well? No, it doesn't got the bounds, but it has the it's the whole.

C

You know ts, iterator, colon clone item thing. I don't know what the right version is. I think probably the right version is the version that we're warning about because, as nico said, it's you know intuitively who's.

B

Right, um I was going to say I tend to treat any case where you have to write out uh some type as some trait in angle, brackets colon calling something right. If that's the only way to write something, we've done something wrong.

C

B

That sounds about right, but yeah. I I appreciate the semantic distinction and yes, there is apparently a way you can write it, but all that said I think I would personally say in an ideal world.

B

In the absence of the concern about breaking existing code, I would love to just completely enforce well-formedness on type aliases uh and require that you specify all of the necessary trait prerequisites.

B

Yeah, and the only reason I see not to do so is the sheer volume of what that would break, because we don't want to make everyone rewrite all of their code for a new edition.

B

You know, but I would be all for finding substantial subsets of this, that we can do and then adding a uh um you know making it making it an error for, say you specified some traits, but not enough or you specified too many traits and then, if the primary case that people would get an obscene amount of warnings about, is you didn't specify any traits at all?

B

Then we could treat that one as an allow by default lint and encourage people to opt into it.

C

Like basically like treating a special case that people who leave out any bounds at all, aren't haven't migrated to this new uh form.

B

Exactly yeah the goal being uh that way, we would hopefully get some substantial warnings to get people to fix, but not worn on every use of type aliases on a generic, because the majority of type aliases on generics seem to be just t on the left and t on the right.

C

Yeah, I don't know well.

C

Nico's not here, so I don't he's the authority on the architecture here. I don't know how easy it is to sort of get the different behaviors.

C

Let me let me take a step back, I guess and say what I do know so. I've been thinking about this, like from the start of this conversation in this meeting in the back of my head, is always like okay. Well, could we make this change but put it under some sort of future incompatibility warning type thing um right and usually the answer for things in the type system are no.

C

We can't because it's not feasible to actually like detect the uh you know the thing that's causing the problem and run the code sort of before and after, like might get the two different versions of it um in any straightforward way. So I'm assuming that this is that's the story here too.

C

As far as I can tell, um and so I'm a little worried that you might, you might run into something similar here with what you're describing of you know, trying to treat the no given bounds a special case, but maybe not maybe, since it's something you can do up front syntactically. Maybe that gives us sort of a secret door um we'll see. Let's see what niko thinks, at least of that hypothetical.

B

One other thing worth mentioning here is: I do actually like implied bounds in other contexts and in particular I find it to be painful when I have a type that has two or three bounds on it, especially if they're complex bounds uh and every single time. I write that trait in a fin. I find myself restating all of its required bounds on just to be able to name its generic parameters.

B

So I'm not going to argue that we should um abandon that for type aliases. I'm actually seriously wondering- and I don't know to what degree. This is just consistency that I'd like elsewhere and to what degree. This is the right answer, but I do actually think that implied.

B

Bounds may be the right approach here, but I think there's a very good argument that even if you're relying on implied bounds for the t with no qualifications approach, that doesn't necessarily mean that we shouldn't warn about you specified bounds, but there aren't they aren't enough bounds or you specified bounds, but some of them are superfluous.

B

If we can warn about those, I think we should, and then there are multiple arguments for not warning about unqualified generic arguments. Both because implied bounds might mean we never want to, and because even if we do want to, there would be an obscene number of warnings.

B

A

I felt like there was some inconsistencies in what you just said. Maybe I didn't understand it.

B

It's all right.

A

B

You elaborate mika where I said: could you elaborate a little.

A

Yeah, it just seemed like I it sounded to me, like you were simultaneously saying people shouldn't have to write too many bounds, and we should warn if they don't write enough pounds.

B

ah What I was proposing was I don't like having to re-specify bounds that a type already has in it, and I have run into that many times in not in the type alias case, but in the um uh type case in general, I've got a type or a trait that requires four bounds and they're complicated bounds, and I'm writing a bunch of functions that take that type and every one of those functions.

B

I have to name all those bounds so that I find to be unpleasant and, I think, implied bounds is valuable so that, for consistency's sake, that seems like an argument that we also shouldn't require all those bounds on a type alias, if you just say type foo of t equals.

B

Some type of t it would be the same case as implied bounds. What I'm arguing is, if you specify any bounds, then you shouldn't specify too few or too many bounds, because that implies that you think you are matching the type on the right and you're. Not so that's worth warning about, but if you don't say anything at all, if you don't say any bounds, then treating that as implied bounds seems reasonable.

B

I think we should do the same thing on functions as well.

C

So I have a similar pink attitude, except that the detail about write down bounds. I think you should be allowed to write down extra bounds and it shouldn't matter about the right-hand side. If it's it's to me, you could. You should be allowed to specify bounds and make this that's a statement about how you want this type alice to be used.

C

It doesn't matter about what its body is interesting, but that's that might be a detail. It's worth debating. It's it's. Nonetheless.

C

Our situation right now is that we can't we're not even forcing the bounty to declare um what what josh one thing josh had said. While you were absent niko, I don't think you caught it.

C

Was that an idea of as a migration strategy to do something where we start trying to enforce bounds that are declared that are written not explicitly and if a type, if a typolist doesn't have any bounds on any of its type parameters, then you silently start or maybe not silently, I don't know, but do something special with it in terms of saying, okay, we're going to not check this one, because it's clearly from the time before we started enforcing these things or whatnot.

C

I don't know if that would help at all in terms of the architecture that we've got, but.

B

I should clarify that what I was suggesting was more. This is what we could do if we want to enforce that, you always specified enough bounds that you could do say something like an allow by default, lint on a no bound type alias, but I don't actually think that we should do that.

B

I don't think the more I think about it. The more I very much want implied bounds and I don't want to enforce the uh requirements. If you don't specify any bounds, I think we should just enforce that. If you specify bounds, you specify enough bounds.

B

I think your point is reasonable. Felix. You could specify too many bounds and then we actually enforce them saying if you're going to use this type alias. I expect that you also have this found. I think that's reasonable. As long as we actually enforce it. I think those are both reasonable strategies either. We tell you that you've done too many bounds on your type, alias right at the point where you make the type alias or we actually enforce the full balance that you specify on a type alias, even if they're too strict.

B

I can actually imagine a good use case for the latter, which would be a public api. You could have a public type, alias that enforces more bounds than the underlying type requires, but it's actually those bounds as part of your api surface area.

B

So that it isn't a breaking change to later, add them.

A

A

I think I feel the same as felix that I expect I definitely I expect any bounds. I write should be enforced and I don't see why, if you're allowed to write bounds, you should be forced to write just the right set. That seems like a little strange to me. um Apart from the reality of this, I was implementing. Of course, uh I don't.

A

I was strong. The only my only hesitation on the implied bounds thing is that the way we set up implied bounds today, it's like.

A

When you're defining, I guess the way we drew the line was sort of structs.

A

Certain things are like the sources of implied bonds and they have to list out all the correct rounds and other things are like consumers of implied balance, and they don't have to list them out. So it's only kind of one hop away in principle. Right, like the function, you see the type used you can jump to the type and you you know from that immediate type definition, not by examining all the types of all its fields.

A

You know like the fact that it requires t debug or whatever now granted there are. You know there are many parameters and you might have to look at all of them to find it, but it sort of limits the amount of its distance you have to search for where that implied bond came from in principle.

A

uh I guess that with type aliases, nothing really changes. It's just that you have to know to go through a type alias uh to the underlying type. um I don't know somehow it it didn't. Quite there was like a pattern match that I was having of. When do you? How do you remember when you have to write bounds and it was like in types you do. I mean functions, you don't uh it didn't, it doesn't match, but I don't. I don't know how much that's. Definitely matters.

C

There's perhaps an argument that you know that the the heuristic there see the change.

B

C

What's the right phrasing, like you know, nominal types you do, but.

A

You know yeah, that's a good point. I mean it's also true that right, like you, have to know for tuples and things those rules are kind of built.

C

C

um We have a roadmap for when further implied bounds. Work is that a separate meeting topic.

A

Well, we're about our time. I guess, but I mean it's.

A

I've sort of been thinking of it, as this is something we would do once we transition over to a more chocolate setup, because we encoded it as chocolate rules, and that might be it's taking a while there could be a way to do it. I haven't thought hard about how to do it in today's type checker, but I guess it's probably possible um I'll see why it wouldn't comfortable in.

A

A

It's really in types and traits, but that's okay.

A

A

A

There is probably some intuition there of like yeah things that are not implicitly equal to one another or distinct type; definitions as opposed to a type alias, which is not a definition. In the same.

A

A

Okay, so what about this other question? How much do we really care about this.

A

I guess I guess I can kind of show my cards. I don't know that I do I care about. I think we have a lot of problems, you know, and it just doesn't somehow. I feel like the current setup can continue and uh until like implied bounds or whatever is there and then we can think about it, and I could live with that.

C

But it seems like when you don't get another wart, that we have that at least we're honest about it in terms of we have the lint that, I think, tells you about the important case right that your bounds aren't enforced. You add them so yeah. It seems like something can wait longer if necessary.

A

And in particular I guess like do we want to land pr's that are making warnings around or errors around narrow cases uh progressively moving, but if that sort of implies, we know it seemed like progressively moving towards the naive approach. Is the easier one to do? I don't know.

B

I personally would prefer to move towards the implied bounds approach for the zero argument case, but I would like to enforce the bounds for the too few or too many case erroring in the former case and actually enforcing it in the to many case.

A

One thing I would add about the prs now that I think about it.

A

There is a this is there's another case where I think we're going to have to do something like this implied bounce approach for backwards compatibility, um which is at least I've been assuming we would, which is in function types when you have higher ranked function. Types like this today, if you have some type in here that that references this take a or whatever, let's just call it like foo of ampersand take a c or something.

A

uh We basically don't check that for well forming this at all. Until you call the function at which point, we know what tick a is, and I have been assuming we're going to change function, pointers over to a similar implied balance approach. This is what we me and scale xm thought about a while back where basically, this also is needed to close the sound. This whole side note, but basically, this function type is kind of shorthand for one. That just again is not valid syntax, but you know deal.

A

Maybe you can imagine what it means it sort of says when you call this function, you have to prove this where clause, but um but the type gets to assume it's true, and so now this function type is sort of well formed in a trivial way. uh That's basically similar what we do today right but again, rationalized- and this seems okay, but there is this examples of like what, if it doesn't matter, what tick a is the the type is never well formed.

A

You know like it's just not well formed for any reference somehow, maybe because some trait that is not implemented for any references um should we at least warn like today. We do nothing until you call it, then you get an error, but but we do give errors. I think, for cases that don't involve.

A

Bound lifetimes so, like the second argument would get an error and the first one might would not even if they're, both errors, and so what I imagine might be, the the longer term path in the would be something like technically, the type is legal, but you get a lint warning that says by the way, uh this will never like any use of this type will be an error or something like that, um in which case we could also start warning like.

A

Maybe not as a future compatibility warning, but just as a helpful hint and start saying, like these kind of cases, where the type the right-hand side of the type alias is obviously not well-formed at least issuing a warning about. It seems like.

A

I would want that, no matter what I don't want to wait until I use the type alias to find out that it's never going to be valid, um so we could start landing pr's of that kind, and then that already may help migrate people towards something at least they won't have utterly broken code out there.

C

I mean that that does sound like an improvement. Is there the fact that you're suggesting this means to me that the you're not aware of any architectural reasons, why we wouldn't be able to do this as a lens.

A

I mean, I think we can do subsets.

A

You know I I don't know what like this pr, that I showed only the case where.

C

You know we're always talking we're only talking about doing linting cases where it's certainly going to be an error. If it's used right, not something where, if there's cases where it could be used usefully and like we're graduating, we could be considered a bug for us to report a link saying this type could never be used and someone's like, but here I use it over here and it doesn't cause any error right. That would be considered a bug and wind in that case. Yes,.

A

C

A

And that's that's what this case does. That's that's an example of this may not it doesn't catch all cases, but it catches some cases where we know it's going to be an error. That just seems like full stop.

A

um I can't imagine a scenario and maybe sometime later it becomes a hard error, but you start out with just linting against these things.

C

You don't think it's there's any drive to try to make it at least right now to try to make a future compatibility warning because it's not it's not like. We need to get rid of this code in the long term and we want to actually you know, make it a hard error. I.

A

Think that yeah I mean we can make it a future compatibility warning. It's a. I don't have a strong feeling yet about whether I think about what I think I guess. The only reason I hesitate is that if this were the formal definition that we have a well-formed aware clause like this, then I don't quite understand how the compiler would sort of sorry. This would actually be.

A

There would actually be two web clauses, and the point is that I don't know how the compiler, like it's been told to assume that this is valid. So on what basis does it issue an error? You know what I mean, um so it feels like it's weird for me to be an error, but a lint can have special extra reasoning about, like I've been told to assume this is valid, but that type that I'm told to assume is valid can never be valid. So I don't know.

C

Just instinctively, it doesn't feel like an error to you, yeah, okay, but you know you could imagine the rule. This is when you're told it sounds. You know sounds like a great start and we can have long. We can debate more. You know later about whether we want to uh pump it up further.

A

I think, by the same token, like I forget what we do now, I think we have kind of weird behavior, because the compiler is not as principal as it could be, but by the same token, linting against limping against. Where causes that can never be satisfied, make sense to me, I'm not. I think today, they're actually illegal, but I think they shouldn't.

A

A

Yeah today, they're illegal, I think that's wrong. I think we even had some prs. I think we even had like an rc or pr that was trying to change that. I can't remember, but uh I think, if we went to a chocolate world, they would not be illegal, they would just work or just be saying. Okay, I'm going to assume that's true, even though it's not.

A

A

Okay, so that seems like an immediate step is we can start linting for cases where we can start yeah warning cases where we know it must be illegal and worry about the rest.

A

B

A

I guess I would say regardless it seems like the kind of thing where we probably would transition it over. In addition, anyway, a warning about a future compatibility is better to me, because I don't know yet that's the story. I want to use those sparingly like you really need to act on this.

A

All right, y'all, I'm gonna, end the meeting. Thank you.