Skip to content

Require explicit stabilization of the constness of functions #58775

Closed
Closed
Require explicit stabilization of the constness of functions#58775
Labels
A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)A-stabilityArea: `#[stable]`, `#[unstable]` etc.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

Description

@oli-obk
oli-obk
opened on Feb 27, 2019

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

Activity

  1. oli-obk
    added
    T-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.
    A-stabilityArea: `#[stable]`, `#[unstable]` etc.
    T-langRelevant to the language team
    T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.
    on Feb 27, 2019
  2. Centril
    added
    A-const-fn
    on Feb 27, 2019

  3. Centril commented on Feb 27, 2019

    @Centril
    Centril
    on Feb 27, 2019
    Contributor

    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?

  4. TimDiekmann commented on Feb 27, 2019

    @TimDiekmann
    TimDiekmann
    on Feb 27, 2019
    Contributor

    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.

  5. petrochenkov commented on Feb 27, 2019

    @petrochenkov
    petrochenkov
    on Feb 27, 2019
    Contributor

    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.

  6. Centril commented on Feb 27, 2019

    @Centril
    Centril
    on Feb 27, 2019
    Contributor

    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.

  7. TimDiekmann commented on Feb 28, 2019

    @TimDiekmann
    TimDiekmann
    on Feb 28, 2019
    Contributor

    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 ...

  8. Centril commented on Feb 28, 2019

    @Centril
    Centril
    on Feb 28, 2019
    Contributor

    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.

  9. RalfJung commented on Sep 21, 2020

    @RalfJung
    RalfJung
    on Sep 21, 2020
    Member

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

  10. oli-obk commented on Sep 21, 2020

    @oli-obk
    oli-obk
    on Sep 21, 2020
    ContributorAuthor

    Yes

  11. oli-obk
    closed this as completedon Sep 21, 2020
  12. RalfJung
    added
    A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)
    on Dec 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-const-evalArea: Constant evaluation, covers all const contexts (static, const fn, ...)A-stabilityArea: `#[stable]`, `#[unstable]` etc.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamT-rustdocRelevant to the rustdoc team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions