Pre-RFC: Catching Functions

[withoutboats]

The problems with Swift seem to have more to do with the fact that once you have an Optional you can’t just destructure it the same way you can with a normal ADT. This is not true with this proposal - a catching function returns a Result, which is still just a library type like any other.

[chriskrycho]

The problems with Swift seem to have more to do with the fact that once you have an Optional you can’t just destructure it the same way you can with a normal ADT. This is not true with this proposal - a catching function returns a Result, which is still just a library type like any other.

That’s strictly not true, actually. You can drop this in a Swift playground and see that it works just fine—and identically with spelling out an optional type explicitly:

let foo: String? = nil;
switch foo {
case let .some(str):  // or case .some(let str):
    print("HEY, \(str)")
case .none:
    print("YO")
}

And this is precisely the point I’ve been concerned by. It’s extremely easy to develop the wrong mental model of what’s happening when certain kinds of sugar are introduced. That doesn’t in and of itself make the proposal here bad, of course! But I think it shows how easy it is for these kinds of syntactical sugar to have some unexpected downsides in terms of what they communicate even among really sharp and well-informed people.

[withoutboats]

So I’ve never used Swift and my entire impression is from reading tutorials on Optional.

What seemed like the problem to me was that if let doesn’t do a pattern-based destructuring, but just lets you do if let x = foo instead of if let Some(x) = foo, and that this is the idiomatic way to process the value. We would not propose that you could destructure a Result except by pattern matching. This is the big difference from this proposal, which makes comparisons to it seem to me to be of limited relevance.

[dan_t]

That doesn’t seem to give you that much. Instead of reusing the mental model people have build for ?, inside of try-functions, they now get a pretty much inverse behaviour for try-functions.

[regexident]

The problems with Swift seem to have more to do with the fact that once you have an Optional you can’t just destructure it the same way you can with a normal ADT. This is not true with this proposal - a catching function returns a Result, which is still just a library type like any other.

As @chriskrycho already remarked this is wrong, as described in my first response:

I have stopped counting the number of intermediate level Swift developers who managed to get used to optional unwrapping à la …

if let foo = bar { // foo: T; bar: Optional<T>
    // …
}

… but fail to grasp the whole concept behind enums and the case let syntax …

if case let .some(foo) = bar { // foo: T; bar: Optional<T>
    // …
}

For them these are completely disjoint concepts. Telling them that those two things are the same and showing them the source code for enum Optional<T> { … } never fails to blow their minds. (I consider this a bad thing. Their response should be a bored “Well, of course.” instead, at this point in their education.)

So I’ve never used Swift and my entire impression is from reading tutorials on Optional.

What seemed like the problem to me was that if let doesn’t do a pattern-based destructuring, but just lets you do if let x = foo instead of if let Some(x) = foo, and that this is the idiomatic way to process the value. We would not propose that you could destructure a Result except by pattern matching. This is the big difference from this proposal, which makes comparisons to it seem to me to be of limited relevance.

No. Swift’s if let foo = <expr> { … } is no more than syntactic sugar for if case let .some(foo) = <expr> { … }. The former has been pushed as the idiomatic way of dealing with Optional<T>, obfuscating their actual semantics. As a matter of fact up until Swift 2, iirc, one could actually do if let foo = <expr> { … } with any enum that had a .Some(T) and a .None case, which I considered a feature (it generalizes), not a bug. They “fixed” it regardless.

There is no Result<T, E> in Swift. (Which is bad too, imho. But that’s another topic on its own.)

---

The fact that you got the impression that one could not pattern match on Optional actually completely supports the point I’m making.

You in fact just witnessed it yourself. By reading tutorials on Swift’s Optionals you ended up with a wrong understanding of the language. That’s my whole point here.

It’s precisely why I consider this RFC troubling to say the least.

@withoutboats, please read my two responses a second time, if you can spare the time.
As of right now 40 people seem to agree with them. So clearly no “limited relevance”.

[newpavlov]

try fn f() -> T {
    let x: T = try_g();
    if fail() { throw e; }
    x
}

It’s even more radical proposal than one in the OP. I think we don’t get much from hiding Result type and it makes extension to Option and other types through try trait even more difficult. And hiding ? does not help either.

I think this syntax can be an acceptable middle ground:

try fn foo() -> Result<T, E> {
    let x: T = try_g()?;
    if fail() { throw e; }
    x
}

try fn bar() -> Option<T> {
    let x: T = try_g()?;
    if is_none() { throw; }
    x
}

try can be replaced with catch or something else, same with throw. This variant does not hide enums and makes integration with other types trivial through Try trait. And it allows Ok wrapping, through explicit notion of try fn, which with other modificators like async fn (and maybe others in future?) notifies user that this function operates under slightly different rules compared to the usual fn.

[rpjohnst]

I think we don’t get much from hiding Result type

For what it’s worth, I didn’t intend to propose that aspect at all. It works equally well with try fn foo() -> Result<T, E>. My intent in removing ? was twofold:

• To double down on the “context” mental model based on the analogy to C#, where await is only available in async methods. ? would map to Task.Wait in that model- a reasonable way to extract the value when not in the context. (This also removes the redundancy between Err(e)? and throw e.)
• To address the explosion of noise in async functions that also use the “context” mental model (IINM, withoutboats would like the two syntaxes to match). This is something people are worried about, since they keep e.g. proposing that ? mean both “try” and “await.”

But as nikomatsakis pointed out, ? does have a stronger effect on control flow than await!, and as dan_t pointed out people already have a mental model for it in Rust. So I’m not hugely opposed your sample code either- it’s certainly the best of the other options IMO.

[bomz]

try fn foo() -> Result<T, E> { let x: T = try_g()?; if fail() { throw e; } x }

sounds like a good proposal, but forces to use extra keyword in the beginning of method, addition of visibility making method declaration pretty lengthy

pub(crate) try fn foo() -> Result<T, E> {
    let x: T = try_g()?;
    if fail() { throw e; }
    x
}

“?” is actually “try” in rust , is it possible to use it in method declaration like:

fn foo()? -> Result<T, E> {
    let x: T = try_g()?;
    if fail() { throw e; }
    x
}

[nikomatsakis]

The fact that you got the impression that one could not pattern match on Optional actually completely supports the point I’m making.

I’m not sure this says as much as you are saying it does. I think that @withoutboats basically got to the heart of it, actually, in this comment:

What seemed like the problem to me was that if let doesn’t do a pattern-based destructuring, but just lets you do if let x = foo instead of if let Some(x) = foo, and that this is the idiomatic way to process the value.

In particular, they were pointing out that the precise sugar that Swift settled on has two parts. The first is expression Option in terms of ? and so forth. The other is letting you write if let foo = <expr> – which completely hides the Some variant constructor (in Rust terms) and looks like a kind of “identity operation” (when in fact it is doing destructing). In other words, the problem may not be “syntactic sugar writ large” but rather the specific choices that Swift made.

That is, if I understood, @withoutboats was trying to point out some specific differences between how Swift handles things and how this proposal works that they feel might make the difference.

Put another way, in Rust, when you get the Result, you still need to use the ? operator to “discharge and propagate” the error. So now as you learn more about how errors in Rust work, you can map ? to this operation – whereas if there were no syntactic mark at all, it may be surprising that in fact a match is taking place.

[newpavlov]

I think we should not forget about consistency with async stuff, using fn foo()? feels too ad-hoc for me. An alternative to using try keyword is to mark functions with #[try] attribute, but result looks a bit less appealing.

[nikomatsakis]

I think we should not forget about consistency with async stuff, using fn foo()? feels too ad-hoc for me. An alternative to using try keyword is to mark functions with #[try] attribute, but result looks a bit less appealing.

I agree. I’ve been wanting to write-up something for a while now, but I’ve been pretty busy. My feeling is that this thread has brought up four important questions:

1. Do we want this feature at all? Will it impact learnability?
   • Drilling into the motivation more seems important.
   • My take is that this can be a win for ergonomics and learnability (which I see as distinct, but related, goals)
   • As far as ergonomics goes, I often find the need to add Ok to be kind of a “mental impedance mismatch” – I forget it, then get an obscure compiler error, then add it. I think this is because code like foo()? + bar()? never has to talk about Err explicitly, so in a way it’s odd to have to talk about Ok
   • As far as learnability, that same mismatch means that to learn error handling one has to fully grok its corners. I think it could be very useful to think of error handling as “exceptions that one must manually propagate at each level” and then, once you’ve learned about enums etc, understand how that works under the hood.
   • But obviously things like Swift can act as a counter example: at some point, particularly when the abstraction is too “leaky”, syntactic sugar just means you have to learn both the sugar and the underlying thing, and that’s not a net win for learnability.
2. Given that we want this feature, should the source code expose the “inner type” (e.g., T catches E) or “outer type” (Result<T, E>). This applies equally to async fn
   • I don’t know the answer here. I think I’d like to try it both ways.
   • I can see that using the “outer type” might have the same mental impedance problem ("I return a value of type T, but my return type is declared as Result").
   • On the other hand:
     • I can see that makes the transition to full understanding more smooth;
     • It helps when reading the signature of a fn you are about to call
     • It eliminates a potential inconsistency with rustdoc
     • It allows smooth support of Option
     • It has precedent from other TypeScript and C# for async fn at least
   • I lean towards writing the “outer type”
3. Given that we want the feature, how should we denote that you are using it? This is not independent from the previous question.
   • T caches E (assumes internal type)
   • try fn foo() -> Result<T, E> (assumes external type)
   • catch fn foo() -> Result<T, E> (assumes external type)
   • fn foo() -> Result<T, E> try { ... }
   • fn foo() -> Result<T, E> catch { ... }
   • There are also blocks to consider:
     • catch R { ... }
     • try as R { ... } ?
   • I think consistency with async fn is probably valuable here
     • note that async { ... } blocks are also a thing
4. Given that we want this feature, is using the trappings of exception handling helpful or harmful?
   • There is after a key difference in the semantics of this feature: errors do not automatically unwind through multiple frames but rather must be manually propagated with ?
   • There are also implementation differences (e.g., we don’t use typical unwinding techniques) but those are less imp’t to my mind; after all, exceptions can be and sometimes are implemented using hidden return flags
   • The core question is, will using “exception terminology” be helpful to people learning or confusing?
   • I tend to think it is helpful: I think having something familiar makes it easier to learn the ways that error handling is different, in short.
     • This isn’t always true. The match between the syntax and the concepts have to be close enough. I think they are in this case.
   • This does imo argue slightly against the keyword catch (as opposed to say try) – using familiar keywords but in an unconventional way means that now you sort of have two things to learn. I’m not sure that’s a net win.

Anyway, that’s my best summary of how I see the state of the thread just now. I do hope to find the time to write out thoughts in more detail.

[phaylon]

As far as ergonomics goes, I often find the need to add Ok to be kind of a “mental impedance mismatch” – I forget it, then get an obscure compiler error, then add it. I think this is because code like foo()? + bar()? never has to talk about Err explicitly, so in a way it’s odd to have to talk about Ok

This kind of surprises me. The ? to me already explicitly implies (weird formulation, is there “explies”?) there’s a propagated failure path, so there has to be a happy path. For example, fn foo() -> SomeOpaqueTypeAlias { bar()? } already looks wrong to me, because it doesn’t acknowledge the happy path at all.

I’d also be interested in why you find the error for these cases to be obscure. Would improving the error message help? Maybe a message that is quicker to understand/recognize could improve the above kind of type intuition?

[nikomatsakis]

This kind of surprises me. The ? to me already explicitly implies (weird formulation, is there “explies”?) there’s a propagated failure path, so there has to be a happy path.

Yes, there is a happy path, what surprises me somehow is that I have to make clear via explicit syntax that the return value represents the happy path. The ? operator basically lets me think about “just the happy path” right up until the end when I still have to think about both paths.

Another way to say it: if you have a function like this:

fn foo() -> Result<..> {
    bar1()?:
    bar2()?;
    bar3()
}

there is some part of me that expects that “searching for ? should find me all the places that can error” (or perhaps also throw). But no, in fact there is a third spot – that final return.

[phaylon]

there is some part of me that expects that “searching for ? should find me all the places that can error” (or perhaps also throw). But no, in fact there is a third spot – that final return.

I think that’s where the main difference lies. I look at the example and my immediate reading is that the the function delegates it’s final result to bar3. If I wanted to do something with bar3s result in a later edit, I’d expect to be dealing with a Result of some kind. Or, if the return type of foo is too far up the file, I’d at least not expect it to be an unwrapped type.

[repax]

foo()? + bar()?

The Err case is very explicit to me too here, and I always think carefully about the exit points - failures and successes alike. The mere sight of a ? pings Result in my head, and I assure myself that the types I’m dealing with are what I expect. So I’d really like to see the Result<T, E> in the fn signature.

All that said:

• Given that we want this feature, try and fail sound better to me than catch and throw because they don’t carry the exception baggage. Their respective meanings are also clear in relation to each other and to the Result<T, E> return type:

fn foo() -> Result<T, E> try {
    let x: T = bar()?;
    if baz() { fail e; }
    x
}

[ranweiler]

Thank you for this summary, it really helps organize the many things going on here!

To me, a major strength of Rust is a very simple, core feature: I can use types as footholds in reasoning about my programs. Matching on enums (reasoning by cases!) is my favorite example of this.

I found myself struck by this line:

I think it could be very useful to think of error handling as “exceptions that one must manually propagate at each level” and then, once you’ve learned about enums etc, understand how that works under the hood.

This seems out-of-order: I would teach a new Rust user about enums immediately, long before the (important!) practical matter of using Result idiomatically.

Here is a data point from another language family: in the past, before I had a need to use them, I found myself a bit confused by async function and function* in JavaScript. The first time I went to use those features, it was while writing TypeScript. It was there, seeing the “external” return type written out, that made everything really click for me.

Now, conflating a T and a Promise<T>, or a T and a Result<T, E> can be either helpful or harmful. In the JS case, after seeing the concrete, true type of an async function, I found it easy to go back elsewhere (e.g. in a plain JavaScript codebase) and conflate the types in a way that was helpful: I always felt like I was on solid ground, because I had the true type in my head.

Similarly, when I have a Rust function that returns a Result<T, E>, I really do mostly think of its return type as a Result<T, E>, not a T– even when I locally want to conflate the two. Because of this, I have found it extremely easy to write my own error handling helpers, and think about how they might be composed.

The ? operator is really great, in that framing, because it lets me “unwrap or bail” explicitly. Note that I think of it as “bail”, as in early return, and not “throw an exception, kinda”. I know exactly where I’m bailing to: historically, the end of the function, or in the case of a catch block, another explicit, function-local place.

When I write error-handling in Rust, I am not thinking of ? as marking a “happy path” (like I might with, say, a hypothetical do notation): I am always thinking of as a shorthand for a particular (tedious, verbose) type of match-and-conditional-branch. In that sense, catch blocks are nice without the exception analogy, because I can think of it as “break from this block” (as if I were in a loop), vs. “return from this function”.

I happily use TypeScript’s try/catch for promises, and I like the idea of throw. But, unlike many languages, Rust has a sturdy foundation of real enums and pattern matching. I think that should be the framing that we emphasize and prioritize when teaching and improving error handling, whatever the syntax.

[phaylon]

I’d also like to give an example on where I find the explicit Result and Ok/Err notation provides more readability. In

fn generate(&self) -> Result<String, Error> {
    let mut out = String::new();
    self.render(&mut out)?;
    Ok(out)
}

If I look at function signatures, my brain separates them into Result, Option and “other” categories. I feel like that would be more complicated if there were additional ways of writing these.

Another thing is that I feel that ? and Ok support each other here. The implications of seeing ? have already been noted, but I feel like the Ok works here in the opposite way as well. I see Ok(out) and know there might be error handling involved. It makes it harder to overlook that ?.

I’d also be worried about readability when the return type is Result<Option<T>, E>. You might end up with Some and None identifiers clearly visible all throughout, but any ? would refer to a Result only showing up in the signature.

[scottmcm]

The ? operator basically lets me think about “just the happy path” right up until the end when I still have to think about both paths.

I really like this phrasing, so wanted to quote it for explit ing

But no, in fact there is a third spot – that final return.

Other things that make me sad about the difference there:

• It’s behaving subtly differently from the other two as well, since it’s not getting the error-conversion.
• It makes it harder to rearrange lines in the method, or to add another one after it. (The ?; here is, in a sense, sortof like the trailing , after a field or list element.)

[gdritter]

This is a pretty heavy thread, and I’ve gone through and I don’t think I’ve seen this exact point made, so I’m going to try to voice and justify it here:

I agree with @chriskrycho and am broadly skeptical of this proposal, I also would be a lot more comfortable with this proposal if it were implemented not with new syntax, but with some kind of macro or compiler plugin. In fact, I’d go so far as to say that I’d have a more positive reaction to this proposal if it were implemented with keywords that just looked like macros, even if there was still compiler-specific magic used to implement it!

A few points about why:

1. It’s pretty clear even to Rust learners that names that end with ! are sort-of-special but always desugar down to something else. I can look at a macro like println! or vec! and know, “This can’t necessarily be expressed as a function for whatever reason, but under this surface it’s still built of the same Rust building blocks.” This is one way to address learnability concerns: with throw and catch, there’s the danger (described by @chriskrycho and @regexident above) that learners will think that Rust has some weird special-cased errors system where you have to manually propagate exceptions, but names like throw! and #[catch] emphasize that the error system is still built of Rust values and expressions, and that these constructs are here to ease the burden of writing repetitive code, not because they’re compiler-sanctioned magic.

2. Implementing these features as macros would also clearly signify the degree to which they’re experimental: people expect macros, especially ones that might require a feature flag to import, to be more changeable and less stable than new built-in syntax, which means there’d be more freedom to notice problems and change them. A lot of the bikeshedding that’s happening in this thread could be resolved by saying, “Well, let’s just implement them all and then squint around the punctuation for a bit, and see what people like best.” I for one would be far more comfortable with an experimental macro than with syntax that could change on a new nightly!

3. Implementing these features as macros won’t introduce new syntactic features: this is good for people’s intuitions about Rust, as it simply says, “Ah, and these mark that something special happens to this declaration, or this expression.” As a nice side effect, the fact that totally new syntax is not introduced would also would play nicely with existing syntax highlighters or other tooling that would otherwise need to be updated to support new keywords and constructs.

4. There’s precedent for doing this kind of thing in a macro-like way: the async syntax is already written as #[async] and await!, which also has the advantages I’ve described here: it can be easily experimented with and iterated on, it doesn’t break existing non-rustc tooling (which is aware of macro-like items and where they can appear) and it’s also a way of communicating to the user that async code isn’t “magical”, it’s simply built out of tedious-to-write-and-read assemblages of Rust expressions.

5. With the try! macro in particular, we also have a precedent for building an abstraction as a macro, nailing down the exact semantics, and after it has become clear that the macro has desirable semantics but undue syntactic burden blessing it with built-in syntax. I would suspect (and probably prefer, for the reasons I describe in the first point above) that the abstractions proposed here could remain as macros indefinitely without too much burden, but it’s possible that I’m wrong, and that these features are indeed so useful and widespread that the !s and #[]s are too heavyweight: in that case, you’d still derive advantages from building these out as macros first, because it would give the entire community time to experiment with the semantics and bikeshed keywords and whatnot before settling on a concrete syntax that’s more pleasing to people.

I say all that with the caveat that I still don’t feel sold on the underlying idea: but, to the extent that I and others aren’t sold on them, I feel like building these features as macros would help sell me on them by demonstrating in a clear-but-not-committed way the advantages we’d get from this proposal.

[inejge]

A couple of empirical observations.

One compelling ergonomic advantage of this proposal which has intrigued me is the ability to turn an infallible function into a fallible one with a minimum of editing (see this post), so I attempted to find out how often the situation arises.

From a global alphabetical search on crates.io I filtered the first 1000 crates published in the previous year with at least five versions and a valid publicly accessible repository. Then I cloned each repository and searched all commits in the default branch for a combination of an added fn returning Result and a removed fn of the same name without a Result in the return type.

About 15% of repositories had at least one matching commit.

I don’t have a definitive analysis, but I suspect that my method produces a lot of false positives. I checked about 20 repos by hand, and found that matching commits in less than a half of them actually represented the transition to a fallible function. Some matches covered the use of type aliases; some caught refactorings which removed an infallible function and introduced unrelated fallible functions of the same name, etc. I believe that 7-10% is a more realistic result.

On the face of it, that’s not much. However, I’m aware that a search of this kind simply can’t detect things like exploratory integration and refactoring, where the ergonomic burden of switching between fallible and infallible versions exists as well. So, take with a grain of salt.

Another, and much easier, search was for a bare Ok(()) somewhere in the source, excluding tests and examples. About 46% of repositories had at least one.

---

As for my opinion on the syntax, I’d prefer to see Result verbatim in the return type. If bikeshedding is permitted, my preference would be for something like fn x() -> wrap Result<_, _> { ... } which would avoid the connotations of catch and fit nicely with Option. I know that catch is already reserved, and I’m not opposed to it in general.