`std::ops::RangeBounds::{start,end}_bound_inclusive`

[schuelermine]

Proposal

Problem statement

If you want your downstream consumers to be able to specify a range as input, and you want to manually iterate over that range in some way, you’ll need to get the bounds. Handling all of the bound variants is cumbersome, and it can’t be generic unless you use the unstable Step trait.

I propose

trait RangeBounds<T> {
    fn start_bound_inclusive(&self) -> Option<T>
    where
        T: Copy + Step;
    fn end_bound_inclusive(&self) -> Option<T>
    where
        T: Copy + Step;
}

which will step forward or backwards on the bound if it is excluded.

Alternatives

You can manually implement this, but it requires using Step, which is unstable.

Much of the time, you only need the start bound as a value, which is (as far as I can tell) never exclusive in std, and the end bound as a comparison target, which you can do generically without Step.

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[kennytm]

trait RangeBounds<T> {
    fn start_bound_inclusive(&self) -> Option<T>
    where
        T: Copy;
    fn end_bound_inclusive(&self) -> Option<T>
    where
        T: Copy;
}

which will step forward or backwards on the bound if it is excluded.

...

... and the end bound as a comparison target, which you can do generically without Step.

How to you know how to "step backward" without the Step bound? Let's say T = f64 or T = &'static str?

[schuelermine]

@kennytm I had forgotten to write the Step bound.

[schuelermine]

To clarify some more things:

1. I think this should call Step::forward and Step::backward, and as such panic if it goes out of range. This means (0..0u32).end_bound_inclusive would panic.
2. The reason this wouldn’t be on Bound is that the bound doesn’t know on which end it is.

[schuelermine]

@kennytm Oh, I may have misunderstood your question.
In the case of the lower bound, AFAIK all std ranges either have an unbounded lower end, or an inclusive lower bound.
That means you can just put unreachable!() in the case where it’s Excluded.
Which is fine, but not as neat.

[pitaj]

Why the Copy bound? Is it just so people don't accidentally clone large bounds?

[pitaj]

Also, why return Option if you propose using the panicking forward? These also must be provided methods otherwise you'd break backwards compatibility.

[kennytm]

Also, why return Option if you propose using the panicking forward? These also must be provided methods otherwise you'd break backwards compatibility.

I suppose OP wants to allow (1..).end_bound_inclusive()

[schuelermine]

@pitaj yes, dropping that bound is probably better

[scottmcm]

If you want your downstream consumers to be able to specify a range as input, and you want to manually iterate over that range in some way,

Wouldn't you take RangeBounds<T> + Iterator<Item = T> in that case?

---

Also, why is this on RangeBounds<T> instead of Bound<T>? Feels like it might want to return Result, too, to distinguish different cases. And maybe have into_exclusive, not just into_inclusive?

If all you do with the RangeBounds is turn it into a RangeInclusive type to iterate it, does it even make sense to take an impl RangeBounds?

[schuelermine]

@scottmcm

1. It gives the caller more options. The same reason that you can use both .. and ..= for normal for loops. Obviously the caller can just do the conversion themselves, but that’s the case pretty much all of the time.
2. It’s on RangeBounds because the Bound doesn’t know if it’s at the beginning or the end. The current API leaves open the possibility that an implementing type might have an exclusive lower bound, which means that the lower bound needs to be decreased to make it inclusive.

[cuviper]

2. It’s on RangeBounds because the Bound doesn’t know if it’s at the beginning or the end.

That's fine if the methods explicitly request treatment one way or the other, e.g. into_inclusive_start/end. A Bound::Excluded could adjust itself either direction.

[pitaj]

I'd rather see something like this added to IntoBounds instead:

trait IntoBounds<T> {
    // existing methods...

    /// Converts exclusive bounds to inclusive, if necessary 
    /// 
    /// Returned bounds can only be `Included` or `Unbounded`
    fn into_inclusive(self) -> (Bound<T>, Bound<T>)
    where T: Step
    {
        ....
    }

    /// Converts start bound to inclusive and end bound to exclusive, if necessary 
    ///
    /// Returned bounds can only be `(Unbounded | Included(_), Unbounded | Excluded(_))`
    fn into_exclusive_ended(self) -> (Bound<T>, Bound<T>)
    where T: Step
    {
        ....
    }
}