Yeah, I'm across all that. I think the real question which i kind of failed to ask is, why is it not accumulating errors in a Task(Result a [A,B,C])
instead of Task a [A,B,C]
?
Oh, it's because it returns a result! and you'd end up with a function signature that returns Task [Result a A, Result b [B]]
right?
I'm not sure I follow the question. Is the question for current roc code or for this proposal specifically?
Sorry I've strayed off topic a little. I was actually talking about current roc code, but this syntax just brought to mind that Tasks kind of being a copy of result is a little weird on the surface.
Can you just remove those messages?
5 messages were moved here from #ideas > chaining but with Task.attempt
and ?
for error returns by Brendan Hansknecht.
Moved them here, hopefully that is good
So Task
is actually defined as Effect (Result ok err)
So a task is just an effect that can fail.
How platforms are designed today, essentially all Effects
map to a Task
and the Task
is given to the end user so that they always get a consistent type. It is just always a Task
.
That said, in many cases, we could theoretically cut out the middle man. We could just have an Effect x
and return that to the user. They would never need to deal with error cases cause there would be none
They would just:
x <- cantFail 123 |> Effect.after
I think after
is the correct name for the Effect
type.
Of course, if you have some values as Effect
and some as Task
, you would have type errors if you missed the two.
Last updated: Jul 05 2025 at 12:14 UTC