Stream: ideas

Topic: top level ? try

Sam Mohr (Sep 26 2024 at 22:44):

I think we should consider allowing ?/try even at the top level, but that's out of scope

Richard Feldman (Sep 26 2024 at 23:41):

:thinking: what would that do at the top level?

Notification Bot (Sep 26 2024 at 23:42):

2 messages were moved here from #contributing > Pull Request for Review by Luke Boswell.

Sam Mohr (Sep 27 2024 at 01:13):

So when I say "at the top level", I mean in the context of top-level expects. I've been thinking of this for a bit, and it seems that even though users can write a try : \{} -> Result XYZ err and call it, that's not as ergonomic as just writing an expect like it is a function.

As such, I'd propose that top-level expects (not inline ones) that have try in them would propagate their errors as is done in Rust 2018, where any Inspectable error is displayed on early return. We'd either require wrapping the bool check at the bottom in Ok or allow bare, there are trade-offs there. Something like:

expect
    parsed = try parseDate "invalidDate"

    parsed == { year: 2021, month: 5, day: 20 }

Which when run would fail something like this:

> roc test example.roc
...

expect on line 123 failed with error InvalidDateStr

0 tests passed and 1 test failed in 123ms

Sam Mohr (Sep 27 2024 at 01:14):

You could argue that this incentivizes users to "fire and forget" tests and not think about how they should fail, but there are a lot of tests where that's probably not important

Richard Feldman (Sep 27 2024 at 01:14):

oh that's really interesting!

Richard Feldman (Sep 27 2024 at 01:14):

I've been thinking about how I like unwrap in Rust tests but would prefer if it were banned everywhere else, and that's an interesting way to achieve that

Sam Mohr (Sep 27 2024 at 01:14):

If we can make the type system okay with not requiring a wrapping Ok, that'd be nicer to use

Sam Mohr (Sep 27 2024 at 01:15):

The great thing here is that Rust has already showed that this pattern works

Richard Feldman (Sep 27 2024 at 01:15):

one idea would be to say that try inside a top-level expect just fails the test immediately instead of doing what it usually does

Richard Feldman (Sep 27 2024 at 01:15):

then there's no type issue

Sam Mohr (Sep 27 2024 at 01:15):

That works!

Sam Mohr (Sep 27 2024 at 01:16):

try just works subtly differently in expect, I think that's better

Sam Mohr (Sep 27 2024 at 01:18):

We did want to eventually make it such that the actual == expected statement debug prints the actual and expected values without needing to put them in defs first

Sam Mohr (Sep 27 2024 at 01:18):

This would make that easier to do

Isaac Van Doren (Sep 27 2024 at 01:39):

This sounds like an excellent idea

Richard Feldman (Sep 27 2024 at 02:19):

Sam Mohr said:

We did want to eventually make it such that the actual == expected statement debug prints the actual and expected values without needing to put them in defs first

yeah I want to generalize this to "whatever the last expression is gets taken apart completely and we print all the sub-expressions"

Richard Feldman (Sep 27 2024 at 02:19):

which includes if the last expression is a pipeline - then, we print all the intermediate steps in the pipeline

Last updated: Jun 16 2026 at 16:19 UTC