Rust: Tracking issue for Range[Inclusive]::is_empty (feature range_is_empty)

[scottmcm]

These methods are a clear way to check for empty ranges without the restrictions of ExactSizeIterator.

Merged as unstable on 2018-02-15 in PR at https://github.com/rust-lang/rust/pull/48087

[jimblandy]

This method is really hard to use. In the program:

fn main() {
    println!("{:?}", (0..0).is_empty());
}

Rust 1.31 in the playground (which is 2018 Edition) complains:

error[E0034]: multiple applicable items in scope
 --> src/main.rs:2:29
  |
2 |     println!("{:?}", (0..0).is_empty());
  |                             ^^^^^^^^ multiple `is_empty` found
  |
  = note: candidate #1 is defined in an impl for the type `std::ops::Range<_>`
note: candidate #2 is defined in the trait `std::iter::ExactSizeIterator`
  = help: to disambiguate the method call, write `std::iter::ExactSizeIterator::is_empty(::std::ops::Range{start: 0, end: 0,})` instead

This arises without any imports in scope, just the prelude. Using std::ops::Range::is_empty doesn't help. Using:

<std::ops::Range<i32> as ExactSizeIterator>::is_empty(&(0..0))

does work, but is longer than x.len() == 0.

[kennytm]

@jimblandy The ambiguity happens only because you haven't enabled the relevant features. Assuming both ExactSizeIterator::is_empty and Range::is_empty are stabilized, using (0..0).is_empty() will always pick the latter since an inherent method has higher priority than a trait method.

#![feature(exact_size_is_empty, range_is_empty)]

use std::iter::ExactSizeIterator;

fn main() {
    println!("{:?}", (0..0).is_empty());
}

[scottmcm]

I believe that's an artifact of both being unstable, @jimblandy. With either or both feature gates enabled, it compiles fine (with a future warning if only the ESI gate is active):

#![feature(range_is_empty)]
#![feature(exact_size_is_empty)]
fn main() {
    println!("{:?}", (0..0).is_empty());
}

Edit: doh, 20 seconds late 😆

[jimblandy]

Okay, thanks for the explanation.

I guess I'm still surprised that the error message is about the ambiguity, not the use of unstable features; is it that rustc can't decide which unstable feature's use to complain about? ^^;;

[raindev]

Are there any outstanding concerns to be resolved before stabilization or is the issue just waiting for someone to send a pull request?

[yankana]

I have no idea why a method like this would be unstable, and the reason provided is kind of old, contradicting itself.

Also, why is it coded like this?
!(self.start < self.end)

Isn't it better to just have this?
self.start >= self.end

[scottmcm]

@raindev I know of no outstanding concerns, though of course such a stabilization PR would need a T-libs FCP. There was a question about whether it should use PartialOrd or Ord, but now that contains is stable using PartialOrd, I think that using PartialOrd here is the obvious answer.

Also, why is it coded like this?

@yankana because those two are only equivalent for Ord, but the function allows PartialOrd. See the second set of examples in the documentation.

[scottmcm]

To anyone following this tracking issue, I've made a PR to request stabilization of these methods: #75132