Implement Receiver for Exclusive

[Jules-Bertholet]

In the hope of being able to implement DerefMut in the future.

Changes Exclusive's methods to associated functions.

cc #98407

@rustbot label T-libs-api

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

It isn't immediately obvious how/why this is blocked and what would make it possible, could you link to your comment explaining it on the tracking issue?

[Jules-Bertholet]

Done

[tgross35]

Nominated for libs-api #98407 (comment)

[bors]

☔ The latest upstream changes (presumably #147128) made this pull request unmergeable. Please resolve the merge conflicts.

[joshtriplett]

We talked about this again in today's @rust-lang/libs-api meeting.

It doesn't seem like trying to work towards DerefMut-without-Deref is worth the complexity for this one type; it doesn't seem likely that that capability will get much use. And adding DerefMut also means making this type's methods less conveniently usable. You can always do .get_mut().method().

If in the future we want to make this work with arbitrary self types, or if the idea of doing DerefMut ends up going through further discussion and reaching consensus, we can always add this later. But it doesn't seem critical to add it speculatively in the hopes of enabling future work that we may not end up wanting to do.

Is there another reason to add this in advance, given that it's an unstable trait being implemented for an unstable type?