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

ICE using enum discriminator in constant expression #4926

Closed
jdm opened this issue Feb 14, 2013 · 4 comments
Closed

ICE using enum discriminator in constant expression #4926

jdm opened this issue Feb 14, 2013 · 4 comments
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Milestone

Comments

@jdm
Copy link
Contributor

jdm commented Feb 14, 2013

rusti> enum A { A1, A2 }
rusti> let a = A1 as uint;
rusti> const b: uint = A1 as uint;
<anon>:37:16: 37:26 error: internal compiler error: Impossible case reached: bad combination of types for cast
<anon>:37 const b: uint = A1 as uint;
                          ^~~~~~~~~~
rust: task failed at 'explicit failure', /run/media/jdm/ssd/rust/src/libsyntax/diagnostic.rs:69

This should be allowed.

@orenbenkiki
Copy link

Question: Does it make sense to also allow:

  • Safe, checked cast in the opposite direction, at least for the case when the enum constructors have no parameters (that is, let index: uint = 0; index as SomeEnum)?

If interfacing with FFI, both conversion directions would be needed... And it also allows writing some nifty generic code that would work for "every enum".

  • Querying the type system for the total number of constructors (possibly via the type descriptor)? e.g. (hypothetical unrealistic syntax) SomeEnum as uint?

In C/C++ there's a pattern of defining a final fake enum value to allow for querying the compiler for the number of real values. This is OK there because the compiler doesn't enforce switch statements etc. to cover all values. In Rust, adding such a fake value would pollute every match statement on the enum, otherwise it wouldn't be complete.

(Or maybe these are already possible and I just don't know the incantations...?)

@nikomatsakis
Copy link
Contributor

On Sat, Nov 09, 2013 at 05:25:33AM -0800, Oren Ben-Kiki wrote:

Question: Does it make sense to also allow:

  • Safe, checked cast in the opposite direction, at least for the
  • case when the enum constructors have no parameters (that is, `let
  • index: uint = 0; index as SomeEnum`)?

Use the FromPrimitive trait, which I believe is derivable.

  • Querying the type system for the total number of constructors
  • (possibly via the type descriptor)? e.g. (hypothetical unrealistic
  • syntax) SomeEnum as uint?

It appears we don't have a trait for this. I think we should. Probably
we should just have a trait like "CLikeEnum" (probably with a better
name):

trait CLikeEnum  : FromPrimitive, ToPrimitive {
    fn last() -> Self; // Returns the "last" enum, traditionally the one with maximum value
}

@orenbenkiki
Copy link

FromPrimitive and ToPrimitive work great, thanks!

CLikeEnum could probably be renamed to RangeEnum, and, possibly, provide an iterator over all the values, as well as a count/last value?

@nikomatsakis
Copy link
Contributor

CLikeEnum could probably be renamed to RangeEnum, and, possibly, provide an iterator over all the values, as well as a count/last value?

Yes!

@jdm jdm removed their assignment Jun 16, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-frontend Area: Compiler frontend (errors, parsing and HIR) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
Projects
None yet
Development

No branches or pull requests

4 participants