Luke Boswell (Aug 15 2024 at 05:40): Luke Boswell (Aug 15 2024 at 05:40):Looking at https://github.com/roc-lang/roc/pull/7000
I'm wondering if we should consider renaming Task.await to Task.try.
I vaguely recall some discussion around the motivation for choosing await, but I don't remember where I saw that.
In this context I think it's nice to align the two. Here's the related rust trait https://doc.rust-lang.org/std/ops/trait.Try.html
What do people think?
Sam Mohr (Aug 15 2024 at 05:42):I think that it is less descriptive than Task.await, but more in line with Result.try. I'm not sure if it's worth the trade-off.
Sam Mohr (Aug 15 2024 at 05:44):I think this matters as a means of making things easier for newcomers to understand. If we are prioritizing not confusing newcomers that already know the concept of await from JS or Rust, then keeping the current name is better. If we are prioritizing newcomers that don't understand await already, then Task.try makes more sense as it corresponds to Result.try.
Sam Mohr (Aug 15 2024 at 05:45):Since I expect more people understand await already than not, I'd lean towards not renaming a popular existing name, though I'm amenable to either naming.
Luke Boswell (Aug 15 2024 at 05:45):In a world where the use of ! and ? is the norm... then I imagine it will be uncommon to see these written out manually.
Luke Boswell (Aug 15 2024 at 05:47):They have the same name, they behave the same*, they're both special with sugar.
*similar
Richard Feldman (Aug 15 2024 at 12:02):I still like the idea of a convention where try means that specifically a Result type is involved
Richard Feldman (Aug 15 2024 at 12:21):that said, I could actually see renaming Task.await to Task.andThen because it reads better when using pipelines instead of the ! suffix:
buildPath arg
|> File.readUtf8
|> Task.andThen Http.getUtf8
vs today:
buildPath arg
|> File.readUtf8
|> Task.await Http.getUtf8
Though today, that should really be:
buildPath arg
|> File.readUtf8!
|> Http.getUtf8!
We could always start with an alias by renaming Task.await to Task.andThen, desugaring ! to andThen, and then creating a Task.await = Task.andThen backwards-compatibility alias to avoid breaking existing code
Richard Feldman (Aug 15 2024 at 15:11):I love that idea!
Brendan Hansknecht (Aug 15 2024 at 15:12):I think with !, await will probably be a clearer name in desugared error messages. but I also think this is a super minor quibbling and long term we probably want to hide the desugared errors (or at least clean them up). So I don't think it matters too much either way.
Richard Feldman (Aug 15 2024 at 15:15):the original goal with the name await was familiarity - to make it appear in code in a similar place to where an await keyword would in other languages
Richard Feldman (Aug 15 2024 at 15:20):so I think now that ! is our await equivalent, it's actually more helpful to use a different name so we can say "! is similar to await in other languages" without it leading to confusion about whether we're referring to Task.await
Last updated: Jun 16 2026 at 16:19 UTC