Tighten up the auto-deref algorithm

[brson]

@nikomatsakis has mentioned that it has some unpredictable interactions with type checking. Hard to spec and understand as-is. Nominating.

[eddyb]

Is this a dupe of #12825?

[nikomatsakis]

No. I think what @brson was thinking of was an idea I had to make auto-deref behavior more predictable. The basic plan was to say that we always autoderef until we find a type T where one of the following conditions is true:

1. The type T is defined in the current module or some ancestor of the current module.
2. The type T is not derefable (does not implement Deref, not a built-in derefable type).

Such a plan would probably best go through the RFC process, and it might need some fine-tuning as well. I had planned to do some local experiments first. There are a fair number of pre-requisites, among them #5527 (which I think encompasses #12825).

[pnkfelix]

Assigning P-backcompat-lang, 1.0.

[nikomatsakis]

Specifically: can we make it possible to add methods to smart pointers without breaking backwards compatibility for users of those smart pointers?

Also, is there a way to make smart pointers able to explicitly identify methods that they DO want to override? For example, Rc<T> may want clone() to be callable so users can write my_rc.clone().

One issue with my proposal in general is that if I implement a trait on a pointer type, you still won't be able to use that trait with method notation.

In other words,

trait Foo { fn foo(self); }
impl Foo for &T { fn foo(self); }

and

trait Foo { fn foo(&self); }
impl Foo for T { fn foo(&self); }

cannot be used in an equivalent way (in fact, they are not quite equivalent in the trait method resolution algorithm I already proposed; that's something I ... kind of forgot about and was meaning to rectify. But it's not too hard to rectify today).

[pcwalton]

@nikomatsakis Is there an RFC on this? If so, could you link to it? If not, could you make one?

[nikomatsakis]

I have not made an RFC. I've been hoping to finish #5527 / UFCS and do some experiments. Perhaps that is too conservative. I'll try to write something up, sure.

[pcwalton]

After talking with Niko I'd like to nominate this for removal from 1.0. We don't have clear ideas on what to do here.

[pnkfelix]

(postponing to triage where at least one of {patrick, niko} is present.)

[pnkfelix]

(okay patrick came back.)

@pcwalton relays that during a 1:1 discussion with niko, their consensus is that the potential cures they could conceive seemed potentially worse than the disease here.

So taking off the 1.0 milestone, at least until someone proposed an RFC that is actually a net improvement.

In the meantime, the safest way to defend the issues described here that I can see is to use top-level functions rather than methods to manipulate the state of the smart pointer itself and avoid the auto-deref'ing.

Closing.