Trait requirements for RefCountFamily

[Eh2406]

Rc and Arc have a number of methods in common, which of them should be required for RefCountFamily?
Obviously this is a judgment call. The fewer methods we require, the more implementations can implement the trait. The current requires of Deref<Target = T> + Clone and new, are so broad that we could even implement it for Box. The more methods we require, the more complicated implementations can be generic. I am personally very fond of make_mut, but different people will disagree about which ones are critical.

As a pre-RFC research project, this question could probably be generalized to "for all methods implemented by Rc and Arc which ones can't be added to the trait and why?"
I would also be interested whether there some way to split up the methods that involve Weak into a substrait. So that WeekCountFamily requires RefCountFamily and adds the functionality for Weak pointers.

[cark]

Those bounds wouldn't apply to RefCountFamily itself but rather to RefCountFamily::Pointer<T>.
While experimenting, I had this being bounded by a RefCounted<T> trait, it is still there, but commented. This would be the perfect place where we can add those constraints.

You may ask why I removed it.

• I had hoped it would help the type inference, but it really doesn't.
• It increases the burden of the implementer for other reference counted pointers.
• With the RefCounted trait there, it was all too tempting for this library's user (that would be me !) to use it instead of the RefCountedFamily trait. While this works, it leads to some pretty hairy typing later on.

Now you're proposing increasing that implementer burden even further, but I can see how it does make sense. After all, what's the point providing a generic reference counted pointer if it doesn't come with all the services we might expect from those.

If we accept this, then of course the Weak family has to follow.

[Eh2406]

I wonder if it makes sense to have three families of traits. PointerLikeFamily with Deref<Target = T> + Clone that can be implemented by Box, Arc, and Rc. RefCountFamily with RefCounted for the shared ownership specific things. WeekCountFamily with WeekCounted for week specific things.

I don't know how many of these will pull their weight to be uplifted into STD, but the only way to find out is to have implementations to look at. If we discover that these are complicated and opinionated designs but they can be implemented as a library, then there's no reason to uplift them and that's really valuable information. If we discover that some of them have a clear-cut design or cannot be implemented as an extra library without nightly features, then we have a strong argument to uplifted which is also really valuable information. Unfortunately, the best way to find out is to try.

[cark]

What pointer like things do you envision going into the PointerFamily other than Box ?
I agree for the Weak pointers, this will be unavoidable as we need to implement downgrade.

I'm already hitting a snag for all implementations that are specializing on different traits for T.

It is possible to do this:

        struct MyRc<T: ?Sized>(T);
        impl<T: ?Sized> MyRc<T> {}
        impl<T: Clone> MyRc<T> {
            fn make_mut(this: &mut Self) -> &mut T {
                &mut this.0
            }
        }
        let mut a = MyRc(1i32);
        *MyRc::make_mut(&mut a) += 1;
        assert_eq!(a.0, 2);

But we cannot do this:

        trait MyTrait<T> {
            fn return_it(this: &Self) -> &T;
        }
        struct A<T>(T);
        impl<T> MyTrait<T> for A<T> {
            // we're using the years away from ready 'specialization' feature (RFC1210)
            default fn return_it(this: &Self) -> &T {
                &this.0
            }
        }
        // This doesn't fly
        impl<T: Clone> MyTrait<T> for A<T> {
            fn clone_it(this: &Self) -> T {
                this.0.clone()
            }
        }

And rightly so, clone_it doesn't belong to MyTrait. Even nightly feature specialization wouldn't help here.

So this means we'll need to introduce a trait for each specialization:

// RefCountedClone
pub trait RefCountedClone<T: Clone + ?Sized>: RefCounted<T> {
    fn make_mut(this: &mut Self) -> &mut T;
}

impl<T: Clone + ?Sized> RefCountedClone<T> for Rc<T> {
    fn make_mut(this: &mut Self) -> &mut T {
        Self::make_mut(this)
    }
}

    fn test_make_mut() {
        fn actual_test<Mark: RefCountFamily>()
        // this is less than ideal
        where
            <Mark as RefCountFamily>::Pointer<i32>: RefCountedClone<i32>,
        {
            let mut data = Mark::Pointer::new(5i32);
            *RefCountedClone::make_mut(&mut data) += 1;
            let mut other_data = Mark::Pointer::clone(&data);
            *RefCountedClone::make_mut(&mut data) += 1;
            // other incantation, same thing
            *Mark::Pointer::make_mut(&mut data) += 1;
            *RefCountedClone::make_mut(&mut other_data) *= 2;
            assert_eq!(*data, 8);
            assert_eq!(*other_data, 12);
        }
        actual_test::<RcMark>();

        fn actual_test2<RC: RefCountedClone<i32>>() {
            let mut data = RC::new(5);
            *RC::make_mut(&mut data) += 1;
            let mut other_data = RC::clone(&data);
            *RC::make_mut(&mut data) += 1;
            *RC::make_mut(&mut data) += 1;
            *RC::make_mut(&mut other_data) *= 2;
            assert_eq!(*data, 8);
            assert_eq!(*other_data, 12);
        }
        actual_test2::<Rc<i32>>();
    }

While this works, I fear it's getting a bit OOPish, and still increases the burden for reference type implementers.
I also fear we'll have a combinatorial explosion of traits that will all need to be implemented for each concrete type.

[Eh2406]

What pointer like things do you envision going into the PointerFamily other than Box ?

Based only on a quick search of lib.rs:

• https://lib.rs/crates/without-alloc
• https://lib.rs/crates/smallbox
• https://lib.rs/crates/recycle-box
• https://lib.rs/crates/atomic-pool

I agree that a separate trait per specialization is going to end up being not worth it.
And indeed there going to be implementations that cannot work with our standard traits because they require bounds that are different from the ones required an STD. But, at least for STD, the trait requirements are not random all the implementers of make_mut need clone. I wonder if we can use the where Self: Clone syntax like:

use std::rc::Rc;
use std::sync::Arc;

pub trait RefCounted<T: ?Sized> {
    fn make_mut(this: &mut Self) -> &mut T where Self: Clone;
}

impl<T: Clone + ?Sized> RefCounted<T> for Rc<T> {
    fn make_mut(this: &mut Self) -> &mut T {
        Self::make_mut(this)
    }
}

impl<T: Clone + ?Sized> RefCounted<T> for Arc<T> {
    fn make_mut(this: &mut Self) -> &mut T {
        Self::make_mut(this)
    }
}

https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e76586443007b5729616e10ad7f49844

[cark]

Ah but that would mean that every RefCounted would always require T to be Clone. Because there is no way to create an impl for Rc both with and without the Clone bound on T ... That just doesn't work without the far out specialization feature.

use std::rc::Rc;

pub trait RefCounted<T: ?Sized> {
    fn make_mut(this: &mut Self) -> &mut T where Self: Clone;
    fn do_something(&self);
}

impl<T: Clone + ?Sized> RefCounted<T> for Rc<T> {
    fn make_mut(this: &mut Self) -> &mut T {
        Self::make_mut(this)
    }
    fn do_something(&self) { println!("yoh"); }
}

impl<T: ?Sized> RefCounted<T> for Rc<T> {
    fn make_mut(this: &mut Self) -> &mut T {
        Self::make_mut(this)
    }
    fn do_something(&self) { println!("yoh"); }
}

run this playground link and see the dreaded conflicting implementations of trait error.

[cark]

As for implementing additional traits, i'll just keep going a little bit on that road and see how it goes

[Eh2406]

You cannot have multiple implementations, but you can have one implementation where a given method is conditional.
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=4d337e3d39ef8cd2e24a6359aa897e64

use std::rc::Rc;

pub trait RefCounted<T: ?Sized> {
    fn make_mut(this: &mut Self) -> &mut T where T: Clone;
    fn do_something(&self);
}

impl<T: ?Sized> RefCounted<T> for Rc<T> {
    fn make_mut(this: &mut Self) -> &mut T where T: Clone {
        Rc::make_mut(this)
    }
    fn do_something(&self) { println!("yoh"); }
}

(also, playground links are immutable. You need to click share to get a new link to the code that's currently in the editor.)

[cark]

That works indeed ! Thanks for clearing that up for me.

[cark]

I pushed implementations for the direct methods or Arc and Rc, RefCounted trait and WeakFamilly with its WeakPointer companion. Didn't make a common trait for Weak and Strong pointers as their API is actually quite different.

I think for the moment we should restrict the scope of this project to reference counted pointers.

[Eh2406]

I took a brief look over your new code. It is really cool! This is coming together. Thank you for all the work you put into it!

I agree that week and strong pointers should not be abstracted over, their different things with different semantics.

I don't see why WeakFamilly is needed, but I have not experimented with the code. It will probably be obvious when I sit down to try and remove it.

Also, while I was sleeping my brain cell had time to do some work. I realized that there's another way to organize the traits, one where the user can pick the methods they need.
As we've discussed before, if we have a PointerFamily that only requires type Pointer<T: ?Sized>: Deref<Target = T> + Clone; then lots of things can implement it but you can only dereference and clone the pointer.
Similarly, we can have a RefCounted trait that adds the functions one would expect from Rc and Arc. Unfortunately if we tie them together then only ref counted things can use our abstraction.
Here's the insight from last night, what if we just don't tie them together. Then to use a pointer like thing whose pointer is ref counted you can do something like:

fn needs_ref_count<R>(s: String)
where
    R: PointerFamily,
    R::Pointer<String>: RefCounted<String>,
{
    let mut r = R::new(s);
    let _r2 = R::Pointer::make_mut(&mut r);
}

Playground link for a runnable example.
This feels like a nice way to split things up. Specifically there is nothing stopping STD in the future or a crate defining its own RefCounted like traits. This gives lots of flexibility for how to handle changes. What if someone adds a new API to both Arc and Rc, it may be possible to add it to STD's RefCounted as long as there's some good default behavior. But if there isn't a way to add it to STD's RefCounted then STD can add a new trait RefNewStuff. People who are using the new functionality can just require R::Pointer<T>: RefCounted<T> + RefNewStuff<T>!

[cark]

You're right, the WeakFamily is useless, I'll push a version without it in a few minutes.
Let's make another issue about this PointerFamilly.