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

[SUGGESTION] Creating an enum instance from a raw integer #1217

Open
tsoj opened this issue Aug 7, 2024 · 6 comments
Open

[SUGGESTION] Creating an enum instance from a raw integer #1217

tsoj opened this issue Aug 7, 2024 · 6 comments

Comments

@tsoj
Copy link
Contributor

tsoj commented Aug 7, 2024

In case I didn't miss anything, it is currently not possible to create an enum instance from a raw integer.

If the values of enum instances should matter at all (which is suggested by the possibility to assign custom values to specific enum members, and by the existence of get_raw_value()), then I believe it should also be possible to create an enum instance from an integer.

A specific use case I have in mind:

Square: @enum<u8> type = {
    a1; b1; c1; d1; e1; f1; g1; h1;
    ...
    a8; b8; c8; d8; e8; f8; g8; h8;
    noSquare;
}

flip: (s: Square) -> Square == Square(s.get_raw_value() ^ 56); // e.g. a1 becomes a8 or e5 becomes e4

Ways to make something like this possible could be:

  • Make the enum constructor operator= : (implicit out this, _val: i64) public.
  • A specific static function (Square::from_raw_value(val: i64)) to make clear that converting an integer into an enum is an unusual/dangerous operation
  • Making the underlying value public, which, while being a bit questionable, would also solve [SUGGESTION] Allow @enum classes as template type arguments #1147.
@tsoj tsoj added the suggestion label Aug 7, 2024
@tsoj tsoj changed the title Creating an enum instance from a raw integer [SUGGESTION] Creating an enum instance from a raw integer Aug 7, 2024
@farmerpiki
Copy link
Contributor

I like the idea... but maybe the syntax should be get_underlying and set_underlying ... possibly value as well, so we don't deviate so much from how people are used to using enums and enum classes, where currently you have to cast from/to std::underlying_type_t and you could look for underlying in both cpp1 and cpp2 at the same time to detect potential issues.

I'm curious how others feel about this as well.

@DyXel
Copy link
Contributor

DyXel commented Aug 9, 2024

In my opinion, to get the raw value we should just be able to cast, for example, by saying s as u8. To set the raw value, we probably should have a escape hatch yes, but I would like this escape hatch to come both in checked and unchecked flavors, I think maybe a pre-condition that can be optimized away could be good to cover both cases with a single function / constructor.

@dwmckee
Copy link

dwmckee commented Aug 9, 2024

In my opinion, to get the raw value we should just be able to cast, for example, by saying s as u8. To set the raw value, we probably should have a escape hatch yes, but I would like this escape hatch to come both in checked and unchecked flavors, I think maybe a pre-condition that can be optimized away could be good to cover both cases with a single function / constructor.

Being able to get the raw value with as is my suggestion #816, though I would leave the existing get_raw_value method for the pure readability of the thing. And @gregmarr was working on it as part of a larger refactor of as (#701, I think), but that effort seems to have stalled.

My sense is that as was meant to be always safe, so using it for type conversion to @enum type would have to be checked.

@DyXel
Copy link
Contributor

DyXel commented Aug 9, 2024

My sense is that as was meant to be always safe, so using it for type conversion to @enum type would have to be checked.

It is always safe to get the underlying value, so the as cast should be safe. The other way around (u8 -> @enum) wouldn't be a cast, but a explicit constructor or a static member function that acts as a constructor.

@gregmarr
Copy link
Contributor

gregmarr commented Aug 9, 2024

And @gregmarr was working on it

Not me, sorry.

@dwmckee
Copy link

dwmckee commented Aug 9, 2024

And @gregmarr was working on it

Not me, sorry.

Apologies.

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

No branches or pull requests

5 participants