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 2018-02-15 in PR at #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? ^^;;