Proposal: Introducing a Unified Enum Data Structure

[Daniel Kukula]

I would like to start a discussion about adding a new enum data structure to the language.

From the Rust documentation: enums provide a way to express that a value is one of a possible set of predefined values.

I understand that the type system can solve some problems related to this, but I believe a dedicated data structure would be highly useful.

For example, I am working on a project that uses Ecto, Absinthe, and Protobuf. Each of these libraries defines its own enum type, which is incompatible with the others. While the Enum namespace is already taken, we could use alternatives like Variant, Choice, or Tag.

Having such a data structure defined at the language level would greatly simplify the process of sharing and translating enums across different libraries. This way, all libraries could rely on the same structure. For Ecto, if we wanted to store enums as integers, we could enforce a mapping that raises an error when not all possible values are covered.

Examples from other languages include enums in Python and Rust. In many other languages, module-level constants are often used for this purpose.

I’d love to hear your thoughts on this!

[José Valim]

Thank you for the proposal. In the best case scenario, it would be premature to do any improvement on this area before the type system is in place.

At the same time, it is worth noting that the libraries you mentioned could reach a consensus on a shared interface, without us having to pick something and force it downstream. In other words, the addition of the feature needs to be justified on its own merit: using the language to unify libraries can be a positive, but it should not be the root cause. More information on the features we consider can be found here: 

https://elixir-lang.org/development.html

[Zachary Daniel]

My colleague has done some excellent work in this direction in iterex: hexdocs.pm/iterex

On Dec 18, 2024, at 1:22 AM, José Valim <jose....@gmail.com> wrote:

Thank you for the proposal. In the best case scenario, it would be premature to do any improvement on this area before the type system is in place.

At the same time, it is worth noting that the libraries you mentioned could reach a consensus on a shared interface, without us having to pick something and force it downstream. In other words, the addition of the feature needs to be justified on its own merit: using the language to unify libraries can be a positive, but it should not be the root cause. More information on the features we consider can be found here: 

https://elixir-lang.org/development.html

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BsDHHq5ewW6DpHXTp0LEV%2BJznJczKze0YFd44HEN3Mgg%40mail.gmail.com.

[Austin Ziegler]

Macros or code generation are really going to be the way that this needs to be handled, because what Ecto needs with enums is very different from what Absinthe needs from enums (and the Ecto version differs *internally* across adapters, because the underlying database implementation of an enum type changes) and itself is likely different than what Protobuf needs (which probably mostly stores enum values as integers). I agree with the desire to have a common interface, as I spent months over the last several years trying to come up with ways to resolve our PostgreSQL enum types (implemented well before Ecto.Enum) with our GraphQL enum types (implemented in Absinthe).

The best that I found I couldn't use because it doesn't have a licence attached and predates the introduction of Ecto.Enum: https://gitlab.com/ex-open-source/enumex

I really don't think that this can be solved at the language level

-a

--

Austin Ziegler • halos...@gmail.com • aus...@halostatue.ca
http://www.halostatue.ca/ • http://twitter.com/halostatue

[Daniel Kukula]

Yes but the macros should be in ecto or absinthe. I was thinking of something simpler that ecto and absinthe can parse, not a universal data structure that will satisfy both cases. Now when you add a new value in ecto then absinthe will fail at runtime when receiving it. It should be catched when both share the same enum values.

--
You received this message because you are subscribed to a topic in the Google Groups "elixir-lang-core" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/elixir-lang-core/1JZytnG6xDw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/CAJ4ekQtyrzX4TMOX8MDTm4ATv0E0CaKGpKXwPsdsOqCqXr%2Bx%2BQ%40mail.gmail.com.

[Zach Daniel]

Oops, disregard my comment on iterex. It was early and I was bleary eyed 😂 It isn't that kind of enum.

On Dec 18, 2024, at 12:35 AM, Daniel Kukula <danie...@gmail.com> wrote:

Enum