For what is worth, this is a question I frequently ask myself: if it is worth adding abstractions on top of pattern matching and provide conveniences such as defpattern and/or defguard? It is one of those things I am somewhat glad the Erlang VM restrict us from generalizing because we would probably have done so some time ago and the solution may not have been ideal.

Maybe one day we will add something that resembles discriminated unions and named patterns, which would give the features you described above, but right now there are still many questions around on how to generalize such patterns while providing good performance and sane semantics. The current mechanism, although it may be repetitive some times, it is simple, explicit and straight-forward. See the expat thread for a similar discussion.

I’ve created a library for doing exactly this, called disc_union. For your example it would look like this:

defmodule Result do
  use DiscUnion

  defunion :ok in any() | :error in atom
end

defmodule Example do
   use Result

   def foo() do
     Result.case my_func() do # expects a %Result{} struct
       :ok in value -> #continues
       :error in reason -> #report the error
     end
   end
end

NOTE: you can also “import” a regular error tuple into the Result struct using Result.from!/1 function and it will check if what your are importing was defined as one of the variants.

Downside is that for each discriminated union there has to be a specially created case macro, in order for it to “know” what valid variants are in this union and warn you (at compile time) when you miss one or implement it with a wrong shape. I find it very useful and use it in production even though I still consider this a research project.

I believe that if your patterns become too complex in a single function, then that might be a very clear indicator that that function could be split in smaller parts.

I do like pattern-matching extensively to ensure that people know it right away when they put garbage in my libraries’ functions. Sometimes these matches become relatively long. I have been tempted to fiddle with pattern-providing macros before, but have not gone through with it until now because I also believed that this would make it harder to read what was going on. I think there are some use cases where you frequently want to match a struct that is in a certain state.

I agree with @josevalim and @crowdhailer: This is not something Elixir itself should provide, but it is great that we can, if it turns out to be useful for the project at hand, write macros that do this stuff.

Like in the tennis kata example where a PlayerPoints.case macro “understands” what it’s possible variants are - which are defined at line 13 - and programmer needs to explicitly cover all of them.

It’s basically a discriminated union concept, and even though a Elixir is a dynamic language, this library gives some compile-time warnings.

Pattern matching is one of the best superpowers that erlang/elixir have. We should not try to decorate/hide pattern matching with other stuff by adding more magic. I agree that having more expressive atoms may be helpful, but this may not be the best way to go about it, See Usage of {:ok, result} / :error vs {:some, result} / :none . To me it seems like we are adding more noise without giving the user much in return.