Guard clause on match operator

Is that really necessary? I would be horrified to see that kind of code in a complex project.

IMO using typespecs in this case for my_function is the way to go, otherwise there is always the option of defining a small private or lambda function for that check.

Example of one of those functions:

def with_integer(fun) when is_function(fun, 0) do
    result = fun.()

    case is_integer(result) do
      true -> {:ok, result}
      false -> {:error, "not an integer"}
    end
  end

But I think that this or any other solutions in this ballpark are much worse than using typespecs and catching possible type errors at compile-time.

Well, typespecs are (very) far from infallible. I use them extensively, and they miss a lot. I like to program defensively, so I use guard clauses a lot to ensure that code fails early. And actually it seems this will work nicely with the upcoming typesystem. Maybe once the compiler actually can guarantee a type, I’ll start moving to compile-time type checking instead of guards.

But actually that’s all by-the-by. The interesting thing here is why guard clauses are not allowed, syntactically, for patterns to the left of match operators.

In what regard do they miss? Are we talking about bugs that are currently present in dialyzer or other static analysis tools?

Regardless of people using them that way, guards are not meant to be type assertions which is why I assume this doesn’t exist. Defensive programming goes against the whole OTP philosophy, really!

You can do this if you want:

y = case x do x when is_interger(x) -> x end

Though that is pretty gnarly.

As far as I understand it, they also won’t be strictly necessary for the type system. For example:

def concat(a, b) do
  a <> b
end

<> only works on strings, so the type checker will know what to do. Adding is_binary guards would be redundant.

My opinion: the main purpose of guards is to support branching, not to ensure certain invariants. If I see a match clause error, it’s almost always a bug in that code, not a bug in the caller. If I see a function clause error, it’s almost always a bug in the caller. I also feel like invariants should be checked at boundaries, not scattered throughout the code. Guards on match clauses would, I think, encourage a style of programming that is more difficult to understand and harder to debug. My 2c, opinion could change.

Really? To me this is an odd claim. The planned Elixir typesystem specifically intends to build on guards as type assertions. Additionally, type assertion in a guard is de-facto useful to help code fail early on unexpected input.

I’d go so far as to say that guards semantically are pattern matches. They offer programmable extension to patterns.

We must be talking at crossed purposes, because I’d say that OTP is pretty much the embodiment of defensive programming.

I think these are the same thing: if you hit a condition for which there is no matching pattern to branch to, you have failed some invariant. In other words, you are using patterns to ensure that data flowing through your functions conform to some expected pattern. We rely on this for fast and efficient failure on unexpected data.

Yeah, I definitely agree with this. But I’d also 100% prefer a pattern match error near some unexpected data over some obscure key :whatever not found in: nil waaay down in the stack.

Absolutely not the case. The “let it crash” philosophy explicitly says that you handle only the expected cases, not all edge cases. The runtime facilitates that extremely well.

As mentioned before, while guards can be used as type assertion, their main role is to do code branching. You start overusing them everywhere to enforce types, you get code that is not readable, has a runtime penalty and loses the value runtime offers. In that case, using a static typed language like golang will bring you more value for your invested time.

Indeed - I like my code to handle only the expected data, and crash early if it does not conform to those expectations.

“Defensive programming” usually refers to the more imperative approach, where you try anticipate potential exceptions (fail if my arguments are null; fail if my values are outside acceptable range).

Contrast that to OTP’s approach of declaratively defining success cases and otherwise “letting it crash” (which it sounds like you are already doing in practice).

Not trying to patronize; seems like just a terminology mismatch.

Yeah, this is definitely just a difference in where we’re drawing lines for our definitions. When I think about being defensive in my programming style, I’m including the semantics that we get from OTP. So OTP enables a defensive style by providing automated crash-handling mechanisms on unhappy paths. So the defensiveness is largely “outsourced” to the underlying frameworks when I’m coding.

But the way that manifests is that I’m very explicit about what is the happy path. And actually I think specifying exactly how valid data should look is essential to ensure code fails early and is surfaced in a way that makes it easy to solve.

So all of that to say - I absolutely believe that restricting pattern matches to define a strict happy path is important. And I include all forms of patterns and guards in that definition, which brings me back to - why no guards on match operators?