Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rustdoc rendering for stable-but-const-unstable const fn is misleading #86464

Closed
RalfJung opened this issue Jun 19, 2021 · 5 comments · Fixed by #86473
Closed

rustdoc rendering for stable-but-const-unstable const fn is misleading #86464

RalfJung opened this issue Jun 19, 2021 · 5 comments · Fixed by #86473
Assignees

Comments

@RalfJung
Copy link
Member

RalfJung commented Jun 19, 2021

I just spent 5min of horror after seeing this rustdoc page:
Screenshot 2021-06-19 at 10-07-35 f32 - Rust

and then I realized that the constness of this function is unstable. rustdoc should either indicate that, or just not show the const at all for stable functions whose constness is still unstable.

Cc @rust-lang/rustdoc @rust-lang/wg-const-eval

@RalfJung RalfJung changed the title rustdoc rendering for unstable const fn is misleading rustdoc rendering for stable-but-const-unstable const fn is misleading Jun 19, 2021
@Nemo157
Copy link
Member

Nemo157 commented Jun 19, 2021

It'd be nice to still show that it's unstably const, but I feel like my 2 minute prototype would be too easy to accidentally skim as a standard "unstable API" annotation. Is there some simple way we could link to the constification tracking issue while leaving it clear that the function is stable?

image

@GuillaumeGomez
Copy link
Member

Not show the const on stable rendering if not stable?

@fee1-dead
Copy link
Member

Why not like this?

image

(this is edited)

@GuillaumeGomez
Copy link
Member

That works too!

@fee1-dead
Copy link
Member

@rustbot claim

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants