Propagate Warnings and Errors from ignored return values

[GregoryTravis]

The big goal here is to make sure that Enso warnings and errors are never lost, even if they are the result of sloppy programming.

To this end, @radeusgd suggests that we add special handling to ignored return values, if they are errors, or have warnings attached.

Currently, if no return values are ignored, and there are no Unused variable warnings, I believe we can be confident[1] that the dataflow-based propagation of warnings/errors will ensure that these are never lost, and always propagated to the user.

However, some end users will choose to ignore Unused variable warnings. And, even worse, forgetting to handle a function's return value is easy to do accidentally.

The proposal is that for any ignored return value, if there is a warning/error, we propagate/attach it to the return value of the block containing the ignored value line.

For example:

fun x y =
    a = f1 x
    f2 y
    f3 a+y

Warnings/errors coming from f1 and f3 are fine, since they propagate properly to the return value, and then up the call chain.

Warnings/errors from f2 are lost, however.

It seems possible to find such code statically, and insert code to propagate errors, and attach warnings to the value returned from the containing block:

• If f2 throws an error, it would normally be ignored, instead we can already stop execution and propagate the error.
• If f2 has a warning, we could re-attach it to the result of fun (i.e. here result of f3).

Viewing warning/error propagation monadically, this is the same as automatically handling the failure case at every step, even when the result is ignored by the steps coming after it.

[1] It's possible there are other ways to lose warnings/errors that I am not aware of.

[GregoryTravis]

@JaroslavTulach @jdunkerley Thoughts?

[radeusgd]

Thanks @GregoryTravis for raising this problem and describing the proposal! I think it would improve the UX for the users, since 'losing' errors is often a cause of hard to understand bugs.

We already discussed a similar idea a looong time ago: #5430 but I think the approach above is even a step further from that (in the good direction 🙂).

Also to show some context, we've been facing some bugs with error propagation and using imperative constructs in the stdlib (like Vector.Builder) for a long time already. For example, see this discussion on introducing a special folding builder pattern to ensure correct error propagation. With the proposal above, all of that would no longer be needed because this would be handled automatically!

Which I think is especially important for end-users - as library devs we can live with Problem_Builders or special fold-builder patterns. But that is too advanced for end-users and so this kind of feature would allow them to not have to think too much about handling errors.

[radeusgd]

Also, @wdanilo weren't you mentioning something about merging panics and dataflow errors? I'm not completely aware of the details of that idea, so I cannot exactly judge, but it feels like moving in the direction as described here could be helpful in case we ever want to unify these two approaches to error handling.

[JaroslavTulach]

What would be the effect on @Tail_Call functions?

[radeusgd]

Good question!

So, if the uncaught dataflow occurs in the middle of the call, if we decide that we abort the rest of the function (like we would with a panic), then we just exit the function at the point where it is thrown - and so we immediately unwind the call stack - I think there the support for Dataflow errors should not be more problematic than the already existing support for panics.

In case of warnings, we already support returning warnings from a TCO function, right? (#6849, #7116)
So we'd have to append such uncaught warnings to the result.