-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Closed
Labels
A-type-systemArea: Type systemArea: Type systemC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Metadata
Metadata
Assignees
Labels
A-type-systemArea: Type systemArea: Type systemC-feature-requestCategory: A feature request, i.e: not implemented / a PR.Category: A feature request, i.e: not implemented / a PR.T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.Relevant to the library API team, which will review and decide on the PR/issue.
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
pnkfelix commentedon Apr 11, 2015
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 commentedon Apr 13, 2015
Box
is just a wrapper around plain pointer, whileRc
andArc
are not. This is also https://github.com/rust-lang/rfcs material.nikomatsakis commentedon Apr 13, 2015
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:
These would be generalization of the existing types (
Box
) and traits (Fn
, etc) that are marked as fundamental.aturon commentedon Jan 20, 2016
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 commentedon Jan 21, 2016
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 commentedon Nov 13, 2017
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 writeimpl 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 typestruct MyWrapper(Arc<MyType>)
and doimpl 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 asRc
andArc
should work the same as&
andBox
from a coherence perspective.cramertj commentedon Dec 18, 2018
I keep coming back to this and am pretty confident that, given that
&mut
,&
,Box
, andPin
are all#[fundamental]
,Arc
andRc
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.7 remaining items