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

stabilize const mem::discriminant #73395

Closed
wants to merge 1 commit into from

Conversation

lcnr
Copy link
Contributor

@lcnr lcnr commented Jun 16, 2020

Changes mem::discriminant to be const stable starting at version 1.46.0

closes #69821

@rust-highfive
Copy link
Collaborator

r? @shepmaster

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 16, 2020
@lcnr lcnr force-pushed the stablize-mem-discriminant branch from 0f72adc to d3dacb6 Compare June 16, 2020 08:09
@jonas-schievink jonas-schievink added relnotes Marks issues that should be documented in the release notes of the next release. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jun 16, 2020
@jonas-schievink jonas-schievink added this to the 1.45 milestone Jun 16, 2020
@jonas-schievink jonas-schievink added the T-lang Relevant to the language team, which will review and decide on the PR/issue. label Jun 16, 2020
@oli-obk
Copy link
Contributor

oli-obk commented Jun 17, 2020

While I see no reason not to do this, I think the stabilization would benefit from at least mentioning a real world use case that would benefit from this or be possible only with this.

@lcnr
Copy link
Contributor Author

lcnr commented Jun 17, 2020

Now that matches! is stable, this is not as important anymore and cases where this might be actually needed are fairly rare. Apart from "this just feels like it should be const", which isn't really a good argument, it helps in cases where a match statement is not useable and the enum variant is hard to construct. We now have do it only once by using a constant.

enum Whatever {
    Variant(Foo, Bar, StructWithWierdInvariants),
    OtherVariant,
}

const WHATEVER_KIND_DISCR: Discriminant<Whatever> =
    mem::discriminant(&Whatever::Kind(...));

fn this_is_a_function(input: Whatever) {
    other_function_requiring_discriminant(input, WHATEVER_KIND_DISCR);
}

@oli-obk
Copy link
Contributor

oli-obk commented Jun 18, 2020

Apart from "this just feels like it should be const", which isn't really a good argument

That argument is enough for me :D

But I think we should keep waiting for a real use case, though I worry we won't get real use cases without it being stable :/

@bors
Copy link
Contributor

bors commented Jun 29, 2020

☔ The latest upstream changes (presumably #72437) made this pull request unmergeable. Please resolve the merge conflicts.

@lcnr lcnr closed this Jun 29, 2020
@crlf0710 crlf0710 removed the relnotes Marks issues that should be documented in the release notes of the next release. label Jul 8, 2020
@crlf0710 crlf0710 removed this from the 1.45 milestone Jul 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-lang Relevant to the language team, which will review and decide on the PR/issue. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Tracking Issue for const mem::discriminant
7 participants