Hello, world! 
We’re trying to get this traits working group going full steam, and this thread is a place for us to note down the results from our meetings. Our meetings are typically held on Zulip and you can find them scheduled under the compiler-team meeting calendar. Come join us!
The goal of the meeting was to try and figure out, in somewhat more detail, how we want to organize the traits working group itself. We’ve been doing work on enumerating and triaging the set of things we hope to do, but in this meeting we were basically trying to come up with some concrete next steps.
Ultimately we identified the following next steps:
type Foo = impl Bar (centril)In general, we’re trying to get a sense for what the initial set of active ‘subprojects’ will be (basically, the things that the WG is focusing on). Ideally, each of them will have a distinct “lead” (or, better, leads!) who is driving the effort (in collaboration with the rest of us).
A likely set of initial subprojects will contain:
but that is not certain. A key drive is both the set of people we have involved and also what seems to be highest priority in terms of unblocking other things within Rust.
We followed up on the goals from last time.
We
discussed
how we found a way to resolve the async fn complications by changing
the async fn desugaring, and hence don’t need any deep trait
action. We are still
interested
in trying to find a way to solve the “captures problem” for impl
Trait, however, and alexreg and nikomatsakis may do some follow-up
there.
Some investigation occurred. Current plan to continue documenting the way that the current normalization code plays out and to hold some sort of meeting to document that and walk through it. That meeting will hopefully happen this week and will be recorded.
Not a lot of progress here. (Yet!)
Once we do make progress, though, the logical next step is probably to try and model those use cases some in Chalk, as well as to investigate more deeply how rustc could be extended to handle the cases natively (without blocking on full chalk integration).
We have a meeting scheduled for tomorrow with the RLS 2.0 folks, planning to talk about how the type checker is working in that context.
We are thinking that integrating Chalk first into the RLS 2.0 project may be a better idea than starting with rustc, particularly as it can help get RLS 2.0 to a “working product” faster, but also because we may be able to use that to pursue the idea of sharing more code between chalk + compiler than we could readily do with rustc. Specifically, we should be able to have:
We also talked about other possible work on chalk, in particular the
idea of chalk-specific refactorings but also building a benchmarking
harness
for the chalk-engine crate.
There are a few other things we talked about this week:
async fn in traits without full GAT supportWe settled on the following plans for the coming week:
So plans for this week are:
We followed up on the goals from last time.
Last week, nikomatsakis did more investigation, taking notes in this
dropbox paper document. In general, it's still not entirely
clear if the "cycle" that gives rise to the need for lazy
normalization is something we can easily circumvent. One thing is that
the generics_of and other queries for "anonymous constants"
currently use the incorrect parent def-id precisely to avoid a cycle,
so it's hard to see how the cycle would manifest.
Next step: re-establish the cycle in those queries so it can be observed.
centril + aturon drew up a paper document containing GAT use casts and there are some notes from the conversation in this Zulip thread.
Next step: unclear, but probably to investigate the use cases and make some comments.
We had a chat (with video) about how the RLS 2.0 type checker works. We decided we'd rather try to do the chalk integration into RLS 2.0 "correct", meaning that we can share a lot more code with chalk.
Next step: nikomatsakis to schedule some time to sketch out what chalk integration would look like.
Maybe discuss other chalk improvements? (e.g., benchmarking harness) (nikomatsakis)
This didn't happen and we'll probably shelve it for now in favor of the previous point.
Maybe discuss the "lifetime capture" problem in impl Trait?
This didn't happen and we'll probably shelve it for now in favor of the next point.
centril plans to (at minimum) upload some draft RFCs to a new wg-traits repository.
alexreg has been working on associated type bounds in this Zulip thread and will likely continue to do so.
generics_of query etc for constants so we can
observe what results.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.