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

Implement numeric fallback #20189

Merged
merged 1 commit into from
Jan 2, 2015
Merged

Implement numeric fallback #20189

merged 1 commit into from
Jan 2, 2015

Conversation

emberian
Copy link
Member

Doesn't yet converge on a fixed point, but generally works. A better algorithm
will come with the implementation of default type parameter fallback.

If inference fails to determine an exact integral or floating point type, it
will set the type to i32 or f64, respectively.

Closes #16968

@rust-highfive
Copy link
Collaborator

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)

@@ -33,7 +33,7 @@ where T : Convert<U>
}

fn a() {
test(22_i32, 44); //~ ERROR unable to infer
test(22_i32, 44); //~ ERROR is not implemented for the type `i32`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be changed to something that actually tests multidispatch & ambiguous destination ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe, I don't really know what that means or what the test would be though :)

@nikomatsakis nikomatsakis assigned nikomatsakis and unassigned brson Dec 24, 2014
@tbu-
Copy link
Contributor

tbu- commented Dec 25, 2014

CC me

bors added a commit that referenced this pull request Dec 26, 2014
Doesn't yet converge on a fixed point, but generally works. A better algorithm
will come with the implementation of default type parameter fallback.

If inference fails to determine an exact integral or floating point type, it
will set the type to i32 or f64, respectively.

Closes #16968
@emberian
Copy link
Member Author

@nikomatsakis there are now failures:

/home/cmr/rust/src/test/run-pass/traits-multidispatch-infer-convert-source-and-target.rs:35:5: 35:9 error: unable to infer enough type information about `_`; type annotations required
/home/cmr/rust/src/test/run-pass/traits-multidispatch-infer-convert-source-and-target.rs:35     test(Default::default(), Default::default(),  2, 4);
                                                                                                ^~~~
error: aborting due to previous error
/home/cmr/rust/src/test/run-pass/traits-multidispatch-infer-convert-target.rs:42:5: 42:9 error: unable to infer enough type information about `_`; type annotations required
/home/cmr/rust/src/test/run-pass/traits-multidispatch-infer-convert-target.rs:42     test(Default::default(), 44_u32, 2, 4);
                                                                                     ^~~~
error: aborting due to previous error

bors added a commit that referenced this pull request Dec 31, 2014
Doesn't yet converge on a fixed point, but generally works. A better algorithm
will come with the implementation of default type parameter fallback.

If inference fails to determine an exact integral or floating point type, it
will set the type to i32 or f64, respectively.

Closes #16968
Doesn't yet converge on a fixed point, but generally works. A better algorithm
will come with the implementation of default type parameter fallback.

If inference fails to determine an exact integral or floating point type, it
will set the type to i32 or f64, respectively.

Closes #16968
bors added a commit that referenced this pull request Jan 2, 2015
Doesn't yet converge on a fixed point, but generally works. A better algorithm
will come with the implementation of default type parameter fallback.

If inference fails to determine an exact integral or floating point type, it
will set the type to i32 or f64, respectively.

Closes #16968
@alexcrichton
Copy link
Member

If ok, it'd be nice to not jump the queue for backwards compatible changes like this. For example I've been trying to land the prelude stabilization for over a week now but it conflicts with just about everything. With only a week left until the alpha, we need to prioritize backwards-incompatible changes first. Thanks!

@bors bors merged commit 53ece71 into rust-lang:master Jan 2, 2015
@emberian
Copy link
Member Author

emberian commented Jan 2, 2015

Yes, sure. I've been manually scheduling PRs that had a priority above this one, didn't notice that that one was huge.

@steveklabnik
Copy link
Member

(on the plus side, I've been waiting for this to land forever, because it impacts docs very heavily, so I appreciate the jump)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Restore int fallback
9 participants