Rc and Arc should be marked #[fundamental]

[ftxqxd]

Box is already, so I think all other pointer types probably should be too.

[pnkfelix]

cc @nikomatsakis

(I'm not sure I agree with the assertion made here, but it seems like it would be good to talk about it, and then either improve the docs to explain why one should not, or actually do it.)

[nagisa]

Box is just a wrapper around plain pointer, while Rc and Arc are not. This is also https://github.com/rust-lang/rfcs material.

[nikomatsakis]

My feeling is that making Rc, Arc, and other "smart pointer" types "fundamental" probably does make sense, but I'm still reluctant to use this attribute too widely until we have a better feeling for what changes (if any) we want to make to coherence. i.e., is #[fundamental] the actual scheme that we want or what?

If we do decide the fundamental IS the scheme we want, then I would probably apply it to:

1. smart pointers, by convention.
2. ops traits, just because it's easy enough to remember.

These would be generalization of the existing types (Box) and traits (Fn, etc) that are marked as fundamental.

[aturon]

I definitely don't think we should make this step just for the sake of uniformity. As @nikomatsakis alludes to, we probably want to drop #[fundamental] in favor of some other approach in the future, and so I think we should avoid using it as much as possible in the meantime.

[alexcrichton]

We discussed this in the libs team triage yesterday and as @aturon mentioned we'd like to avoid more #[fundamental] types if possible (as mentioned by @aturon), so closing.

[cramertj]

I've been wanting this several times recently when implementing some traits with functions which take &mut self, but many impls of which actually only need &self. I'd love to be able to write impl MyTrait for Arc/Rc<MyType> (&'a doesn't work because I need to pass a 'static type). My current workaround is to make a wrapper type struct MyWrapper(Arc<MyType>) and do impl MyTrait for MyWrapper. This is annoying, and it seems unnecessary.

While I understand the justification for wanting to avoid #[fundamental], I think that smart-pointer types such as Rc and Arc should work the same as & and Box from a coherence perspective.

[cramertj]

I keep coming back to this and am pretty confident that, given that &mut, &, Box, and Pin are all #[fundamental], Arc and Rc should be as well. I can't come up with a justification for these types behaving inconsistently. I understand the reluctance to add more #[fundamental] types since it spreads a system we're not confident in the workings of, and I'd be opposed to adding #[fundamental] to other non-ptr-related types in stdlib just for the convenience of it, but I think it's more important that our pointer types behave consistently with one another. I've opened #5695 -- feel free to close if you decide it's still unwanted.

[Mark-Simulacrum]

It feels like with self: Arc<Self> and such being possible this might be largely no longer as necessary, even if it would be nice to have. It's also pretty clear that this leads to breakage in practice based on the crater run in #56955, so I think movement here would probably be worth of an RFC (though, likely, a somewhat small one). Closing.