Hello all :) welcome to the "30 min late" weekly meeting
This meeting is meant to be a bit informal so I didn't prepare an agenda in advance or anything
@dhardy you mentioned wanting to work on trait object upcast, I think that's an interesting idea: my main concern has been working on integrating chalk but actually there are a few topics that might be worth looking at which are — at least somewhat — independent
I was thinking of trait aliases too
Yes, I thought it's somewhat independent... trait objects are a different thing from traits
I'm still struggling to find my way around the compiler so haven't got anywhere
I forget, was it you that I was talking about on this topic before?
There was someone :)
Not sure but probably not. I made some comments on the linked GH issue
There are various complexities to deal with, and I had been talking to someone about drafting up an RFC
we had created this repo
but as you can see — its contents are empty :)
so evidently we didn't get too far
I think trait object upcast involves figuring out a few things — e.g., we have to talk about the runtime representation we'll be using etc — but it's probably worth looking for some easy "subproblems" to start with
Does it need an RFC? There are are some questions about how exactly vtables and upcasts work, but seems like the only questions are technical (can this be done) rather than design (what should be done)?
It's borderline perhaps, but I think an RFC would be helpful, or at minimum a design document.
We tend to skimp those and I don't like it
it also feels tied up in questions about how to handle things like
&(A + B)
(where A and B are arbitrary traits)
&dyn (A+B), I suppose
(a bit late to the party: by "trait aliases", are we talking about aliases for bounds or traits?)
Okay. I'd prefer to have some progress on an implementation before writing one but might get to that later (when I have a better idea how the internals work).
@varkor I was talking about RFC 1733
I think @Alexander Regueiro was also talking about trait object upcasting
&dyn A + B is a multi-trait object, regarding which there are quite a few comments in https://github.com/rust-lang/rfcs/issues/2035
Well, I've not given trait object upcasting a lot of thought, I have to confess, at least not recently. I think the place to start is to figure even what the problems are. =) There are some key language-level choices, though.
For example, is upcasting a kind of coercion or a subtyping operation.
subtyping meaning "no change is needed at runtime"
I suspect we will go with a coercion
but i'm not sure
that would imply that e.g.
Vec<Arc<dyn Trait>> cannot be upcast to
in any case, @eddyb and @kimundi had an early RFC about this that is worth revisiting
(My general hope was that we could approach the RFC writing and implementation in tandem, sketch out a rough plan, working on it, and revising as we go — which is actually something I'd like to move towards more generally, but that's neither here nor there)
ok, so, in the past we had this dropbox paper document for kind of tracking things
Vec<dyn Trait> to
Vec<dyn Supertrait> is in any case unsound (because it allows users to push
dyn Othersubtrait objects)
it is not unsound
we have a notion of variance already for the existing region-based subtyping
note that if you own the
Vec<dyn Trait> and you upcast it
no harm is done
because there exists no alias
that is, nobody to "remember" the old type :)
True, you have to keep an alias to the old type
if you have an
&mut Vec<dyn Trait>, that is not the case, but then we enforce invariance
&mut T <: &mut T)
&T <: &U :- T <: U)
re. tracking: it'd be good to not only have a list of the current objectives wrt chalk, but also what chalk currently supports (and doesn't), to track its overall state
(I'm still planning to tackle const generics in chalk, once I get some time, but it's not yet one of the pressing issues, for example)
I think I will remove the old table, and we'll try to sketch a new one. But I would like to have a clear roadmap showing the various "active goals" and the work towards them. @scalexm, @tmandry and I drew up some intermediate steps for Chalk integration but I think they've not made their way into this document, so perhaps that can be a goal for next time. I think @varkor that steps within chalk just fit into that general framework (they may be separate "topline" goals, in some cases — for example, I'd like to push harder on modeling specialization at the chalk level etc)
I'm not sure whether Dropbox paper is the right form for this sort of planning though
I'm going to start by moving the existing tracking somewhere else, since it's outdated, but I don't necessarily want to lose it
@nikomatsakis I want to start doing some chalk work but I'm not currently familiar with rustc or chalk. What would be something good for me to get started? Whatever can add some value to chalk would be nice.
fwiw Paper actually lets you set action items for people and "due dates" in a doc, not sure if we'd want to use that feature but it might help keep people more organized
Should we resurrect the old paper document for WG-traits?
@Sunjay Varma the paper link is here
@Sunjay Varma niko linked to it above ^
I've cleared out the existing content, but it is available in the history from what I can see
oh i see
I was finding it a bit overwhelming :)
I think maybe the main thing for this meeting that would be good is to just brainstorm a bit the topline goals and try to prioritize them a bit
@Diogo Sousa btw, I think that's the question we're aiming to answer a bit in this meeting and over the next few weeks :)
ok, I added a bit to the paper brainstorming some possible goals:
So I guess it would be useful for now to have this:
What is the current state of chalk? I mean, what are the missing pieces to have chalk fully able to check (all rust) programs?
some kind of idea of how many people are maybe interesting in doing things :)
(sorry, I don't have a lot of context yet)
I'm not 100% sure. In some sense, chalk is more complete, but it doesn't model specialization right now, nor does it have a notion of trait objects, and probably some other Rust "special cases" we'll have to decide how to handle.
You have to have a full picture of how it fits together: chalk is really a shorthand that refers in some sense to a lot of things
e.g., there is an underlying chalk-engine crate, and it is basically complete, but it relies on some front-end lowering Rust traits + impls into the form it expects
the chalk crate itself is not something rustc will ever directly depend on
it's kind of an elaborate unit testing harness that demonstates how trait lowering can work
(maybe eventually we'll be able to pull some of that code into common crates shared with rustc, though, but it's not an immediate goal)
there is some stuff written up in the rustc-guide under the "trait-solving (new style)" chapter
that may help to "set the scene"
Preliminary chalk integration
- Goal: to type-check a very simple program using chalk
I am interested in working (at least in some small part) on this. It's one of the things I wished I had gotten to a few months ago :smile:
so in terms of completing chalk, what we are kind of talking about is extending that unit testing harness to figure out how to lower more things
Well, I'm here and interested in doing things. You may or may not have seen this, but: I have some experience with Rust and limited experience with rustc. I'm hoping to get involved here as a way to learn more and help out, though. :)
@Diogo Sousa I put some links at the top of the document that are helpful for context
I'm thinking a bit more; I think probably the thing to do is to try to move some of this "overall plan" state into GH in the form of issues and labels. I've found that ultimately that's the most effective way to drive things.
@nikomatsakis basically the most important things when it comes to completing chalk are trait objects and type outlive requirements
I see. I will try to explore the current state of things this week. Thanks @nikomatsakis!
Right now I have an airplane to catch, but after that I will read the rest of the topic.
thanks @Sunjay Varma, I will look into those.
(I think specialization and const generics might wait a bit)
Can those of you who are attending add some info to this section of the minutes?
@scalexm what do you mean by "type outlive requirements"?
I don't feel like that is chalk's job
so i'm not 100% sure if I know what you mean
or do you mean just "Adding that as a kind of domain goal"?
mmh I think we need some "implied" outlive requirements in chalk no?
or maybe not
I'm not sure now
because we are no longer "elaborating" the type context but moving over to implied bounds?
I guess the answer is "maybe", I think we can probably avoid it to start, it's certainly (imo) not needed to get our first program working
like, I remember translating
StreamingIterator to chalk there: https://gist.github.com/scalexm/e3e4ecefe970a2df861cc158e50c363c
but I would like to talk over how to handle outlives at some point and how to model it in a better way. This is somewhat tied in with NLL + polonius etc though.
and I needed to hack in an implied outlive requirement in order to model it well
right, I guess I am basically thinking that we can add some kind of
T: 'a thing to chalk, but it basically just gets propagated back up and left for rustc to handle
(Niko - this is Josh. I've been to the Kendall square Rust lunch a few times, and we talked about getting involved, and you suggested poking at a working group. So here we are. :)
(which is what the trait solver does today)
@nikomatsakis yeah ok so just add
T: 'a goal basically then
I'm debating how to proceed :) I think what I want to do is to try and move these "top-line goal" ideas into github, opening up various issues and using labels etc to track. I've found ultimately it's best to lean on GH for these sorts of things. I don't think I want to do that synchronously right here, but it'd be good to grab a smaller group and do it live in the next day or two. Then we can try to advertise those work items and people can sign up
and we can 'check in' on progress next Monday as well as revisiting the overall structure?
works for me
maybe we should pick a time for that
I guess I would probably aim to do more of that planning tomorrow at 10am EST (but as I said I don't think it's something where a ton of people need to be present)
in particular, I think it only makes sense if you already have a pretty good grasp of rustc + chalk etc...
I can make it then
I can make it
great, let's reconvene then, and once we've got some issues chopped up we can post them to zulip/internals ?
sorry for being 30 min late today again btw :) though actually I think we should shoot to keep these meetings 30min if at all possible
I'm all about the 30min meeting these days :)
sounds good :wave:
that sounds great to me. i'm mostly going to sit back and see what sorts of things you come up with and see if there's tasklets that'd be a good way for me to get started. so I suppose I'll just return next Monday!
@varkor I have been yes. Haven't gotten around to writing up a document still, but there's a repo for an RFC there. Needs some brainstorming.
@nikomatsakis could you create a calendar event for this meeting like the NLL group?
I have one, I can add people to it as needed (I'll add you, @davidtwco)
hello @Sunjay Varma , I started this topic