Thanks for the question.

I’ve never used ex_const so my answer probably won’t be complete but here are the main differences I noticed.

First of all, you must know that when writing SimpleEnum, I got a lot of inspiration from how Enumerations work in C++. This explains some of my design choices like the fact that it is impossible to have 2 times the same key in an Enum.

Difference 1: with ex_const, an Enum can have duplicates keys and values.
This is a valid code :

enum type do
    key1 	0
    key1	1
    key1	1
end

iex> Enums.type(:key1)
0

Here SimpleEnum will raise an exception at compile time:

defenum :type, [key1: 0, key1: 1, key1: 1]
# ** (CompileError) tests.exs:13: duplicate key :key1 found in enum Enums.type

Difference 2: ex_const does not support lists of keywords for creating Enums
With SimpleEnum, you can do

defenum :type, [:key1, :key2, :key3]

iex> type(:__enumerators__)
[key1: 0, key2: 1, key3: 2]

Difference 3: ex_const can be used at compile time to get a value from a key but not the opposite.

enum type do
    key1 	0
end

# Valid: when x == 0
def test(x) when x == Enums.type(:key1), do: x
# Raise
def test(x) when x == Enums.type(0), do: x
# Raise
def test(x) when x == Enums.from_type(0), do: x

With SimpleEnum you can do

defenum :type, [:key1]

# Valid: when x == 0
def test(x) when x == Enums.type(:key1), do: x
# Also valid: when x == :key1
def test(x) when x == Enums.type(0), do: x

Difference 4: ex_const does not seem to have any introspection helper.

Thanks for your interest!

Short answer:
The two main differences are that SimpleEnum does not depend on Ecto (it has no dependencies) and it adds Enums at compile time, not just at run time.

Long answer:
As mentioned in its documentation on reflection, Ecto.Enum’s introspection is only at runtime.

I originally wrote SimpleEnum because I needed to be able to work with Enumeration at compile time (in guards for example).

For example, let’s say I have a file that looks like this:

# <access_type> <value>
1 value1
2 value2
1 value3
....

Now, let’s imagine that I only want to display values with access_type 1 (because they are users data). I can do something like that:

def print_value(1, value), do: IO.inspect(value)
def print_value(2, value), do: :ignore

But here, why are we only printing value with type 1 ? The code is not really explicit.
A better solution could be:

@user_type 1
@admin_type 2
def print_value(type, value) when type == @user_type, do: IO.inspect(value)
def print_value(type, value) when type == @admin_type, do: :ignore

Now the code is much more explicit. It is easy to understand that we do not want to display data belonging to an administrator.

But what if several modules need to define these access types. The best would be to define a module that exports these constants.
This is what SimpleEnum does:

defmodule MyEnums do
    import SimpleEnum, only: [defenum: 2]
    defenum :access_type, [user: 1, admin: 2]
end

def print_value(type, value) when type == access_type(:user), do: IO.inspect(value)
def print_value(type, value) when type == access_type(:admin), do: :ignore

Here, my example is probably not the best, because you can easily rewrite it without guard (with a case for example) but sometimes it is not possible.

Conclusion:
I think SimpleEnum is not intended to replace ecto_enum or the native Ecto.Enum module but rather to add compile time functionality to them.
In the documentation, there is an example where you can see SimpleEnum and the native Ecto.Enum working together.

Hi @ImNotAVirus! Cool project… Could you elaborate on how is simple_enum different from existing packages like ecto_enum and the native Ecto.Enum module? I’ve been using ecto_enum for some time now and have been meaning to migrate to the new native Ecto.Enum. I think a comparison would be great to understand the value proposition of your package. Cheers!