Skip to content

Rc and Arc should be marked #[fundamental] #24317

@ftxqxd

Description

@ftxqxd
Contributor

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

Activity

pnkfelix

pnkfelix commented on Apr 11, 2015

@pnkfelix
Member

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

nagisa commented on Apr 13, 2015

@nagisa
Member

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

nikomatsakis commented on Apr 13, 2015

@nikomatsakis
Contributor

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.

added
T-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.
on Jan 8, 2016
aturon

aturon commented on Jan 20, 2016

@aturon
Member

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

alexcrichton commented on Jan 21, 2016

@alexcrichton
Member

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.

reopened this on Nov 13, 2017
cramertj

cramertj commented on Nov 13, 2017

@cramertj
Member

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.

added
C-enhancementCategory: An issue proposing an enhancement or a PR with one.
on Jan 22, 2018
cramertj

cramertj commented on Dec 18, 2018

@cramertj
Member

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.

7 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-type-systemArea: Type systemC-feature-requestCategory: 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.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @steveklabnik@alexcrichton@nikomatsakis@pnkfelix@nagisa

        Issue actions

          Rc and Arc should be marked #[fundamental] · Issue #24317 · rust-lang/rust