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

Implemented Mul operator trait can't be used #22099

Closed
bluss opened this issue Feb 8, 2015 · 4 comments
Closed

Implemented Mul operator trait can't be used #22099

bluss opened this issue Feb 8, 2015 · 4 comments
Labels
A-type-system Area: Type system

Comments

@bluss
Copy link
Member

bluss commented Feb 8, 2015

A user provided the following test case that fails compiling at the point where the * operator is used.

use std::ops::Mul;

#[derive(Copy)]
pub struct S {
    a: f64
}

impl Mul<f64> for S {
    type Output = S;

    fn mul(self, scalar: f64) -> S {
        S {
            a: self.a * scalar
        }
    }
}

impl Mul<S> for f64 {
    type Output = S;

    fn mul(self, s: S) -> S {
        s.mul(self)
    }
}

fn main() {
    let s = S {a: 0f64};
    s * 5f64;
    5f64 * s; // error: mismatched types: expected `f64`, found `S`
              // (expected f64, found struct `S`) [E0308]
}
@mdinger
Copy link
Contributor

mdinger commented Feb 8, 2015

Maybe a dup of #19035 ? Seems similar.

@bluss
Copy link
Member Author

bluss commented Feb 8, 2015

I'm not sure and here's the reason: in #19035, today's coherence rules don't allow the correct trait impls to define addition/multiplication both ways.

What made me react in this bug was that the trait impls are accepted by the compiler, but the operator still doesn't work.

@Diggsey
Copy link
Contributor

Diggsey commented Feb 9, 2015

I don't think coherence rules prevent this: there's no way a sibling crate could contain a different implementation of Mul<S> for f64 because it would have to import this crate to learn of S, and in doing so it would learn of this crate's implementation.

It can't implement a generic version, Mul<T> for f64 because that would violate the coherence rules, as T is not constrained by a local type, and f64 isn't a local type either.

@steveklabnik steveklabnik added the A-type-system Area: Type system label Feb 9, 2015
@mdinger
Copy link
Contributor

mdinger commented Feb 22, 2015

Isn't this a big 1.0 problem? You can do lots of things but not math...

nikomatsakis added a commit to nikomatsakis/rust that referenced this issue Mar 25, 2015
Fixes rust-lang#22743.
Fixes rust-lang#19035.
Fixes rust-lang#22099.

(Those all seem to be exactly the same scenario.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

No branches or pull requests

4 participants