New result error handling operator ?

[Wilbert-mad]

Like Rust's ? operator, there should be a similar way to do what Rust does with its postfix operator in Gleam.

Some ideas for the syntax:

fn func() -> Result(Nil, Nil)

let expected = func()? // Rust like
let expected =? func()
let expected ?= func()

They're all quite similar, but the last one may be the best as it follows conventions similar to other operators. I.e ==, !=, or >=.
This operator would hand off the error down through and let the developer handle it when needed. For example, In a parser or in a complex build system that returns an error if it fails somewhere in the chain more easily without the need or want to crash, although that goes a bit against BEAM's philosophy of "let it crash".

Under the hood

Under the hood of this operator, it should essentially be like the use statement where it takes the remaining (in scope) of the body and compiles it into a case expression.

fn fetch_name() -> Result(String, Nil) {
  some_api_call()
}

// from
fn get_name() -> Result(String, Nil) {
  let name ?= fetch_name()
  // ... other stuff
  Ok(name)
}

% to
get_name() ->
  case fetch_name() of
     {ok, Name} -> begin
         % rest of the body
          {ok, Name}
      end
     {error, Er} -> {error, Er}
  end

Types

Result(a,e)

When using the ? operator, like in Rust, it should also require that the expression be of type [named] Result. As well as, the e argument be the same as the expression for the outer expression or function, like in Rust.

[GearsDatapacks]

This used to exists; called try. It was later dropped in favour of use, which is more generally useful. This will not be added to the language, we don't need another way to do error handling

[lpil]

What problem does this solve? It seems to be a strictly weaker form of use.

[Wilbert-mad]

Yeah, it technically is. The ? operator is basically syntactic sugar to this;

use _ <- result.try(get_name())
//...

Unless I'm mistaken? I'll infer this is not wanted?

[GearsDatapacks]

Gleam does not generally have more than one way to do things. This doesn't add much benefit to the language, while increasing the complexity. Unless you have a good reason for adding it, it's unlikely to be implemented