Tracking Issue for `const_arguments_as_str`

Feature gate: #![feature(const_arguments_as_str)]

This is a tracking issue for const fmt::Arguments::as_str.
Note that the original PR didn't create a tracking issue.

Public API

// core::fmt

impl<'a> Arguments<'a> {
    #[stable(feature = "fmt_as_str", since = "1.52.0")]
    #[rustc_const_unstable(feature = "const_arguments_as_str", issue = "103900")]
    pub const fn as_str(&self) -> Option<&'static str>;
}

Steps / History

• Implementation: Make fmt::Arguments::as_str unstably const #86655
• Mention tracking issue in feature gate: Add tracking issue for const_arguments_as_str #103901
• Final comment period (FCP)¹
• Stabilization PR

Unresolved Questions

• None yet.

Footnotes

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

[RalfJung]

The function list in the issue description is outdated, this feature gate now also includes

impl<'a> PanicMessage<'a> {
    pub const fn as_str(&self) -> Option<&'static str>;
}

(For some reason I can't edit the issue description...)

@rust-lang/libs-api Given that this has been regular-stable for a while, is there any reason not to make them const-stable as well? The implementations are trivial, and in fact they are already indirectly exposed on stable via the const panic machinery (specifically, it gets called in const_panic_fmt).

The main reason not to do this is that these functions cannot be actually called in const fn since you can't construct Arguments/PanicMessage in const context. But if that's the argument then IMO we should turn this into an internal feature gate that doesn't need a tracking issue (and PanicMessage::as_str can be fully de-constified).

[dtolnay]

these functions cannot be actually called in const fn since you can't construct Arguments/PanicMessage in const context.

This is usually not a compelling counterargument because const is still relevant for cases like:

const fn f(thing: Option<&Arguments>) {
    ...
    if let Some(thing) = thing {
        thing.as_str() ...
    }
    ...
}

and not having const on as_str can necessitate needlessly complicated workarounds.

@rust-lang/libs-api: this feature requires making the commitment that future designs of core::fmt::Arguments will not involve putting the string message from format_args!("...") behind a virtual function call, as in pub struct Arguments<'a> { repr: &'a dyn FmtRepr<'a> }.

@rfcbot fcp merge

[rfcbot]

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[RalfJung]

this feature requires making the commitment that future designs of core::fmt::Arguments will not involve putting the string message from format_args!("...") behind a virtual function call, as in pub struct Arguments<'a> { repr: &'a dyn FmtRepr<'a> }.

Or if we do add such an indirection then it has to be dyn const FmtRepr or so -- something like that could conceivably exist.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔