Skip to content

Cast a number to a c-style enum #2132

New issue

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

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

Already on GitHub? # to your account

Closed
jamorton opened this issue Apr 5, 2012 · 10 comments
Closed

Cast a number to a c-style enum #2132

jamorton opened this issue Apr 5, 2012 · 10 comments
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.

Comments

@jamorton
Copy link
Contributor

jamorton commented Apr 5, 2012

It doesn't seem there is any way to do this:

enum foo { X, Y, Z }
let v : foo = 1 as foo;

( v == Y )

Useful for interfacing with c libraries, writing DCPU16 emulators (!!!), etc. Possible?

@marijnh
Copy link
Contributor

marijnh commented Apr 5, 2012

I think unsafe::reinterpret_cast will do this, but there's no safe way yet (it'd require checking whether the int is a valid value for this enum).

@jamorton
Copy link
Contributor Author

jamorton commented Apr 5, 2012

Yeah, I ended up doing:

enum basic_opcode { ... }
fn basic_opcode(v: uint) -> basic_opcode {
    unsafe { unsafe::reinterpret_cast(v) }
}

but it would be nice to have this as a feature of "as".

@catamorphism
Copy link
Contributor

Could this be another use for overloaded integer literals? Or would that be a bridge too far?

@catamorphism
Copy link
Contributor

In any case, marking as RFC since it is a language change.

@marijnh
Copy link
Contributor

marijnh commented Apr 5, 2012

I don't think the actual use case involved a literal—if you already know, when writing the code, which value you want, you should probably write the variant's name anyway. Autoconverting literals to enum values seems like a bad idea.

@jamorton
Copy link
Contributor Author

jamorton commented Apr 5, 2012

yeah, that was a bit of a contrived example. I actually wanted to convert some arbitrary uint data into an opcode enum for alting

@nikomatsakis
Copy link
Contributor

This seems like a case for a macro. Something that will generate a function foo_from_uint(x: uint) -> option<foo>

@catamorphism
Copy link
Contributor

@marijnh Quite right -- I wasn't thinking.

@brson
Copy link
Contributor

brson commented Sep 25, 2012

Doing it with a macro would require that the macro also define the enum, so that it knows the names and values, which I think would make for an ugly enum declaration. I would maybe prefer to use an attribute.

This could also be done with reflection and I think it should: enum::from_int<T: CLikeEnum>(int) -> T. Could be implemented in a number of ways. You would have to introduce a new compiler generated trait for c-like enums, or have dynamic failures if T isn't one.

@graydon
Copy link
Contributor

graydon commented May 1, 2013

continues in #3868 , closing this as a dupe

@graydon graydon closed this as completed May 1, 2013
bors added a commit that referenced this issue Sep 21, 2017
Implement `Copy`/`Clone` for closures

Implement RFC [#2132](rust-lang/rfcs#2132) (tracking issue: #44490).

NB: I'm not totally sure about the whole feature gates thing, that's my first PR of this kind...
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
- Change `#[kani::proof]` expansion so it doesn't include `#[no_mangle]` but includes `[allow(dead_code)]`. (rust-lang#661 and rust-lang#689).

- Add a check for harnesses with arguments and merge the checks into one function (rust-lang#1919). 

Co-authored-by: Zyad Hassan <88045115+zhassan-aws@users.noreply.github.com>
Kobzol pushed a commit to Kobzol/rust that referenced this issue Dec 30, 2024
bors pushed a commit to rust-lang-ci/rust that referenced this issue Jan 2, 2025
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
A-type-system Area: Type system C-enhancement Category: An issue proposing an enhancement or a PR with one.
Projects
None yet
Development

No branches or pull requests

6 participants