Potential `len` method ambiguity in `src/range.rs` about rayon HOT 5 CLOSED

Understood, so we could rename UnindexedRangeLen::len to something else to avoid the ambiguity. However, this also suggests that the change would need to happen at an edition boundary, i.e. be opt-in and we should be fine as long as build against the current edition.

from rayon.

we assume Range and Range does not implement ExactSizeIterator.

I would say it is the other way around: We do not assume that they do implement ExactSizeIterator.

I am not sure what you mean by "break" if such an implementation was added to the standard library? From my understanding, Rayon would just not automatically take advantage of it, but everything should continue to work as it does now, shouldn't it?

In any case, we should not move here before the std does, i.e. there is not just a decision, but the feature is published and available in Rayon's MSRV.

from rayon.

One can check this failed action once we add the implementation it will gives a compile error.

from rayon.

Ambiguous method resolution is a risk for any standard library addition. I don't think it's fair to call that "unrobust" here, because the only perfect way to defend against it is to use fully-qualified syntax for all trait method calls. This risk is acknowledged as a "minor change" in the API evolution RFC, and the Rust Project uses its crater tool to judge the practical impact -- though it's more obvious when it breaks a library used by the toolchain itself, as you found.

https://rust-lang.github.io/rfcs/1105-api-evolution.html#minor-change-implementing-any-non-fundamental-trait

However, this also suggests that the change would need to happen at an edition boundary,

AIUI, the compiler has no ability to consider editions during trait/method resolution. I don't know if that's a fundamental limitation, or just something that hasn't been implemented or would be very difficult. So in the current situation, the library team will weigh the benefit of such additions against the crater impact and decide all or nothing.

I'm not totally opposed to renaming internal implementation details like UnindexedRangeLen::len, but I'm pretty skeptical that the upstream API team will want to add these new ExactSizedIterator impls at all.

from rayon.

I see. So this proposal is under discussion in rust-lang/libs-team#369 because I'm afraid of there are more example that "implicitly" "assume some trait are not implemented".

from rayon.