Sure, but in a language with an effect system, it seems like effects would be used for errors, so it seems worth comparing error-handling techniques.
Go uses a single base type (interface) for “expected” errors and panics for errors that aren’t normally caught. I suppose those would be two different effects? For the “expected” errors, some kind of annotation on the function call seems useful.
The way I see it, effects would be implemented/assigned to the function where the error gets logged for instance.
But as long as the error value remains local, a function can still be pure all else being equal.
This is not the case with exception looking code (aka panics) since it escapes normal control flow and I guess makes an error "punch" through stacks as they are unwinded.
A bit like being thrown toward global state.
So if we consider panics as side effectful operations, we would have to change go to explicitly declare panics as side effects with a known function signature.
I guess one would want the list of side effects to be part of a function signature for full visibility.
I wonder how that would influence backward compatibility.
Go uses a single base type (interface) for “expected” errors and panics for errors that aren’t normally caught. I suppose those would be two different effects? For the “expected” errors, some kind of annotation on the function call seems useful.