diff options
| author | bors <bors@rust-lang.org> | 2018-04-16 16:07:10 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2018-04-16 16:07:10 +0000 |
| commit | 49317cd511fbb60178bd5122e484609568938468 (patch) | |
| tree | 8d89911dcf8d9baed771133f3382d8f471d9b800 /src/liballoc/string.rs | |
| parent | 1ef1563518d48ad9231b3ec3ac463d34d819ed28 (diff) | |
| parent | 51f24ec7f01b6a636750baff5ab5a12ec6bfe6cd (diff) | |
| download | rust-49317cd511fbb60178bd5122e484609568938468.tar.gz rust-49317cd511fbb60178bd5122e484609568938468.zip | |
Auto merge of #49130 - smmalis37:range, r=alexcrichton
Move Range*::contains to a single default impl on RangeBounds Per the ongoing discussion in #32311. This is my first PR to Rust (woo!), so I don't know if this requires an amendment to the original range_contains RFC, or not, or if we can just do a psuedo-RFC here. While this may no longer follow the explicit decision made in that RFC, I believe this better follows its spirit by adding the new contains method to all Ranges. It also allows users to be generic over all ranges and use this method without writing it themselves (my personal desired use case). This also somewhat answers the unanswered question about Wrapping ranges in the above issue by instead just punting it to the question of what those types should return for start() & end(), or if they should implement RangeArgument at all. Those types could also implement their own contains method without implementing this trait, in which case the question remains the same. This does add a new contains method to types that already implemented RangeArgument but not contains. These types are RangeFull, (Bound<T>, Bound<T>), (Bound<&'a T>, Bound<&'a T>). No tests have been added for these types yet. No inherent method has been added either. r? @alexcrichton
Diffstat (limited to 'src/liballoc/string.rs')
0 files changed, 0 insertions, 0 deletions
