In my mind that is “sloppy typing” - always returning a two element tuple where the consistently typed value of the first element is an indication of the type of the second value is much cleaner - and I suspect much better for pattern matching.

The :ok/:error tuple is a poor man’s implementation of Either. When used correctly it makes it easier to compose functions without having to specify explicit conditionals to deal with the errors - i.e. it enables railway-oriented programming (ROP).

defmodule Demo  do

  def f1({hour, minute, second}),
    do: Time.new(hour, minute, second)

  def f2({:ok, time}),
    do: NaiveDateTime.new(Date.utc_today(), time)
  def f2(other),
    do: other

  def f3(input),
    do: input
        |> f1()
        |> f2()

end

IO.inspect(Demo.f3({3,2,0}))
IO.inspect(Demo.f3({25,2,0}))

$ elixir demo.exs
{:ok, ~N[2018-05-12 03:02:00]}
{:error, :invalid_time}

In any case - what exactly is stopping you from putting the “ugly code” into a stand-alone, clearly-named function?

But what if {:error, _} is a legit return value? How would you distinguish this from a real error?

Consider an Elixir Term Parser: Terms.parse("{:error, :badarg}").

If we were returning plain values on success but {:error, :badarg} on non-string input, we had a problem here.

But since it is common to return wrapped values in success cases, we can clearly and unambiguisly distinguish between {:ok, {:error, :badarg}} and {:error, :badarg}.

I do not understand your reasoning, seems to work:

iex(1)> for x <- 1..10 do
...(1)>   {:ok, time} = Time.new(3, 2, 0) 
...(1)>   {:ok, naive} = NaiveDateTime.new(Date.utc_today(), time)
...(1)>   %{date_time: naive}
...(1)> end
[
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]},
  %{date_time: ~N[2018-05-12 03:02:00]}
]