# Idiomatic pattern matching without arity overloading. (Single function vs mutliple)

**URL:** <https://forum.elixirforum.com/t/idiomatic-pattern-matching-without-arity-overloading-single-function-vs-mutliple/67206>\
**Category:** Questions\
**Tags:** learning-elixir\
**Created:** [November 3, 2024, 11:58am UTC](https://forum.elixirforum.com/t/idiomatic-pattern-matching-without-arity-overloading-single-function-vs-mutliple/67206 "2024-11-03T11:58:50Z")\
**Posts on this page:** 1\
**Showing post:** 9

<div class="post-metadata">

**Author:** ![dimitarvp](https://forum.elixirforum.com/user_avatar/forum.elixirforum.com/dimitarvp/32/38664_2.png) [@dimitarvp](https://forum.elixirforum.com/u/dimitarvp)\
**Post date:** [November 3, 2024, 4:00pm UTC](https://forum.elixirforum.com/t/idiomatic-pattern-matching-without-arity-overloading-single-function-vs-mutliple/67206/9 "2024-11-03T16:00:01Z")

</div>

It’s still very valuable information for future maintainers.

It’s 50/50 and I like your approach but you could also do it like this as you alluded to earlier and I don’t think a lot of information will be lost:

```elixir
@type message_request :: {:send, String.t()}
@type disconnect_request :: :send_disconnect

@type message_response :: {:push, String.t(), t()}
@type disconnect_response :: {:stop, :normal, t()}

# ...

@impl true
@spec handle_info(message_request() | disconnect_request(), t()) ::
    message_response() | disconnect_response()

```

Sure, some information is lost – like is it OK to have a `message_request` in parameters but `disconnect_response` as a return value is what I’d be a little grumpy about – but expressing types like this still increases readability and you can also put a short comment saying that a message response is only returned when message request is passed and the same for disconnect and others.

Ultimately though, your way is still fine IMO. And I might prefer it in some cases.

---

_[View the full topic](https://forum.elixirforum.com/t/idiomatic-pattern-matching-without-arity-overloading-single-function-vs-mutliple/67206)._