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: Nov 09 2025 at 12:14 UTC