Custom Smart Pointers in Rust
===

## What do we need?

Before we start exploring solution I think it's important to list what are the things that we need for smart pointers.

Let's say that we have a smart pointer `MyPtr<T>` which is a wrapper around a pointer to T, and a type called `Foo`. Then we might have the following needs:

0. Be able to used as `self` type.

    impl Foo {
        fn foo(self: MyBox<Foo>) { /* ... */ }
    }

1. Be able to call method on `Foo` with first argument being `&Foo` or `&mut Foo`

    let mut my_ptr: MyBox<Foo> = ...;

    my_ptr.foo(); // Able to call `Foo::foo(&Foo)`
    my_ptr.foo_mut(); // Able to call `Foo::foo_mut(&mut Foo)`

2. Be able to call method on `Foo` with first argument being `MyPtr<Foo>` or `&MyPtr<Foo>`.

    let mut gc_ptr: Gc<Foo> = ...;

    gc_ptr.foo(); // Able to call Foo::foo(&Gc<Foo>) 

3. Be able to be coerced to an unsized type, or be trait upcasted.

    let my_ptr: MyBox<Foo> = ...;
    let my_ptr: MyBox<dyn Bar> = my_ptr;

4. Be able to be used for dynamic dispatch (trait object).

    trait Bar {
        fn bar(self: MyBox<Self>);
    }

    let my_ptr: MyBox<dyn Bar> = my_ptr;
    my_ptr.bar(); // calls Foo::bar(MyBox<Foo>);

## Current situation

So what's the current situation?
* For case 1, we already have `Deref` trait today.
* For case 0 and 2, we have the `Receiver` trait, or the `arbitrary_self_types` feature. Currently, we require the custom type to implement `Deref` for the `Receiver` trait to be useful.
* For case 3, we have the `CoerceUnsized` trait.
* For case 4, we have the `DispatchFromDyn` trait. However, it's important to note, that while this trait can be implemented without `Receiver` trait, but it's useless.

The [arbitrary self types RFC](https://github.com/rust-lang/rfcs/pull/3519) tries to address case 0 (and 2), without adressing case 3 and 4. It spents a lot of effort trying to make the case 2 extend to types that are not `Deref`.

## Evaluation

First of all, I think it's important to note that, the case 0 (i.e. ability to make a custom type receiver), *should not* be a goal. It should be a *mean* that allows us to solve other cases. We don't need to allow more types to be put into `self: T` just for the sake of being able to do it, but rather we should focus on *why* we'd want to put things there.

So, let's look at case 2-4 and see what can we gain from these (ignoring case 1 which is already stable).

### Method resolution

It should be important to notice that case 2 and the other two are of different categories. Case 2 doesn't add any new power to the language, but rather just a syntactic sugar. It's already possible to just use `Foo::foo(&my_ptr)`. Case 2 provides us with a nice sugar to turn it into `my_ptr.foo()`, but that's only value that it provides.

It should be noted that we already define quite a few methods on `*const T` or `Weak<T>`, and it can be a quite a disaster if we allow `weak.foo()` or `raw_ptr.foo()` because it
* makes it a breaking change to add methods on `Weak`, or makes it a breaking change to add methods on `Foo`
* makes it confusing to know which type provides which method.

This won't be an issue for new types, but I think it's a bad idea to retrospectively tweak method resolution for existing types like `Weak` and raw pointers.

### Dynamic dispatch

Case 3 and 4, on the other hand, provides *real* power to library authors. Currently, smart pointers that allow dynamic dispatch is a privilege that only standard library smart pointers enjoy. It's extremely difficult if not impossible to replicate this feature in 3rd party libraries, and even it's possible, it won't be as ergnomical.

Different from case 2, there are value in extending dynamic dispatch to `*const T` and `Weak<T>`, and it is backward compatible. It should be noted that `DispatchFromDyn` even is already implemented for those types, but we just don't have a way to use them (we do hard-code raw pointers in `arbitrary_self_types` feature, but I don't think hardcoding is good).

If we look at all types, we can see that they have different needs,

| Types | 1 (Deref) | 2 (Method) | 3 (Unsize) | 4 (Dispatch) |
| ------|---------- | ---------- | ---------- | ------------ |
| `Box`/`Arc` | ✓ | ✓ | ✓ | ✓ |
| `*const`/`*mut T` | ✕ | ✕ | ✓ | ✓ |
| std `Weak` | ✕ | ― (too late to change) | ✓ | ✓ |
| custom `Weak` | ✕ | ✓ | ✓ | ✓ |

(There are definitely smart pointers that need 12 but not 34, but I can't think of any now)

The sad thing, though, is that we entangled things a bit too much. For `DispatchFromDyn` to be useful, you need to implement `Receiver`, for which you need to implement `Deref`. So you have all of case 1, 2, 3, 4, or you have none of them, but there are scenarios where we need 3 & 4, but don't want the ability to do `Deref`.

## So what's the next step?

The current self arbitrary types, both as current implemented and the new RFC, doesn't address the dynamic dispatch issue, which I think is more important than the symbol resolution. Furthermore, if we pursue self arbitrary self types without considering dynamic dispatch, this may make the entanglement worse and make it even harder to make dynamic dispatch work.

I think a reasonable first step is to see how we can detangle receiver with dynamic dispatch. Perhaps we can lift the requirement that a method must have `self` to be used in trait object? I don't see a particular reason why

trait Bar {
    fn bar(this: *const Self);
}

can't be made object-safe and dispatched on `this` (i.e. lifting the `self` requirement, and dispatch on the first argument instead).

You can then call this with `<dyn Bar>::bar(dyn_bar)`.

Combining this with an arbitrary self types *without* pointers would cover *almost* all use cases, with the exception that we won't have the sugar to use method-calling syntax on methods defined on `T` that takes `Weak<T>`.