Compiler doesn't recognize that patterns are exhaustively covered if using guards

[ardauzan]

I'm using version 1.8.1 which is the latest at the time I'm writing this.
I am trying to learn gleam and basically just playing around, I came accross this issue the other day:

I was writing this function (using vscode with the extension) and it kept complaining about not all cases being accounted for. Obviously this can be fixed by changing the last pattern with _ so it catches all... But my issue is, I want to be explicit, in this case changing the last pattern with _ would only get matched if steps is a negative integer which is identical to my version logically, Is this a known issue?

pub fn tick_to(
grid: Grid,
ruleset: Ruleset,
steps: Int,
) -> Result(Grid, GOLError) {
case steps {
s if s > 0 -> tick_to(tick(grid, ruleset), ruleset, steps - 1)
0 -> Ok(grid)
s if s < 0 -> Error(NegativeSteps)
}
}

I hated the idea of losing explicity so much, I had to re write this as follows (which kinda looks better too but thats not the point):

pub fn tick_to(
grid: Grid,
ruleset: Ruleset,
steps: Int,
) -> Result(Grid, GOLError) {
case int.compare(steps, 0) {
ord.Gt -> tick_to(tick(grid, ruleset), ruleset, steps - 1)
ord.Eq -> Ok(grid)
ord.Lt -> Error(NegativeSteps)
}
}

So I understand that guard expressions are not getting evaluated but I really think this should be fixed as the whole magic of Gleam for me was it being very readable and explicit and for this case the order module saved the day but for other cases there might not be a module to just drop in like this... So are we supposed to write an extra module to be able to be explicit with pattern matching? I find it to be a bad practice to use the discard pattern if it's not matching with multiple patterns, like in this case we are obviously matching based on the steps being positive, zero or negative, so there are litteraly 3 options. When it's like this I don't like to use the discard pattern as it's only matching a single option out of three possible options. I want the reader to know if they see a discard that is there to match with at least 2 different options. And what shocks me is in the guard only a limited set of operators are allowed, when I first saw that in the language tour I automaticcaly assumed that it's probably like that so the compiler can effectively be sure of the slice of the target set that guard covers.

I'm not hating. Just giving feedback. Gleam is awesome and the team did an awesome job. Outside of this specific thing everything is perfect.

[lpil]

This isn't a Gleam limitation! Performing exhaustive checking on arbitrary boolean expressions is an unsolved problem in computer science.

In your example there the guard is redundant and wasted computation, so it can be safely removed.

The limited set of guard expressions is a virtual machine design choice, motivated by performance characteristics. If Erlang supports more in future we will also support the new additions.

[ardauzan]

Hey I didn't know that, thanks for the response.