stabilize smart pointer map functions

[Qelxiros]

Tracking issue: #144419
@rustbot modify labels: +T-libs-api

[rustbot]

r? @Darksonn

rustbot has assigned @Darksonn.
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

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: libs
• libs expanded to 12 candidates
• Random selection from 6 candidates

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Darksonn]

Sorry I'm at capacity for the next two weeks.

@rustbot reroll

[dtolnay]

This stabilizes a subset of #144419 — just the map functions and not try_map.

• https://doc.rust-lang.org/nightly/std/boxed/struct.Box.html#method.map
• https://doc.rust-lang.org/nightly/std/rc/struct.UniqueRc.html#method.map
• https://doc.rust-lang.org/nightly/std/sync/struct.UniqueArc.html#method.map
• https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html#method.map
• https://doc.rust-lang.org/nightly/std/sync/struct.Arc.html#method.map

@rfcbot fcp merge libs-api

[rust-rfcbot]

@dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @the8472

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rust-rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[maxdexh]

Is there a reason custom allocators were not included in the implementation?

[nia-e]

...huh. It might honestly just be an oversight? I think it should be sound.

cc @Amanieu @BurntSushi @dtolnay @joshtriplett @the8472 (can't ping the old libs-api anymore) as ppl with checkboxes here - should we block this on adding an allocator param?

[maxdexh]

Allocators are not stable API anyway. The implementation looks simple enough that it should be possible to just jam it in, except that the transmute in Box::map needs to be into_raw_with... + from_raw_in (why is it even using transmute for this?)

If you want I can just write a PR right now

[nia-e]

Wouldn't it be breaking to move this later from an impl for Box<T> into impl for Box<T, A>? if not then ignore me ^^

[maxdexh]

I mean just changing it before stabilization without starting another FCP.

Also I don't think it's breaking even if done later because it would take Box<T, A> with the allocator type in a param. If that's breaking then almost all additions of A: Allocator in the past were breaking.

[maxdexh]

Alright I wrote a PR (#161617). Feel free to do whatever you want with it. If you decide to stabilize first, I'll update it afterwards

[edwloef]

Stabilizing Box::map should probably be blocked on the decision on whether Box::take is OK to exist, since they suffer from the same problem as far as I can tell. See #160436 (comment)

[maxdexh]

Yup, we discussed this on zulip too. It's probably fine but it'll need some thinking

[rust-bors]

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