Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

&5i + 5i compiles but 5i + &5i or &5i == 5i don't #8895

Closed
ben0x539 opened this issue Aug 31, 2013 · 4 comments
Closed

&5i + 5i compiles but 5i + &5i or &5i == 5i don't #8895

ben0x539 opened this issue Aug 31, 2013 · 4 comments
Labels
A-typesystem Area: The type system

Comments

@ben0x539
Copy link
Contributor

Auto-borrowing or auto-dereferencing are confusing me here, but this feels somewhat weird and inconsistent.

I wonder why all the operator overloads need to implemented methods rather than associatied functions where all the operands could be equally unsurprising arguments and not half arguments, half method receivers, but I'm not sure how applicable that is to this nitpick.

@nikomatsakis
Copy link
Contributor

Related to #4920. My proposal is to make == and other operators never do any form of auto-coercion.

I am also inclined to agree associated fns would be better than methods but it doesn't really make any difference to the question at hand, which is what the behavior should be when used as binary operators.

@flaper87
Copy link
Contributor

Visiting for triage, still needs to be fixed.

Proposed bug example:

fn main() {
    &5i + 5i;
    5i + &5i;
    &5i == 5i;
}

@pnkfelix
Copy link
Member

pnkfelix commented Jul 4, 2014

cc me

@ben0x539
Copy link
Contributor Author

oh hey this went away with the introduction of by-value operator overloading traits

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-typesystem Area: The type system
Projects
None yet
Development

No branches or pull requests

4 participants