Rust Programming Language Language Design Team, 4 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: 2020-11-04 Lang team design meeting: RFC 2580 and Custom DST

Description

Minutes and notes:

https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2020-11-04-RFC-2580-and-custom-dst.md

A

Oh, this is a design meeting to cover the rfc 25 um there's the hackmd.

A

I can hear it if people want, or we can just all open it uh he's playing with me and the idea was, I thought we would walk over what's in the arts and then some of the various proposals uh just and kind of discuss those details and see if there are any problems and also like what we want to do going for um in this area, I mean more generally like the rfc is all about custom dst or the area I'm referring to.

A

I guess is cost custom, dynamically sized types and the various extensions that have been proposed around them, of which there are many that seem like a good agenda, any additions or changes to it.

A

Okay, does everybody have the hack md? I will throw it in the chat. I'm gonna go ahead and not because I don't know sometimes that's weird.

B

A

Okay, what's in the rc simone, you want me to talk, or do you want to talk your.

B

B

C

D

Yeah sorry uh zoom is being very slow as well. I'm gonna try it with the yl.

D

A

A

B

I guess we'll just wait.

A

And keep going, but if someone nothing someone doesn't know, uh I mean the core idea. Is that it's defining this trait, uh which it calls pointy?

A

I think I think in the past I propose the name reference which I like better but anyway, uh but it's something that can be pointed at by a pointer and it would be implemented for all types, since all types can have pointers to them at least today, and the main thing that that trait does is carry the metadata as an associated type and the metadata has to be all these things copy send sync whatever.

A

So the idea is, if you have an ampersand t, it is a that pointer that is paired with a t, colon colon metadata, which could be unit, asymmetry, working.

D

Better! Yes, much better sorry about the delay.

A

Okay, I was just saying that talking about the pointy type and thin yes, pointy with metadata of.

D

Unity yeah, so the idea is that um every type would implement this tray it straights automatically, and the purpose of the trait is to have the associated type for the pointer metadata.

A

And then there's some functions for manipulating it right, like the ability to extract.

D

The data so for slice, for example, we have from raw parts where it detects a data pointer on the length, and the idea is to generalize this to all pointers.

D

Possibly dynamically sized.

A

So for slice we have that method, but this would add, like a generic one for all right that just works, so there's a from raw parts for every raw pointer type. Yes, um it takes a unit pointer and a metadata and creates basically builds a fat pointer.

D

Yes, so similar to how slice have formal pattern from about mute. Similarly, for const pointers and mute pointers.

A

And what else can we do with this? So the other thing that's pretty relevant is the din metadata struct.

D

Right, so that's the one case: trade objects where the metadata is not something that already exists in the tank system, so we want to represent it as a type.

D

That's pointer, sized and uh minimally doesn't do anything else, except you can obtain it and form a um straight objects and then recreate the white pointer from it. On the data pointer and optionally. We can have other features on this type like accessing size of.

A

Yeah and that's that's paired with the ability to permit I'm just looking at this last line, which I haven't thought that hard about so right now, when you want to build a trade object, you have to build it from a size, type and you're saying you would change it to any thin type.

D

So originally to actually create create a trade object. You would entice it from a size type. Yes and.

D

Now a library would have the ability to separate the components of that white pointer and then recreate it later, except from separate components.

D

So the only way to obtain a vital pointer would be from a trade object, an existing one.

A

Right yeah, so you could use this to the get metadata, get out, v table um or din metadata and then put them back together, yep, um but be going past that so in my summary, I have like these two bullets at the bottom, which are basically moving from places where we have used sized to using this thin trait instead, so changing the bounds on null from size to thin and also changing the rules around casting to din values, din types.

D

Yeah right, so the the thin bound uh is something that now we that we have pointer meter that are in the type system with the traits you.

C

D

Express the constraints, this type is size. uh Sorry, this pointer is thin, even if it's, if the type is not sized, so that makes a difference for excellent types.

A

This is good for null, but it has a funny behavior for din. I mean, I guess it's no stranger than extern types generally, but like right now, if you have an ampersand in foo, for example, we can we can find the size and alignment dynamically, but if you had coerced it from something that is not sized, you wouldn't be able to do that right like right now. The v table encodes the size and alignment.

A

So I'm trying to say but right if you go from thin type, but the main difference between a thin and a size is that you don't know the size or alignment, nothing.

E

Well, you can know under certain circumstances, I mean for c string. For example, we would know.

A

But the I don't believe the rrc adds anything that allows no.

E

No, no, it doesn't but like in general, um this doesn't apply to all thin unsized types.

E

D

A

You're talking.

D

About going from a thin type to a trade object, and yes, the only way to do that is uh for incising through it's through and sizing uh a type that implements a trait to dean of the traits. That already the case today and that doesn't change with zero fc, and it's that incising operation that creates the table.

A

Yes, but the v table can't be created, it's kind of my point: unless the type is sized.

D

At least the v table today contains.

A

D

This rfc doesn't change anything there.

A

Maybe I have the wrong notes in my notes. It says that it does it's a minor point. I think we should move on.

D

So wait, which part of the notes was that.

A

uh The final bullet says: permit pointer, casts from ampersand t to and in foo, if t is thin, plus foo.

A

But I really sort of regret spending this much time on it, so I want to move on okay. This is a minor point. um The main thing is right: okay, so you have a trait that describes metadata and the ability to take apart and put together uh fat pointers.

A

So I guess, does anybody else have any questions about what the rfc says so far I've been asking a lot.

A

Okay, so what are some of the assumptions? These are some that I came up with things that like because the question is, what are we locking ourselves into so to speak? uh One of them is that all metadata has to be copied, along with send sync word: hash, unpin and static. That would be.

F

A

To be otherwise about that.

D

Someone mentioned in the rc3 that, because raw pointers exist today, and they are harsh and comparable and all of that then, because they continue to data, then the meter should be all of that as well, and there was discussion about the bounds in the associated type definition.

D

um When implementing this, I I have a branch where I implemented the pointy trait, so I copied the definition from the rfc with the constraints, and then I didn't actually implement straight for tin, metadata and still worked out because the it's a special case in the compiler so probably like, I would be able to trigger some compiler or even internal compilers, but anyway. My point is the metadata type that you can extract with. A public api is not literally a struct field inside raw pointers.

D

It's only the wrapper that you get so even if raw pointers can be compared, it doesn't mean that steam metadata has to implement the partial liquid uh trade and hash trade, and all of that maybe we want to anyway, but it's not as hard a constraint as we thought in.

A

I'm not sure I understand so you're saying it may not have to because.

A

We could make some conversion into something like when we're happy when we implement cash.

A

I didn't really understand that so.

F

I think I think I understand that it's um like, I think something similar is assuming that users cannot implement point e right, which some extension rfcs on this do propose, but if they can't then the type that is the metadata type isn't necessarily it's not the actual v table necessarily right. It's like some center library type that is wrapped around the uh v table of the compiler variants yeah, and so because of that it, the fact that the uh v table type doesn't implement.

F

Hash doesn't mean that the player is implemented because the pointer just hashes the actual address of the v table. It doesn't.

A

F

But it would be, this is only as so long as users cannot implement point e, which is where it gets more like, which is, I think, where these bounds actually matter right is, if we allow users to import them,.

D

Yeah, so it is an assumption of this rfc that pointy trade is implemented for all types and you don't need a bound on generic code to use it right.

A

Yeah, one thing that that does point out is that you can't add more bounds later.

D

So because it's already implemented for all types, you can't have manual impulse of these traits.

D

And how that interacts with a future rfc for custom dst, where you would want the trade to be implemented manually? I don't know.

A

You could permit manual impulses as long as they're inherent like as long as they're in the same crate, and we could have some special rules. Okay, all right. I think we'd have to switch to a little bit, obviously very special, so that would be expected.

G

um Okay, I'm trying to understand the uh the outcome of this.

H

I think, given the level of interest, I think it's worth exploring that further.

A

Yeah, I was going to turn to some of that, but sorry felix gone. Oh.

G

I I wanted to try to summarize the outcome of this discussion regarding this. Is all this started with a discussion about the bounds on the metadata associated type right and I'm trying to understand the outcome in terms of whether simon is saying we can remove a lot of these bounds because they in turn they are, aren't actually necessary for the use cases under interest, or is the idea that, since we can't add the bounds later, we in fact want to be conservative and not as many as possible.

G

I I just want to make sure I understand what decision, if any is coming out of this.

D

um So in rfc the argument was because raw pointers already implement all of those traits. Then the components of group hunter must implement hash and all of that as well- and what I found is that's not the case.

D

You can have ash for pointers that, like the current implementation, just transmutes the white pointer to a tuple of view, size and hashes that.

G

Yeah, I guess them yeah I'd, be curious to know what bounds are actually needed are expected to be needed in practice and try to narrow down to just that, just to keep our options open.

D

G

uh I'm still trying to digest this.

D

So so the places where those bonds are useful is generic code that manipulates metadata of any type so that generic probably wants the metadata to be copied because it's convenient, or at least clone.

D

And then we can discuss whether it's useful or meaningful to compare metadata or hash it, etc.

E

Can we also hunt on these decisions because it's not a breaking change to like enforce that they have it later, because we are not allowing any custom metadata yet right, yeah yeah, I.

D

A

A

But or at least to remove that, um but I think we want those bounds, I mean if you look at the impul, I think the argument, the rfc is basically correct, like existing impul hashes, the metadata.

A

Oh, we do want to be able to do that.

C

D

Yeah we can change the standard library to uh use transmute less and instead use the new function to access metadata.

A

Right, I think that's what we would. I would assume you'd rewrite this impul to not use transmute, but instead call the metadata free function and hash that.

D

Yeah- and in that case it's useful to have the.

G

I guess my most immediate reaction is to this question of copy and static about whether there's potential future scenarios, in particular with dynamic library loading where you'd want the v tables to actually be things that aren't dynamic, labor loading and unloading. I know it's not something that we support today. I don't think any real, proper sense, um but it doesn't mean I don't want. I don't I. I still see that I think about the back of my head, but hashing seems fine.

D

um If I remember correctly, there's already a behavior, that's arguably a bug where.

D

The same combination of type and traits can have multiple vitamins if they are compiled separately and in some sense they are the same table. But the pointers will compare not equal.

A

Yeah, that's probably true, um I think we maybe uh anyway, that's let's not get down that road um all right. Well, we can so. This is a thing to investigate.

A

Let's go look at some of the um like other stuff that might come down the line and how this would be compatible or not compatible with it. um I think the tick static brown is definitely interesting. That also applies to function. Pointers like this whole dynamic loading thing so be nice to have function, pointers with a lifetime bound, but anyway, um so ollie made a big list of proposals.

A

We can walk through a little bit, some of which have more details below. I want to start with this first one of trait objects and multi-trade objects, because it's something I expect us to want to implement relatively soon um and or I would love it if we did.

A

uh I have some notes in the section called din, foo plus bar that's down below, but basically the the summary of this is that, according to the rfc there's- and there is an unresolved question about this- but there's din metadata- that is basically a v table and it's a single pointer and so that that works for all of our existing traded objects.

A

And I don't think, there's any interaction with trade object up casting in particular, but we have discussed different representations for multi-trade objects like din, fu, plus bar and one of the things that that they could be represented as multiplicative, and the advantage of that would be if you have like 10 a plus b plus c, and you want to upcast it in a plus c. You can just drop the bv table.

A

Basically, uh however, the disadvantage is that your pointer is really big, and so the advantage is that it's really easy to get all the possible like subsets that you could want the disadvantage. Is your pointer is really big and maybe it's better to?

A

Maybe we don't expect there to be really long lists of traits and it would be better to uh just always have a single v table.

A

You have to generate, like all the combinations of possible sub v tables, but the problem is, if you, if you have only a single v table a pointer and you have a p plus c and you have to be ready for that to be up cast to either a plus b or b, plus c or a plus c, like all the combinations, and you can't sort of know ahead of time, which ones will be actually used, so you sort of have to and you can't generate them dynamically, you kind of have to generate them all.

D

The number of subsets is exponential.

A

Yes, that's not fun.

D

So that's not great, but if the total number is small, maybe that's not really a problem right exactly it's.

A

Being recommend.

D

To have dozens of trades, maybe.

A

Right, yeah you'd think it's uncommon and if you I don't know right, you'd think so.

I

So long as it's not numb traits with 17 different pounds,.

A

It only matters which ones you actually put in the din. I guess.

D

A

um Well, it'll be also for upcasting.

A

If you combine that with up casting- and you have a trait foo with like a whole bunch of super traits- and it has to be upcastable to any subset of them, it could be a lot of e-tables.

D

So personally, I think the very big counters are not very good, not good, so I would prefer a solution where we keep the a single table pointer and maybe have.

D

Some other vitamins reachable from there, but either way if we change the metadata to be parameterized over the din trait type.

D

Then, in that case the very white pointer should still be possible.

A

Yeah, so I don't know if everyone saw that, maybe I'll add a little note about it, I'm adding into the doc above proposals and compatibility notes.

A

People see this part of the rfc, so there was a proposed extension to instead of having din metadata, be just a simple type. It should be parameterized, so that- and I guess it would be a question mark sorry so that you have liked in metadata.

A

Instead of just- and that gives us the ability to change its size and representation as we wish, but the downside is you can't just talk about a v table in the generic case anymore, you have to talk about a v table for this din type.

D

And maybe that's a good thing, because that means you can't mix up visible pointers for different traits accidentally.

H

You wouldn't necessarily have to indirect it.

A

H

I didn't understand that if you know exactly what type you're talking about and what its v table is, then it's no longer necessarily a dynamically sized type.

A

But you don't know what type the v table is for you just know what trait it is.

I

This would be like generics.

A

Like what you know.

I

With so you'd we'd need a form of like trait generics or no no, it's the object, type that you can put into the.

D

I

Yeah, okay, cool!

I

I guess that's easier.

A

I

Trade generics.

A

Yes, I think it wouldn't. It would just not make sense to have like a dim metadata of u32 or something you probably have to figure out. What happens if you do it, but you couldn't get an instance.

D

I think it's a type you can name, but uh you can't get the value of it.

A

Right, the compiler will have to deal with it sometimes.

C

And the alternative to having it bound on a trade is to store something like uh enum right instead like we could potentially have multiple versions of it that the compiler generates and like a discriminant or something or is that precluded for some reason.

A

You could I mean the main thing would be that the size and alignment of the data will potentially change over time. I guess so. Maybe that's fine to say this is repper rust. You can't rely on it being a single word or something.

A

um Yeah, I don't know I'm kind of of no. This seems like a good. I think the unresolved question was the right way to handle this situation like we should experiment a little bit and we can worry about it when we have to stabilize, but I am kind of curious what use cases the didn't. Parameterize version of din metadata helps and which one's harder.

G

So, actually, I was curious, the usage of din metadata in practice with the rfc. You have to already specify that you're getting out a um the metadata and specify that the metadata associated type is did metadata in order. If it's useful right, there's there's no other way to actually get the metadata out and be able to manipulate it without specifying that.

G

So so it seems to me, like this choice is already sort of parametric right in that we, if we decide to change their position later, uh we'll stop compiling if they, if they've you know committed to this, which may be bad or maybe good, but it opens up on sorry.

A

I think I think another thing that I forgot, I wanted to say is actually we could just have din metadata, it could be a single word, but because we don't have a type like din, foo plus bar. Yet we don't know what its metadata type is right. Maybe it's not did metadata. Maybe it's din metadata too, or something.

F

A

Yep, oh that's an interesting point.

F

Like we have a type for things that are very adequate number, the same type.

H

It would be unfortunate if at this point, we're committing to that is the only possible representation for the metadata of multiple of a dynamic of multiple traits. But it certainly is an.

H

A

The point is: we're not actually committed very much but yeah.

C

C

Am I correct that the representation of the din metadata doesn't actually have to match the pointer representation like we could potentially have complicated logic to pull out and sort of make a user visible, struct and then repack it back into the pointer.

A

That is true, awesome.

C

Not saying like we want to, but it it this was.

A

Basically, similar.

B

F

I think users will expect it to be like a wrapper, transparent structure on the the address of the v table because, like this is a lot of unsafe code, so we'll probably need to make pretty clear guarantees about.

D

So the implementation of the metadata function is basically transmute, so I would not expect that function to have a lot of logic.

D

It could in theory, but I don't know.

A

So josh asked some questions there. I don't know, I don't know if you meant those for sink or async.

A

um I'd like to go on to talk about some of the more extensions, though the question dodge asked was basically do these live in student core? What traits do we guarantee that did metadata will have? um I think I think the answer would be the same like on the simone answer, but same as metadata right, but it can probably grow more, unlike manufacturing.

F

And we'll have inherent methods for getting the size in the line of the.

F

I feel like the like safe thing to do is to focus on denman data and thin and leave like pointy as in implementation detail in the initial, like the mvp that is like, like currently unstable, uh to avoid having to worry about these questions around what. If we want users to give the implement point e and what types of bonds do we require, and so.

F

On like, for example, it was a bit concerning that you know it has to implement on pin, because that pin was obviously added long after the other traits in that list and what, if someday? We want to add another trait like that, but we can't now and so on.

A

Yeah, you should.

D

So I think the adding a new bound to the associated type is fine, because a custom implementation of that trade does not allow.

A

I think it's it's okay, I think it's okay, so long as we don't allow custom implementations yeah brand we improve there is. There is one uh scenario where it could be a problem with the current rules. We have around the performance but actually implied bounds within some of that, but potentially like. If you're writing generic code- and you say I have some type t that has a metadata of you right now- you have to give the right bounds to you for it to be, and so we couldn't change that set without breaking generic code.

A

But if we um implied bounds, if we in some versions of implied bonds, we talked about in like some of the ones that chocolate would mean. That's not true. You actually get by virtue of saying that you get to assume that you meets all the bounds, so you can actually add more nouns without breaking people, um but so there's some interaction there.

A

Making pointy unstable to start is reasonable, but.

D

I'm not a fan of keeping the trade unstable if it's part of the signature of uh stable apis like the metallic function.

A

It was, it would significantly reduce the amount to write generic code.

F

Yeah, you would get a little bit generic over, but I think it's a good point that well, if we deal with this um this example about what formerness, then it isn't really a risk until we want to deal with people, including their own types capability, special dst's, which is definitely out of the mvp anyway. So.

A

Yeah, I'm going to add these notes up to the point where I brought this topic up about wanting further balance.

A

So the point is, until you have custom impulse, this isn't as big a concern um except for well-formed in this.

B

Bounds might change okay,.

A

So in terms of the extensions we went over trade objects, uh it seems like we can jump right to implementing the the main. The main one is implementing unsized for yourself right, sort of custom dst, um and I don't know how much detail we'll be able to go into. But we can talk a little bit about what that would look like uh there's a section on it in the hackmd. It says: custom, dst, rfc, 1524 and rfc 2594..

A

It doesn't have a lot of detail but, and then I've since looked at some other rfcs and they all kind of feel quite similar, I'm sure they're different in various ways where, basically, you can imagine that you have some some struct somehow and you can implement uh and specify what its metadata looks like and that metadata has to implement various traits that the compiler can use to figure out size and alignment and that sort of thing.

A

A

I don't know not sure what else is worth going into about it like you know, I think it does work fairly smoothly. um What's in this.

B

A

I guess one point that is comes up: a lot is the exact hierarchy of how much size and alignment information you get.

A

At each point, but points pointy is usually just none uh right and then there's like different sort of like an extern type. You don't get any guarantees that you can even ask what the size and layman are even.

A

E

I think one main question here is like how much control about that we should give to users like, um for example, for for extern types. Should it be possible for some um types to specify a way to compute the alignment and so on, and what how do we figure out? How that there's, no alignment to be computed like how do we expose this fact that it's not possible.

A

Yeah we've been around and around on this, do we do it statically or do we.

A

Panic, it's a pain either. It's very appealing, it's the problem, but it's kind of not this particular rfc sidesteps those problems. I think.

D

Yes, it was very intentional to not block on answering a bunch of questions around custom, dst and.

D

F

I think it's also the thing about like c string where, like its size, would not be contained in its melody. If it worked the way it wasn't seen.

A

C string is a good thought experiment. I mean.

D

It's kind of an extern.

A

You can compute its size, but it's not obvious to me that dies of vowel should be on yeah. That's true,.

B

A

I guess I would say that extern types and custom dst- I guess ali wrote this in the document like extern types- are kind of one extreme version of custom pst or something like, especially if they gain the ability to specify their own size and alignment and then they're really exciting. On the same ground.

B

A

But the main thing about custom dst is, I mean essentially, if you allow people to write their own pointe, then you can write methods. I like the matrix example or something right, but then you can kind of use the methods in this rfc to to really do useful stuff.

A

I don't know what exactly this would look like, but whatever, um if you imagine, you had a two-dimensional slice that has probably not you ate, probably used size uh as multiple indices, um whatever.

A

And that's pretty cool, no.

F

F

It also occurred to me that if we ever did have another thing like unpin, uh it just would be that it would have to be we're like wherever we currently. I think we require on pin, because box supplements on pin like reverences, implement nothing regardless of t's found, but that would just have to say, like it would be like influence on pin where t clone called metadata implements on, pin like we have to put the bound where we're currently relying on the assumption, rather than having the assumption.

A

That we may not, oh, I see it yeah, so that works. If that works. For a case like on pin, um I.

F

Think it works. A lot of these were like none of them are like the link. Well, definitely anything that we're gonna add in the future. I think we could design where we created. This functionality only works with types whose metadata implement the new autocrate or whatever we have created. That would be required.

I

Yeah, even something like hash seems reasonable to say well yeah. If you pointers are only hash if the metadata is hash and all of the existing metadata is hatched, so it's backwards compatible.

D

But the trade solver doesn't know that.

F

Like it would even be backwards compatible if they like, we were adding hash language now, even if all the existing metadata is not everyone hash, then this feature just would not be usable with any existing types which would be unfortunate, but like it wouldn't be it's a new feature, so it's not backwards and compatible.

H

Does removing does requiring the metadata to be unpin break any of the stunts people might wish to pull with uh how they efficiently store their metadata, together with the pointer, for instance, if you had an aligned pointer and only two or three bits of metadata, if you wanted to store it in the low bits of the pointer, could you get away with that kind of.

F

Thing, I don't know if you can get away with that, but I don't unpin does not keep you from getting away with it. I think the other limitations are going to be a bigger problem like how you're going.

E

F

Do an actual address and stuff.

E

I addressed this a little bit in um in the procedural v tables rfc and came to the conclusion that we'll need runtime code for things like unsizing and even just accessing the base pointer, because you'll need to extract the correct bits and so on, and this means like really simple operations like well. An unsizing operation could now do arbitrary logic at runtime, uh which might be very, very surprising to users.

H

E

Think about that logic may.

H

Be as simple as mask out the low bids.

E

It might be, but people could also write like enormous code when you're just making a method call, but maybe that's not an issue. Maybe we can just allow that and ignore it. I.

F

Think they already should like draft and stuff, which I think is like. Actually, if you want to do this, you probably should just use a custom strike that implements draft to your the real type. Yes,.

A

Are there any other extensions worth digging into like procedural v tables we're kind of running out of time anyway,.

E

No, we can ignore procedurally tables those are compatible with everything else.

A

Seem, like you know the other ones in the list custom. So going down the list, we had trade objects, custom, wire, pointer, layouts, not really sure what that is, but I think it's kind of custom tst.

A

Custom v table layout- that's that's totally orthogonal from this, since this is only saying that we have a pointer, but not what's at the what the pointer points at um extern types we kind of covered kind of orthogonal from this, except for the use of null um custom metadata. The.

A

One thing I would point out: in general, I think there has been some other proposals somewhere on the line that said, allowing a trait to define what its v table looks like or there was this stable v table rfc. That was another one and I think that's all.

A

That's kind of either if it's just changing what the v table looks like it's fine, if it's even changing what the metadata of a din foo trait looks like.

A

I don't know that we'd ever do that, but that's the sort of we already kind of went over that with din foo plus bar, like we have ways plenty of ways to address this idea. If we need to where um we're really committing to, is that all existing then types have this thin metadata that we defined um and that combining multi-trait objects and custom metadata?

A

I think that's, maybe what I just talked about uh kind of except more complicated, because this is more than one trade, all the more reason not to ever support that feature, um and then there was finally noxus rfc around pointy and dim sized, which I think is just an extension of this rsd, essentially to add, try and address statically the extern types question by adding a new default question mark bound, didn't sized, which I think we kind of rejected the last time.

A

We talked about this uh if I recall, because it seemed horrible, or at least like a very likely ergonomic and confusing situation.

F

It's also breaking, and I think that yeah it's actually fun to like try to implement it and found it to be breaking like it broke the compiler immediately. So.

A

Yeah, I think, adding new question about everything is very subtle. It's not not just happen, usually careful attention.

A

Especially around traits, but any case, I don't think it conflicts with this artsy.

A

So there you have it.

A

I guess two questions to leave ourselves with. I would be inclined to merge the rc, but people can think about that. I don't want to make that decision in the meeting or I'd be curious if anyone has any strong objections, but also how much we you know how open we are to other extensions like custom, dst and so forth, I am somewhat unopen.

A

I would much rather prefer I would. I would encourage people to write or design.

A

And log it for the future, because it seems like a major design- that's pretty hard for us right now.

D

My personal feeling is that any famous custom dsc.

D

Spends a lot of complexity, budget for the language, and I would not be surprised if ross never ends up with custom dst.

D

So I try to be a good citizen with this rfc and not prevent any future proposals, but I'm not counting on them happening either.

F

Yeah I feel like, like this rc, provides a pretty good uh stepping stone in that it seems very obvious how a custom tsd would look thanks to this rfc right. It would just be being able to manually implement point e, but I don't think that we would, I think, the other side of it, the figuring the uh traits that the metadata has to implement to be allowed there, so the compiler can get size line and so on.

F

That's where it's actually like a lot more complicated work and that's what we don't want to take on right now.

D

Right, I think there is a lot more to the design of custom dsc than just implementing custom implementation of these trades, and my view is that this rfc is not a new feature, but rather finishing a missing piece of existing dhc.

A

Yeah it's. I was just going to say that, even in the absence of custom dsd, I think his rfc adds a lot of value and kind of always thought we would end up with these apis, but somewhere along the line, we never did for manipulating, not pointers.

E

Also, basically, every rfc and these.

A

The list we have in hackmd.

E

Does introduce some kind of this trait um so or some some methods to to extract the parts? So it's like everyone wants this, no matter which uh um destination rfc, we're looking at.

A

So josh is raising various points in the chat that I think would be good to log, but seem I totally agree with them. uh I mean they're like but they're relatively minor. You agree, josh.

H

Yeah to be clear, none of these are things that make me want to reject the rfc. These are things that make me want to uh make sure the rfc is exactly what we want before accepting it so like on balance, I think that this is good and should move forward. I want to make sure that static is the is a bound we want to commit to and that the pointer type here is the correct, pointer type. We want to commit to that kind of thing.

A

Logging, these in the dock.

A

I think yeah on the point of clone, so felix pointed out that it'd be not. Maybe it would be better to have meta be cloned, but I think that that is just not possible because ent has to be copy and and t carries a metadata as part of it.

C

So it doesn't have to be copyright like a future. All just because all current metadata is copied doesn't mean that the trade itself needs to require it right because, like we could condition.

H

C

Bound on nt to require that the trade is uh like, the metadata is copy.

D

Yeah today, you can write a record that copies references or pointers.

A

Exactly you know, you would be that's kind of the same as din size like you would be redefining. What t colon question mark size means to mean t with point d, whose metadata is talking.

G

Or something perfect.

A

And I don't think, there's the real you well, I'm sure there are use cases but we're making it not copy. But uh oh well.

D

And same with the thick static bounds, if the middle has a lifetime parameter, that means uh raw pointers need to have a lifetime parameter as well. What would that look like.

A

That's a little bit: that's a little subtler because you don't darkon's t is not tick static for all t t has to be take static, but it is we you're right that it's connected like we have. I don't know if we can actually express the connection like we would be able to say something like the metadata is static. If.

A

That's actually not no way. I sort of take that back. We already have that. That's a rule. We already require that if you, I think yes, if, um because of the way our well forming this rules, work and rfc 10, 14 or whatever it was. If, if you have t colon colon foo, if you know the t is tick static, you know the t cone calling foo is tic static.

A

That's that's just like a basic structure that the language guarantees you um and so, as a result, we don't need to say the.

C

A

In order to know that ampersand t or sorry that star const t is stick static and t is dictating because g colon called metadata must be tick-static um that make.

A

A

I

I

So this is, if I'm trying to rephrase that, if the because the only way you can get the metadata is by having an instance, then metadata lifetime could be tied to the instance lifetime.

A

Oh, it's not really about the instance. It's about the type, so we basically have a rule that we try to guarantee is that for any associated type t column, colon foo or the more generic with more type parameters. You know the t colon calling foo outlives the lifetime tick a if all the inputs outlived together. There are t outlets.

A

Today, then t cone, colon foo must now live today as well, um and that's you can still think of this, as if you had to write an impul that specified the value of foo you'd have to name the lifetime in that impul. You know you have to like impulfu for some type, t or sorry infiltrate. Let's call it iterator employer type item.

A

What lifetime can I actually write here? I can only write lifetimes that appear inside of t. I can't just make one up out of nothing or I can write take static, but that's that's okay, that outlives all things.

A

um So that's why so, if I have like like, I could write to k, but if I write today it has to be coming from an input somewhere and that's partly because we don't allow like, if you try to write this simple you'll, get this obscure error saying that tick, a is not constrained by the input types.

A

um That's the reason we have that rule in the first place. That makes sense.

A

Maybe you weren't, seeing what I'm typing actually occurs to me since I'm not showing my screen.

G

A

Trying to understand.

G

The counter example here, though, or that example you're, giving I don't understand if you're still talking about a dying iterator returning getting the assisted type off of the dying iterate or the right or not. My misunderstanding. The connection here like there can still be a ticket under the hood.

A

No well, if you don't have a ticket in the input types, you can't write: okay in the associated type definition, but.

G

Okay, but you can have types that have decay in them.

A

So what so all we want to say, but that's that's not what we need to prove. We need to prove that star, con's t where t is tick static is also like. We need to prove that b tick static implies start, we should take this offline starch on st is stick static, and I'm saying we can prove that to be true without the stick static bound on metadata.

G

Oh okay, you're just making an argument why we don't need a bound? Sorry, okay, that's that's fine! Okay,.

A

D

What, if g, is not aesthetic.

A

But if t is not tick static then this doesn't then it's already true that star quantity is not tick static. Right, like.

D

I mean I can get the metadata of a pointer and then drop the pointer.

D

The voltage doesn't prevent that.

A

Yeah, it will actually.

G

B

Simon simon.

G

Are you asking like there are cases you can imagine where you'd want to still then ensure that the table thing is is stick static? There.

D

I don't know, I'm not sure.

A

D

A

It I think, if you, if you wrote some, I think, you're saying what if I have like generic code and I do like let meta data, so I really have to go, but let's take this offline but I'll finish this example and I write like let m equals, or it's hard to make. This example make sense, but something like this such that as a borrow, that's part of this.

D

Yes, that's what I had in.

A

Mind yeah, and then you do this this will. This will not work because m's type will include either. We can resolve this to a specific metadata type and we know if it has tk or not, or it's going to be something like.

A

Like this, and in order for that type to be valid all the way down to here to the point where it's dropped- tick a would have to be extended down to that point, which means that the loan will cover this drop. Okay,.

A

A

All right thanks everybody. uh On the basis of this meeting, you tend to move to merge um and we'll see where it goes from there. Thank.

I