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

[dogweather]

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

I appreciate the thoughtful discussion around error handling ergonomics in Gleam. I'd like to respectfully share a perspective that might be worth considering.

While I understand that use expressions can technically achieve the same result as a ? operator, I think there's value in distinguishing between mechanism and intent. The current approach feels similar to arguing that we don't need dedicated case syntax because pattern matching can be implemented with nested if statements under the hood - technically true, but it conflates implementation details with developer intent.

The Developer Experience Argument

The ? operator (or similar explicit error propagation syntax) would signal intent immediately: "this operation might fail, and if it does, propagate that failure up the call stack." This is a fundamentally different semantic concept from the general-purpose callback mechanism that use provides.

Consider these two approaches:

// With use (current approach)
use result1 <- result.try(operation1())
use result2 <- result.try(operation2(result1))
use result3 <- result.try(operation3(result2))
final_operation(result3)

// With hypothetical ? operator
let result1 = operation1()?
let result2 = operation2(result1)?
let result3 = operation3(result2)?
final_operation(result3)

Both compile to the same thing, but the second immediately communicates "this is error handling" to any developer reading the code, regardless of their familiarity with Gleam's use patterns.

The Documentation Gap

You've highlighted something important that I noticed while reading the language tour - while use expressions do exist in the documentation, they're buried under "Advanced features" rather than being presented as a core language concept. More tellingly, "Error handling" doesn't appear anywhere in the main navigation as a first-class concept, despite being fundamental to any production system.

The current documentation structure suggests that error handling is an advanced, optional concern rather than a basic requirement for working software. Meanwhile, the Result type gets minimal coverage in the main flow, and the critical use + result.try pattern that actually makes error handling ergonomic is relegated to an "advanced" section that many developers might never reach.

This documentation structure reflects the same prioritization issue - treating error handling as an afterthought rather than a first-class language concern. A dedicated error propagation operator would be immediately discoverable and self-documenting, whereas the current approach requires developers to:

1. Recognize that Result types are important (minimally documented in main flow)
2. Navigate to "Advanced features" to learn about use expressions
3. Connect that use + result.try creates error propagation
4. Understand that this "advanced" pattern is actually essential for real-world code

When a language treats fundamental error handling patterns as "advanced features," it signals a concerning disconnect from the needs of working developers. This cognitive overhead exists not because the concepts are inherently complex, but because the language design and documentation don't prioritize the developer experience of writing robust, production-ready code.

The Ecosystem Perspective

Every functional language community eventually converges on similar error handling patterns. Rust has ?, F# has computation expressions with let!, Haskell has do notation for monads. These aren't accidents - they reflect the reality that error handling is common enough to warrant dedicated syntax that clearly expresses intent.

Gleam's current approach optimizes for the simplicity of the language specification at the expense of clarity in the user's code. I'd argue that developer ergonomics should take precedence over keeping the language feature count minimal.

A Compromise Suggestion

If adding new operators feels too heavyweight, perhaps there's a middle ground - could the compiler/LSP provide specialized highlighting or code transformations that make the error handling pattern more visually distinct when using use with result.try? This would preserve the current architecture while improving the visual recognition of error handling patterns.

I hope this perspective adds value to the discussion. Gleam is a beautiful language, and I believe it would benefit from making one of the most common programming patterns as clear and intention-revealing as possible.

Thanks for considering these thoughts!

[GearsDatapacks]

Hello! Thank you for your ideas. Here are my thoughts:

The current approach feels similar to arguing that we don't need dedicated case syntax because pattern matching can be implemented with nested if statements under the hood - technically true, but it conflates implementation details with developer intent.

I don't think this is a particularly sound comparison. Rather it's like saying we don't need if because case can be used to achieve the same result, which is the decision we made in Gleam. We chose the more generalised and powerful tool (case, over the specific tool (if).
It is the same story with use. As I mentioned, there used to be a keyword called try, which did exactly the same as ?. However, it was later decided that use can be used to achieve this same behaviour, as well as allowing for many more uses also.

Both compile to the same thing, but the second immediately communicates "this is error handling" to any developer reading the code, regardless of their familiarity with Gleam's use patterns.

Correction: It communicates that this is error handling to anyone familiar with what the ? operator does, which is not every developer. The same can be said of the first example, if you know what result.try does.

"Error handling" doesn't appear anywhere in the main navigation as a first-class concept, despite being fundamental to any production system.

Error handling is part of the page on the Result type, and the most commonly used functions for working with results are documented on the page for the gleam/result module of the standard library.

the critical use + result.try pattern that actually makes error handling ergonomic

This is perhaps a misunderstanding. use in combination with result.try is not the only way to do error handling in Gleam. There are generally three main ways. The first is pattern matching, which is often the recommended way to handle errors as it is explicit about the intent of the program, and easy to see the control flow. The second is using result.try without use, often followed by either pattern matching, or something like result.unwrap.

use with result.try is only really useful in one circumstance: Handling many possible errors which are all propagated in the same way, by just returning an error to the parent function immediately. In many cases this is not the best way to handle errors, and it is important that all three methods are considered.
Adding a ? operator would encourage the last kind of error handling, which can sometimes lead to unclear errors, when they all just get propagated to the top-most level function, it is difficult to tell from where they originate.
It is for this reason that use is an advanced feature. It is not mandatory for error handling or any other form of control flow: Only a syntax sugar to make the code nicer in certain circumstances.

Gleam's current approach optimizes for the simplicity of the language specification at the expense of clarity in the user's code. I'd argue that developer ergonomics should take precedence over keeping the language feature count minimal.

I disagree. Keeping feature count minimal makes the language extremely easy to pick up, because there are very few features to learn. Its simplicity also makes Gleam code easier to understand in many cases, because there isn't a lot of hidden magic in the language: The code you see very directly reflects its behaviour.

could the compiler/LSP provide specialized highlighting or code transformations that make the error handling pattern more visually distinct when using use with result.try

Do you have any specific ideas in this regard?

[lpil]

Personally I think the intent is less clear with the proposed ? syntax as it is easy to miss and it is a more cryptic symbol rather than a word that can be easily looked up.

Either way ? is strictly weaker than use, and we don't have any problems relating to error handling today, so there's no reason to explore design in this area.