Proposal: use assert

[acandoo]

Hi! I've been playing with Gleam and have admired how intentionally scoped the language's syntax feels, and how it encourages simple, legible patterns. However, among other features, I feel like this one would fit in well with Gleam's existing semantics.

Proposal

Allow assertions along with use syntax. I know that assertions are generally not encouraged in library/application code/etc, but extending assertions would allow for more concise syntax that is imo still reasonably readable.

Note that these examples are fabricated, since I'm unaware of a use with a current library.

Example 1: Single-argument assert

The base case for single-argument callbacks is simple enough.

// fn file.at_path(
//   path: String,
//   permissions: io.IOPermissions,
//   cb: fn(Result(io.IODevice, io.IOError)) -> a,
// ) -> a
use assert Ok(config_file) <- file.at_path("config.toml", io.ReadOnly)

Equivalent to:

use tmp <- file.at_path("config.toml", io.ReadOnly)
let assert Ok(config_file) = tmp

Example 2: Single-argument assert with as

This differs from the usual semantics of the let assert syntax in the as being on the left side, but I think it's necessary given the complexity of multi-argument use.

use assert Ok(config_file) as "Unknown filesystem error" <- file.at_path("config.toml", io.ReadOnly)

Equivalent to:

use tmp <- file.at_path("config.toml", io.ReadOnly)
let assert Ok(config_file) = tmp as "Unknown filesystem error"

Example 3: Multi-argument assert

I'm split on whether or not the assert should occur for every individual argument. I'm leaning towards having it for each argument for more explicitness:

// fn db.get_handles(cb: fn(Result(DBHandle, DBError), Result(DBHandle, DBError)) -> a) -> a
use
  assert Ok(handle1),
  assert Ok(handle2),
<- db.get_handles

Equivalent to:

// fn db.get_handles(cb: fn(Result(DBHandle, DBError), Result(DBHandle, DBError)) -> a) -> a
use tmp1, tmp2 <- db.get_handles
let assert Ok(handle1) = tmp1
let assert Ok(handle2) = tmp2

Though having one assert would make code more concise / closer to let assert + tuple destructuring:

// fn db.get_handles(cb: fn(Result(DBHandle, DBError), Result(DBHandle, DBError)) -> a) -> a
use assert
  Ok(handle1),
  Ok(handle2),
<- db.get_handles

Example 4: Multi-argument assert with as

This is, unfortunately, why as would have to be on the left side, unlike the usual let assert.

// fn db.get_handles(cb: fn(Result(DBHandle, DBError), Result(DBHandle, DBError)) -> a) -> a
use
  assert Ok(handle1) as "Unknown error when acquiring handle1 of DB",
  assert Ok(handle2) as "Unknown error when acquiring handle2 of DB",
<- db.get_handles

Equivalent to:

// fn db.get_handles(cb: fn(Result(DBHandle, DBError), Result(DBHandle, DBError)) -> a) -> a
use tmp1, tmp2 <- db.get_handles
let assert Ok(handle1) = tmp1 as "Unknown error when acquiring handle1 of DB"
let assert Ok(handle2) = tmp2 as "Unknown error when acquiring handle2 of DB"

[GearsDatapacks]

Hello! Thank you for your proposal. What problem in current Gleam code would be fixed by adding this feature?

[acandoo]

In the case of accessing resources that are accessible through a function that takes a callback (say, for automatic resource cleanup with a DB connection / opening a file as in the examples), there's a good chance that that callback would use a Result or some similar argument that would be ergonomic to assert. While the examples mentioned in the proposal are fabricated, I see the real-world use case in scripts that access files or open network connections where error conditions should not necessarily be handled gracefully.

[giacomocavalieri]

While it could avoid a bit of typing I feel like adding a new construct for panicking in the language is not all that needed given you could already use let assert for that:

use result <- result.try(fallible_operation())
let assert Ok(wibble) = result

I don't think the extra typing is enough of a problem in itself to justify adding use assert

[acandoo]

If I'm not mistaken this couldn't happen in a main function since result.try would return Result instead of Nil? You'd have to put it in a handler function and then do let assert Ok(_) = fallible_op_handler() which is a lot more of a change than an additional line.

[giacomocavalieri]

The same would happen with an hypothetical use assert as it would still return the value returned by the function. These would all behave the same:

use assert Ok(a) <- result.try(wibble)
todo

// Would desugar to:
result.try(wibble, fn(value) {
  let assert Ok(a) = value as "use assert"
  todo
})

// And so be equivalent to this code which you can already write today:
use value <- result.try(wibble)
let assert Ok(a) = value
todo

[acandoo]

Oh sorry, I got confused since in my examples, a type-safe version would use result.try to return the error to be properly handled elsewhere.