The Erlang ecosystem (and thus much of Elixir’s) uses:

{:ok, result} / :error
– or –
{:ok, result} / {:error, reason}
– or –
:ok / {:error, reason}
– or –
:ok / :error

Depending on what information needs to be returned. Consequently I’m a fan of the Exceptional Elixir Package as it wraps all of the above, and exceptions, and other things all into a single interface that is wonderfully easy to pipe around. ^.^

I think the important thing is that irrespective of exactly which alternative is chosen that it is easy to pattern match on. So when you do want to test the alternatives you can just use case

case some_function(1) do
  {:ok,val} -> do_yes(val)
  {:error,err} -> do_no(err)
end

This is possible in most cases but what is also very practical that you can just match against the success case else have the system generate an exception if no match:

{:ok,val} = some_function(1)

This case is often forgotten which can complicate its usage.

I don’t agree that always piping everything is a good way. While it might be very easy to write, I find the given examples nearly completely illegible. They are very “dense” in behaviour and many different things are occurring at once. Treating different things, differently is not always a bad thing.

Going back to the original question about {:some, value} | :none, I’m not sure I see any difference with the currently used {:ok, value} | :error - it behaves exactly the same in all occurrences. The only difference is the names, but I’m not sure it’s worth going against the established convention in the entire platform (both Erlang and Elixir), just to have a slightly better name.

I agree, but I don’t know that this needs to be an either/or kind of decision. What about:

{:ok, result}
:none
{:error, error}

The with/do/else pattern I feel encourages more readable response atoms. I wound up with this recently:

with(
      client_ip = get_client_ip(request_ip, params),
      {:ok, location} <- Geoip.lookup_ip(client_ip),
      true <- should_search?(location, parse_exclusion_zone(params)),
      query = build_search_query(%SearchQuery{}, location, params),
      {:ok, results} <- NHSearch.search(query),
      Analytics.track(results, client_ip, "api", "search_results")
) do
      json conn, results
else
  {:error, :location_not_found} ->
    Logger.error("Unable to find the location for: #{get_client_ip(request_ip, params)}")
    # Need to make this an error message of some sort to explain what's going on.
    json conn, []
  :user_in_exclusion_zone ->
    Logger.info("User is too close to the exclusion box")
    # Need to make this an error message of some sort to explain what's going on.
    json conn, []
  other ->
    Logger.error(inspect(other))
    json conn, []
end

should_search could have just returned false, but with the with() pattern, I instead returned :user_in_exclusion_zone to make the code less brittle and easier to read.

I’ve also seen code where people use [result] if there is a result, and [] if there is none.
Lists are of course a more general way of Rust’s Option<T> or Haskell’s Maybe type, as besides no result and one result, they might also contain two, three, etc. results.