Tracking Issue for OneSidedRange

[cramertj]

Feature gate: #![feature(one_sided_range)]

This is a tracking issue for the OneSidedRange trait, used in the signature of (stable) [T]::splt_off and similar API.

Public API

// core::ops

pub enum OneSidedRangeBound {
    StartInclusive,
    End,
    EndInclusive,
}

pub const trait OneSidedRange<T>: RangeBounds<T> {
    fn bound(self) -> (OneSidedRangeBound, T);
}

impl<T> OneSidedRange<T> for RangeTo<T>
where
    Self: RangeBounds<T>,
{
    fn bound(self) -> (OneSidedRangeBound, T);
}

impl<T> OneSidedRange<T> for RangeFrom<T>
where
    Self: RangeBounds<T>,
{
    fn bound(self) -> (OneSidedRangeBound, T);
}

impl<T> OneSidedRange<T> for RangeToInclusive<T>
where
    Self: RangeBounds<T>,
{
    fn bound(self) -> (OneSidedRangeBound, T);
}

Steps / History

(Remember to update the S-tracking-* label when checking boxes.)

• ACP: rust-lang/libs-team#...
• Implementation: Add slice take methods #88502
• Final comment period (FCP)¹
• Stabilization PR

Related: tracking issue for slice_take #62280

Unresolved Questions

• Should this trait be perma-unstable, stablized as sealed, or stabilized without restriction? Tracking issue for slice_take #62280 (comment)
• Should this move to core::range?

Footnotes

1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

[KodrAus]

Since the linked implementation PR was closed (just from inactivity) we don't really have a feature to track here yet. I'll go ahead and close this one now, but if #62282 resurfaces in the future we can re-open this!

[its-the-shrimp]

Should this be reopened now that OneSidedRange is on nightly? No clue when it got there, but it is most definitely there, my eyes don't deceive me

https://doc.rust-lang.org/std/ops/trait.OneSidedRange.html

[its-the-shrimp]

Also, should this trait be unsafe? Since the guarantee of

must return Bound::Unbounded from one of RangeBounds::start_bound or RangeBounds::end_bound.

Can't be represented by this trait directly (in its current form at least)

Making it unsafe will allow for the following use of it:

fn f<T>(x: impl OneSidedRange<T>) {
    match (x.start_bound(), x.end_bound()) {
        (start, Bound::Unbounded) => todo!(),
        (Bound::Unbounded, end) => todo!(),
        _ => unsafe { // Safety: guaranteed by `OneSidedRange`
            std::hint::unreachable_unchecked()
        }
    }
}

Another possibility is the following API for this trait:

enum OnlyBound<T> {
    Start(Bound<T>),
    End(Bound<T>),
}

trait OneSidedRange<T>: RangeBounds<T> {
    fn bound(&self) -> OnlyBound<T> {
        match (self.start_bound(), self.end_bound()) {
            (start, Bound::Unbounded) => OnlyBound::Start(start),
            (Bound::Unbounded, end) => OnlyBound::End(end),
            _ => unreachable!(),
        }
    }
}

[tgross35]

Reopening as it this does indeed exist and the tracking issue points here, added in #88502. See #62280 for some discussion about what to do with these traits (added as unresolved questions).

[tgross35]

These types should probably move to the newly stable core::range. Added an unresolved question so we don't forget it.