RFC: Change operator method lookup to be less magical

[nikomatsakis]

Right now, operator "methods" proceed according to the same logic as any other method. But this leads to surprising results like this: https://gist.github.com/bstrie/4948410

Also, operators are already handled somewhat specially because we auto-ref their arguments. This means that you can write val1-of-my-linear-type == val2-of-my-linear-type and it doesn't move or do anything creepy (to call eq explicitly, in contrast, you'd write val1-of-my-linear-type.eq(&val2-of-my-linear-type)).

I think method lookup for operators should never apply any automatic transformations to the receiver or arguments, other than the current auto-ref behavior (which means that a OP b is kind of implicitly (&a).OP(&b))

@pcwalton I expect you in particular might have an opinion about this.

[nikomatsakis]

I think this should apply also to unary operators and the [] operator, except that [] autoderefs its receiver (as it does normally).

[nikomatsakis]

Discussed in meeting: https://github.com/mozilla/rust/wiki/Meeting-weekly-2013-03-12

[nikomatsakis]

It seems that we only partially discussed this issue in the meeting. In particular, we did not discuss:

1. Removing argument coercions from uses of overloaded operators
2. Extending auto-ref to the argument of the [] operator, which seems useful for hashtables

On point 2, currently a[b] is converted to a.index(b) but if we extended autoref (as we do with all other operators) it would be equivalent to a.index(&b).

[graydon]

seems reasonable to me

[graydon]

Looks like this was merged in #5558 .. @nikomatsakis can this close?

[pnkfelix]

Visiting for triage, email from 2013-09-02.

Nominating for milestone 1, well-defined.

(Of course, its possible that graydon's hypothesis that this might be closeable is true. @nikomatsakis, any thoughts?)

[nikomatsakis]

Not closeable in that point 1 remains unresolved: do we want to coerce arguments? I remember @pcwalton had this on the agenda recently (under the guise of == operations).

[catamorphism]

Accepted for milestone 1, well-defined

[flaper87]

Triage bump, this still needs some work.

[sinistersnare]

Should this go through the new RFC process? I hope that == does no coercion, and it might un-stagnate the conversation.

[rust-highfive]

This issue has been moved to the RFCs repo: rust-lang/rfcs#283

[japaric]

@nick29581 I think @rust-highfive shouldn't have closed this issue, since it's marked as P-backcompat-lang - unless that tag no longer applies, but I don't think that's the case here.

[nrc]

reopening and nominating for triage to decide what to do with this

[nikomatsakis]

Repeating a relevant comment from #16918:

what I'm most concerned about is that, currently, we do a kind of odd-ball search when looking up operators. e.g., if we have l + r, where the types of l and r are L and R, I just want to search for Add<L,R>, rather than doing a traditional method search (which involves auto-ref, coercion, and other considerations). This does mean that in some cases we might wind up writing "convenience" impls for things like String compared with &str that basically encode common coercions. But I think it's more predictable overall. Today I whippe up a prototype of this approach, though it doesn't quite build yet. One obstacle is the current Eq and Ord traits which do not permit comparison between two distinct types for some reason.

[nikomatsakis]

I am working on this. I consider this a bug fix and not RFC worthy, though this is perhaps debatable. Basically what I am implementing is what I think the semantics were supposed to be, and it requires very few changes to existing code anyhow since most code is using operators as intended.

Basically the changes I am doing are:

1. The [] operator (both for indexing and slicing) autoderefs consistently (right now it only autoderefs for built-in but not overloaded usages, and slicing doesn't autoderef at all).
2. An expression like a op b is basically a trait lookup OpTrait<A,B> where A and B are the types of a and b.
3. Various minor fixes to mutability correction.

Point 2 is what occasionally causes breakage. We used to accept things like foo + bar where foo had type &int and bar had type int. This worked because we applied a kind of odd method search where we did not autoderef but we did autoref, but we did it in reverse order of precedence for a normal method (so we tried to autoref first). I don't consider this to be a particularly sensible semantics: it is neither normal method lookup nor a simple trait lookup, it's just a third thing. This means that occasionally the new code requires an extra *.

Now, I think there are changes we could (and should) make to the operator traits themselves (as I have discussed with @aturon), but what I'm working on now is strictly limited to how the operator traits are matched in the compiler.