Unhelpful type error with PartialOrd ambiguity #71538
Labels
A-diagnostics
Area: Messages for errors, warnings, and lints
C-bug
Category: This is a bug.
D-incorrect
Diagnostics: A diagnostic that is giving misleading or incorrect information.
D-invalid-suggestion
Diagnostics: A structured suggestion resulting in incorrect code.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
In
num-bigint
master, we've implementedPartialEq
andPartialOrd
between the bigint types and the primitive integers. I'm reconsidering this, because I've experienced a lot of type inference failures from afar, in modules that aren't usingnum-bigint
at all. I'm not too surprised by that, because it really does add ambiguity, but some of the errors are not helpful.Here's a reduced example: playground
AFAICS the "needed for _" and the suggested "explicit type" are identical, and it doesn't change anything if I add that type on
array
anyway (usingndarray::Dim
instead of that private path). Besides,nrows()
always returnsusize
, and "cannot infer type for typeusize
" is nonsense.The last note about
PartialOrd<_>
is the only part that really seems relevant, although I think it could also mention thatu8::MAX.into()
is ambiguous. In this example,usize
implementsPartialOrd<usize>
andPartialOrd<Foo>
, andu8
implements lots ofInto<{integer}>
, though notInto<Foo>
. The compiler could match up the only answer,PartialOrd<usize>
andInto<usize>
, but I guess it's not that aggressive.In the full
num-bigint
case, we would haveu8: Into<BigInt> + Into<BigUint>
too, so then matchingPartialOrd
andInto
really is ambiguous even if the compiler tried harder.Meta
rustc --version --verbose
:The text was updated successfully, but these errors were encountered: