Tracking Issue for MAIN_SEPARATOR_STR

[SUPERCILEX]

Feature gate: #![feature(main_separator_str)]

This is a tracking issue for adding a static path separator str to match the static char already available.

Public API

pub const MAIN_SEPARATOR: char = '/';
pub const MAIN_SEPARATOR_STR: &str = "/";

Steps / History

• Implementation: Add MAIN_SEPARATOR_STR #93976
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

Can we combine the char and str API into one type that AsRefs to char, str, u8 etc. as needed?

[kamellperry]

What's the status on this?

[SUPERCILEX]

Probs still waiting on using AsRef.

[SUPERCILEX]

@yaahc I gave your idea a go, but I don't think it makes sense:

pub struct Separator;

impl Separator {
    pub const STR: &str = crate::sys::path::MAIN_SEP_STR;
    pub const CHAR: char = crate::sys::path::MAIN_SEP;
}

impl Deref for Separator {
    type Target = str;

    fn deref(&self) -> &Self::Target {
        Self::STR
    }
}

impl AsRef<str> for Separator {
    fn as_ref(&self) -> &str {
        self
    }
}

impl AsRef<char> for Separator {
    fn as_ref(&self) -> &char {
        &Self::CHAR
    }
}

Hiding the str and char behind a type doesn't really help because the type isn't opaque. People are presumably coming to do low-level stuff with the &str or char so we can't get rid of those constants. Maybe if every API had been designed from the start to take in a Separator this would have made more sense, but as it stands I actually think having a MAIN_SEP_STR constant is perfectly reasonable. At the very least, adding this constant doesn't block any future work (it would just get deprecated/forgotten).

On that note, how do I start an FCP?

[klensy]

In topic: path separator named static when in actually const, but in this example it have possibly no difference.