Add a Library Trait Evolution experiment

[lcnr]

I am not fully happy with this proposal as is. Ah well, it's fine :>

I do want this to be active and to provide monthly updates here, so it feels appropriate as a project goal.

I don't have any specific timeline in mind as the main goal here is to explore the design space. It also overlaps with https://rust-lang.github.io/rust-project-goals/2026/supertrait-auto-impl.html and kind of subsumes it, but not fully 🤷

Open questions

Is it possible to add other project goals as work items of another project goal? I would like to link to this project goal from https://rust-lang.github.io/rust-project-goals/2026/move-trait.html.

cc @dingxiangfei2009 @cramertj @tmandry

Rendered

[nxsaken]

This feels similar in spirit to Rust/C++ interop problem space mapping. I don't think it supersedes the other goals because they have more specific objectives. I'm also not sure why Move should have this as a work item; could you elaborate?

[lcnr]

This will be even more of an issue once we add new implicit default auto trait bounds to support Immobile types and guaranteed destructors or the Sized Hierarchy. For example in trait Trait { fn foo<T>(); } the generic parameter T will get an implicit T: Move bound whose removal is a breaking change. This makes immobile types a lot less useable with existing traits.

I want to be able to weaken the implicit move bounds for trait methods in impls, and there's currently no way to do this. This for the Trait above, there'd be no way to call foo with a type T that is not Move and right now there's no way for library authors to work around this without making a breaking change

[tomassedovic]

@lcnr I made a few changes/fixes.

This is ready to go once we have a types champion. You can add them yourself (and it can be you, if you'd like) or let us know and we'll do it.

There's nothing preventing you from adding any work item to any goal. We don't really have a specific way of declaring dependencies, but that's one way to do it or mentioning it there.

[lcnr]

the other question is how to accept this. do we still merge this and then separately accept? What's the process here. From a @rust-lang/types perspective I'd like it to require a second + 10 day FCP 🤔

unsure. it was accepted as a lang experiment already, so we could just quickly chat about it in the next types meeting and then merge it as accepted 🤷

[nxsaken]

There's no rigorous process for this for now; as long as the Goal proposal has the necessary champions, we can just merge and accept it. In fact, there are some merged Goals in the Proposed state that should be updated to Accepted (will do that shortly)

[nxsaken]

I'd like it to require a second

You adding yourself as the types champion is the seconding. Goal owners who are also team members can champion their own Goals. Since Goals are less "powerful" than RFCs and PRs, this is okay (IMO).

[tomassedovic]

I think the "seconding" in Types is that someone proposes an experiment and someone else agrees with it and that's when what would make the experiment "accepted".

lcnr championing the goal themself wouldn't count as seconding (IIRC!).

I think seconding is what should turn the goal from Proposed to Accepted in our tracking. I think for now any of the following would count as seconding:

• replying here in the comments
• opening a PR/commit changing status to Accepted
• replying somewhere at least Project-public on Zulip.

We could merge the goal now and have a separate PR for seconding or keep this open. I'm not sure we have FCP bot set up here. If y'all want to keep that process going, we should.

[nxsaken]

I see, the Compiler MCP process (Types didn't have a separately documented MCP, AFAIK) does say:

A second, a member of the compiler team who approves of the idea, but is not the one originating the proposal.