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.
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-typeand it doesn't move or do anything creepy (to call eq explicitly, in contrast, you'd writeval1-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 bis kind of implicitly(&a).OP(&b))@pcwalton I expect you in particular might have an opinion about this.