Operator dispatch

[nikomatsakis]

This branch cleans up overloaded operator resolution so that it is strictly based on the traits in ops, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.

This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the ! operator to a &int. See the first two commits in this pull-request for examples.

One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for Eq, Ord, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.

Fixes #4920.
Fixes #16821.
Fixes #15757.

cc @alexcrichton
cc @aturon

[nikomatsakis]

It occurs to me that we could have a special rule for operators that eagerly coerces fixed-length arrays into slices, much as we eagerly reborrow pointers. But I'm not super enthusiastic about it: special rules are annoying, it won't work super reliably (e.g., not for Rc<[int, ..n]> and Rc<[int]>) and it doesn't help with the deriving problem etc. Still, might be worth doing.

[nikomatsakis]

(Oh, one other thing. If we make Eq and friends take multiple type parameters (as might be nice...) then we could easily define impls that permit "cross-comparison" between fixed-length arrays and slices.)

[japaric]

It occurs to me that we could have a special rule for operators that eagerly coerces fixed-length arrays into slices

If we add this special rule, and change #[deriving(PartialEq)] to use operators instead of method calls (as I have done in #18457) then we would be able to use #[deriving(PartialEq, PartialOrd)] on structs that contain fixed size arrays of any size. (It still wouldn't work with fields like Box<[T, ..N]>, Rc<[T, ..N]>, but those types seem not useful to me, do they even come up in practice?)

(Oh, one other thing. If we make Eq and friends take multiple type parameters (as might be nice...) then we could easily define impls that permit "cross-comparison" between fixed-length arrays and slices.)

Wouldn't the last part require being able to use integers as generic parameters? As in fn eq(&self, rhs: &[T, ..N]) -> bool where Self = &[T]. Or you mean manually implementing all the cross comparisons up to N = 32?

[alexcrichton]

Can't wait to give this a go, thanks @nikomatsakis!

[nikomatsakis]

@japaric yes, it would suffer from the same limitations about length.

Yes so perhaps we should "eagerly-unsize" fixed-length arrays used with operators. It handles arbitrary sizes and is more ergonomic. Deriving could be fixed either by using operators or by just modifying deriving to understand that (for things like Eq etc), if something is a fixed-length array, it ought to first convert to a slice. Hmm. As a bonus, I think it's not very hard to do.

[nikomatsakis]

One possible downside I can see is that a == b where a and b are both fixed-length arrays may not be compiled as efficiently, because it will convert to a loop that llvm has to unroll. OTOH, LLVM can do that, at least in principle, and anyhow currently I implemented the traits just by doing a[] == b[], so clearly that's no different.

[nikomatsakis]

(Note though that this efficiency argument could be side-stepped by not using operator form)

[nikomatsakis]

@japaric ok, I prototyped the [T, ..n] => [T] coercion but without Eq implementations for [T] it winds up making less code compile. So I will land as is I think and then bring it in as a second PR once you land your new Eq implementations. It's a pretty small patch (about 5 lines or so).

[SiegeLord]

Does this change in semantics completely preclude future implementation of the ad-hoc operator overloading (rust-lang/rfcs#399)?

[nikomatsakis]

@SiegeLord this is not a change in semantics, it's just tightening up the semantics we have. It doesn't preclude going to ad-hoc operator overloading in particular, though obviously that would require further changes.

[japaric]

@nikomatsakis How does this PR affects issues #8280 and #10337?

[nikomatsakis]

@japaric I did not fix #8280 but #10337 is really a dup of #4920 I think. Certainly #10337 describes what I did in this PR for the most part; it also describes how we could possibly fix #8280 if we wanted to.

[chris-morgan]

I’m guessing “tuple” is a mistake here?

[nikomatsakis]

yes. although as this is a private module it hardly matters...

[nikomatsakis]

actually I have no idea what that annotation does :) anyway, correction in commit ec67675

[chris-morgan]

@nikomatsakis This marks the documentation for the primitive types as they are handled in links and things like that, e.g. for tuple and slice.

[sinistersnare]

so does this fix #16821 / #15757?

[chris-morgan]

So now it’s stable and experimental?

[nikomatsakis]

Um... too late to be making edits, I guess.

[nikomatsakis]

@sinistersnare yes it will fix those issues.

[japaric]

Can't [1, 2][] be written just as &[1, 2]?

[nikomatsakis]

@alexcrichton is that a known failure?

[alexcrichton]

Sadly not yet, that's the first time I've ever seen that :(

[nikomatsakis]

@alexcrichton it could be the fault of this PR, plausibly, though make check passes locally (linux)

[alexcrichton]

The error code listed corresponds to 0xc0000005 and googling for that points to it being some form of access violation, so we may have just uncovered a bug in gcc or ld (who knows!).

[nikomatsakis]

@alexcrichton let's see if it repeats. not obvious to me how what I did would be at fault, but then I did change operator resolution, so in principle it COULD affect things.