Read my last paragraph.

So they are better... in a theoretical implementation.

A prototype of the Java compiler with composable checked exceptions existed at one point, so we know it's definitely doable.

How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.

There's at least one language, Koka (https://koka-lang.github.io/koka/doc/book.html) that has effects in its type system. There are probably others. If you don't have effects, you could use union types.

This language looks really cool. Thanks for sharing.

Simple! You just make f take in g's result type.

... not sure if serious or not

I'm completely serious in the sense that you could do that and really would in some situations.

You might do it because you want to factor the handling of the different result cases out to another function.

You don't think it would limit the independent use of f()?

No? Surely if f() takes a full result (including error condition) it's because there's something it wants to do with that?

Very serious. https://pkg.go.dev/text/template#Must

In rust, you write "f(g()?)", and make sure that your function body returns a Result<> with an error type that g()'s error type can be converted to.

It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible.

Sadly, there are proposals to add exceptions to rust, and it seems likely they will be accepted, breaking error handling semantics across the entire ecosystem (even in new code, since exceptions are too hard to use correctly).

What's the rationale behind adding exceptions?

I'm not sure what they mean by adding exceptions.

AFAIK, the only proposal related to exceptions is adding a `try` block that would scope the `?` operator to that block instead of the current function.

You could actually, iirc if f takes as many parameters as g returns it works out.

In a better langage f would take a Result, and then it can manipulate that however it wants.

Obviously you can also plug in adapters if you need some other composition e.g. g().map(f), g().and_then(f), …

> You couldn’t do that in Go, for instance.

You can – by making f accept g's return types, including the error. This is even being done in the Go standard library: https://pkg.go.dev/text/template#Must

That’s interesting, but consider two functions like func ParseInt(string) (int, error) and func Abs(int) int. You lose some composability when using errors over exceptions. The Rust solution mentioned elsewhere seems elegant.