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

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

Open
scottmcm opened this issue Feb 10, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@scottmcm
Copy link
Member

commented Feb 10, 2018

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 comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 7, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Dec 7, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

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

This comment has been minimized.

Copy link
Contributor

commented May 28, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.