Require explicit stabilization of the constness of functions

[oli-obk]

Right now:

• if you have an unstable const function and you stabilize it, you automatically stabilize the constness, too.
• if you have a stable non-const function, adding const to it will automatically stabilize the constness
• You can opt-out of the stability of the constness of a function via rustc_const_unstable

What's missing is the ability to explicitly mark the constness as stable, just like we have an explicit scheme to mark items as stable. This would prevent accidental stablization of any constness. Not that any has happened so far, but #58750 (comment) made me realize that it's not always easy to gauge the stability of constness.

It might also be helpful if documentation showed since when the constness has been stabilized.

cc @Centril @varkor

[Centril]

cc #57562 (comment)
cc @rust-lang/libs @rust-lang/rustdoc

So... re. semantics, I think #[const_stable(..)] should have the semantics that:

• If #[const_stable(..)] is attached:
  • If not staged_api => error
  • If item is not const fn => error
  • If #[const_unstable(..)] attached => contradiction! => error
  • If #[stable(..)] is not attached => error
  • Else => require min_const_fn
• Else:
  • If not staged_api => same semantics as today.
  • If item is not const fn => same semantics as today.
  • If #[const_unstable(..)] attached => same semantics as today.
  • If #[stable(..)] is not attached => ???
    -- What do we do for internal APIs?
    -- Do we have protections against accidental omissions of #[stable(..)]?
  • Else => require min_const_fn

Is there any case I missed?

[TimDiekmann]

I have an idea for an alternative without introducing even more attributes: Add a const_since parameter to #[stable(..)]. I don't know if you can cover all mentioned cases with it, but I wanted to share thoughts once.

[petrochenkov]

It would probably be simpler and less error-prone to add modifiers to #[rustc_stable] and #[rustc_unstabe] than to introduce new attributes for const stability.

[Centril]

You'd also need a way to name the feature-gate, not just the equivalent of since, e.g.

#[stable(
    feature = "option_xor", since = "...",
    const_feature = "const_option_xor", const_since = "...",
)]

#[unstable(
    feature = "option_xor", issue = "50512",
    const_feature = "option_xor", const_issue = "50512",
)]

If const_feature is omitted, we can assume the feature gate name is the same as the usual one.

This hasn't really addressed the ??? part tho; only repainted the syntax.

[TimDiekmann]

This hasn't really addressed the ??? part tho

We don't have to care, as we cannot stabilize a const fn without the non-const fn

I'd go this way:

• if #[stable(..)] is attached:
  • has const_since:
    • item is not const fn => error
    • is not min_const_fn => error
    • has not const_feature:
      • const_since != since => error
      • else: success => uses feature as gate
    • has const_feature => success => uses const_feature as gate
  • else
    • has #[unstable(const_feature = "...")] => success
    • else => error
• else:
  • success

Every other case should have been captured by #[stable(..)]/#[unstable(..)].

Examples:

/// Uses `option_xor` for both, const and non-const
#[stable(
    feature = "option_xor", since = "1.34", const_since = "1.34",
)]
const fn ...

/// Error
#[stable(
    feature = "option_xor", since = "1.34", const_since = "1.35",
)]
const fn ...

/// Fine (no #[stable(..)])
const fn ...

/// Fine
#[stable(
    feature = "option_xor", since = "1.34", 
    const_feature = "const_option_xor", const_since = "1.35",
)]
const fn ...

/// Error (no `const_since` and no `#[unstable(feature = "...")]`)
#[stable(
    feature = "option_xor", since = "1.34", 
)]
const fn ...

/// Fine
#[stable(
    feature = "option_xor", since = "1.34", 
)]
#[unstable(const_feature = "const_option_xor", const_issue = "50512")]
const fn ...

/// Error: not a `const fn`
#[stable(
    feature = "option_xor", since = "1.34", 
)]
#[unstable(const_feature = "const_option_xor", const_issue = "50512")]
fn ...

[Centril]

We don't have to care, as we cannot stabilize a const fn without the non-const fn

I don't think this actually requires explicit stabilization in full. You do reduce some of the risk and it serves as better documentation, but you also do not cover the case when there's no #[stable(..)] for a stably exposed function. However, this is a general problem with #[stable(..)] not exclusive to const fns.

As long as we are cognizant of what problems we solve and which we don't, then I think your solution will work well.

[RalfJung]

@oli-obk isn't this resolved by #[rustc_const_stable]?

[oli-obk]

Yes