3 ms·

Well, apparently it was fixed with `enum class`… until it was unfixed in C++17 for unfathomable reasons. It’s honestly crazy that C++ doesn’t have simple exhaus

Well, apparently it was fixed with `enum class`… until it was unfixed in C++17 for unfathomable reasons. It’s honestly crazy that C++ doesn’t have simple exhaustiveness-checked enums. The obvious actual solution for the valid use case of deserializing an enum from an integer would be something like template<E> std::optional<E> from_underlying(std::underlying_type<E>) requires(std::is_enum_v<E>)

bluGill 2y ago
an event loop often wants an event type enum that has defined values for internal events and then everything out of range means pass onto the users handler. There are other variations where you need to pass an enum value without caring what it mean.
- Nullabillity 2y ago
  This isn't rocket science once you have sum types. enum Event<T> { System(SystemEvent), User(T), }
  - account42 2y ago
    Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations. Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution.
    - Nullabillity 2y ago
      > Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations. data Event = System SystemEvent | User a > Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution. Virtually all event systems end up carrying auxilary event data of some form, so sum types are what you want regardless.
  - bluGill 2y ago
    At least in C++ a template needs to be known at compile time, but I want to build my event loop and latter add in more values that should be handled without rebuilding it.
    - Nullabillity 2y ago
      You could make your `T` type as dynamic as you want it to be.
Thorrez 2y ago
It wasn't unfixed in C++17. The problem existed before C++17. This is valid code in C++11: enum class Foo : int { Invalid = 0 }; Foo f = Foo(5); In C++11, this compiles with Foo(5) but not Foo{5}. In C++17, this compiles with both Foo(5) and Foo{5}.
- gpderetta 2y ago
  IIRC for a brief period GCC considered values outside of the enumeration as UB and heavily optimized according to this. At some point this interpretetion made it as far as at least a draft standard. Then it got reverted as it went against decades of common usages and instead the opposite was made explicit in the standard. Making it UB for enum classes was considered, but the strongly typeded alias use case was considered safer and more useful.
  - account42 2y ago
    Unfortunate. Then again, constraint value integer types are something that would be useful in general and perhaps can be provided independently of enum class.
- Sharlin 2y ago
  Uf, I see, thanks. I could’ve sworn that this was one of the things enum class was supposed to fix.

bluGill 2y ago

an event loop often wants an event type enum that has defined values for internal events and then everything out of range means pass onto the users handler. There are other variations where you need to pass an enum value without caring what it mean.

Nullabillity 2y ago
This isn't rocket science once you have sum types. enum Event<T> { System(SystemEvent), User(T), }
- account42 2y ago
  Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations. Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution.
  - Nullabillity 2y ago
    > Using Rusts' retarded enum keyword for your example doesn't exactly make your point understandable, especially when talking in the context of actual enumerations. data Event = System SystemEvent | User a > Anyway, the point of what gp describes is to do this in a single integer without overhead so a naive sum type is not the solution. Virtually all event systems end up carrying auxilary event data of some form, so sum types are what you want regardless.
- bluGill 2y ago
  At least in C++ a template needs to be known at compile time, but I want to build my event loop and latter add in more values that should be handled without rebuilding it.
  - Nullabillity 2y ago
    You could make your `T` type as dynamic as you want it to be.

Thorrez 2y ago

It wasn't unfixed in C++17. The problem existed before C++17. This is valid code in C++11: enum class Foo : int { Invalid = 0 }; Foo f = Foo(5); In C++11, this compiles with Foo(5) but not Foo{5}. In C++17, this compiles with both Foo(5) and Foo{5}.

gpderetta 2y ago
IIRC for a brief period GCC considered values outside of the enumeration as UB and heavily optimized according to this. At some point this interpretetion made it as far as at least a draft standard. Then it got reverted as it went against decades of common usages and instead the opposite was made explicit in the standard. Making it UB for enum classes was considered, but the strongly typeded alias use case was considered safer and more useful.
- account42 2y ago
  Unfortunate. Then again, constraint value integer types are something that would be useful in general and perhaps can be provided independently of enum class.
Sharlin 2y ago
Uf, I see, thanks. I could’ve sworn that this was one of the things enum class was supposed to fix.