Improve Arc and Rc documentation

[JakobDegen]

This makes two changes (I can split the PR if necessary, but the changes are pretty small):

1. A bunch of trait implementations claimed to be zero cost; however, they use the Arc<T>: From<Box<T>> impl which is definitely not free, especially for large dynamically sized T.
2. The code in deferred initialization examples unnecessarily used excessive amounts of unsafe. This has been reduced.

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[JakobDegen]

Apparently I was wrong when I thought I knew how to run the tests locally...

[m-ou-se]

The code in deferred initialization examples unnecessarily used excessive amounts of unsafe. This has been reduced.

I suspect the author of that used get_mut_unchecked rather than get_mut, to avoid unnecssary checks and panicking code in .unwrap(): https://godbolt.org/z/zKczvTx47

(For Rc the compiler can easily optimize the check out, but that (currently) doesn't work with Arc once atomics are involved.)

In general, the new_uninit+get_mut[_unchecked] api is a bit awkward, as it always involves a second function call which either requires unsafe or unwrap. There's some discussion on the tracking issue about a nicer interface: #63291 (comment)

Anyway, I agree that trading unsafe for unwrap is reasonable in documentation.

@bors r+ rollup

[bors]

📌 Commit 4de7618 has been approved by m-ou-se

[JakobDegen]

@m-ou-se oh yeah, I understood the point of doing it that way, but this is also sort of a separate issue in that deferred initialization within Arcs is not on its own a performance optimization but sometimes just the nicest way to write the thing; the .get_mut_unchecked() on the other hand is definitely a performance optimization, and there's no need to add it in many cases. (thanks @Nemo157 for originally pointing this out)