diff options
| author | kennytm <kennytm@gmail.com> | 2018-02-14 16:14:33 +0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2018-02-14 16:14:33 +0800 |
| commit | bd3674e4def219b22b3d5a3c3871569b0b153236 (patch) | |
| tree | 025f5070b62192cd7039870141a720dfd67796fc /src/rustllvm/RustWrapper.cpp | |
| parent | 3715f1e490e187c3635ef241104bd5abe119958b (diff) | |
| parent | 22b0489f80dae5242f19c4ce892b50d3685dbf82 (diff) | |
| download | rust-bd3674e4def219b22b3d5a3c3871569b0b153236.tar.gz rust-bd3674e4def219b22b3d5a3c3871569b0b153236.zip | |
Rollup merge of #48087 - scottmcm:range_is_empty, r=kennytm,alexcrichton
Add Range[Inclusive]::is_empty During https://github.com/rust-lang/rfcs/pull/1980, it was discussed that figuring out whether a range is empty was subtle, and thus there should be a clear and obvious way to do it. It can't just be ExactSizeIterator::is_empty (also unstable) because not all ranges are ExactSize -- such as `Range<i64>` and `RangeInclusive<usize>`. Things to ponder: - Unless this is stabilized first, this makes stabilizing ExactSizeIterator::is_empty more icky, since this hides that. - This is only on `Range` and `RangeInclusive`, as those are the only ones where it's interesting. But one could argue that it should be on more for consistency, or on RangeArgument instead. - The bound on this is PartialOrd, since that works ok (see tests for float examples) and is consistent with `contains`. But ranges like `NAN..=NAN`_are_ kinda weird. - [x] ~~There's not a real issue number on this yet~~
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
