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

Explicit operator bound on primitive type shadows built-in operators for that type #105685

Closed
ghost opened this issue Dec 14, 2022 · 0 comments
Closed
Labels
C-bug Category: This is a bug.

Comments

@ghost
Copy link

ghost commented Dec 14, 2022

I tried this code:

pub fn a<T>(x: T) -> T
where
    i64: std::ops::Mul<T, Output = T>,
    T: Copy
{
    let a = 2 * 2;
    2 * x
}

I expected to see this happen: the variable a is inferred to be i32 (or some other integer type) and the operator 2 * 2 uses the built-in integer multiplication operation.

Instead, this happened: the trait bound i64: std::ops::Mul<T, Output = T> shadows the built-in implementation for Mul<i64, Output=i64> which results in the error:

| pub fn a<T> (x : T) -> T
|          - this type parameter
| where i64: Mul<T, Output=T> {
|     let a = 2*2; 
|               ^ expected type parameter `T`, found integer
|
   = note: expected type parameter `T`
                        found type `{integer}`

It is unclear to me whether this shadowing behavior is intended or unintended, however it works fine if the bound is instead T: Mul<i64, Output=T> which makes me wonder if it is unintended.

Meta

rustc --version --verbose:

rustc 1.65.0 (897e37553 2022-11-02)
binary: rustc
commit-hash: 897e37553bba8b42751c67658967889d11ecd120
commit-date: 2022-11-02
host: aarch64-apple-darwin
release: 1.65.0
LLVM version: 15.0.0

@ghost ghost added the C-bug Category: This is a bug. label Dec 14, 2022
@ghost ghost closed this as completed Dec 14, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug.
Projects
None yet
Development

No branches or pull requests

0 participants