Pre-RFC: Catching Functions

[mark-i-m]

Wanting to simplify code refactoring when adding error handling.

I would add one more thing under this: code should never be ambiguous in the sense that partially refactored code should not compile.

[phaylon]

I would add one more thing under this: code should never be ambiguous in the sense that partially refactored code should not compile.

I’m not sure this is entirely possible. A return None with a Option<Option<Value>> return type would work with auto-wrapping or without. Similar conditions can arise with Result and other types as well.

Or having some value than can be value.into() to both a Result and Option type with a Result<Option<Value>, Error> return value.

I would be surprised if this were 100% solvable when the types of return expressions can refer to different parts of the return type depending on context.

These types might seem obscure, but I do run into them sometimes, even the Result<Result<T, E>, E> one. An example would be nested parsing, where I want to distinguish between inner and outer errors later on for alternatives and error reporting.

[ranweiler]

@aturon, I just want to say thanks for your comments about the “killer combo” and demoralization, especially this line:

That is, where you sense inevitability, we sense exactly the opposite.

I felt a twinge of exactly this fear when I saw this thread (before I read it), and when I first heard murmurings about the recent module work. Rust’s development is exciting, but sometimes, it can feel very hard to feel on top of how various RFCs and ideas are evolving. I’m sure that’s true even for people who work on it full-time!

I have a lot of trust that folks like you, @nikomatsakis, @withoutboats, and others are always sincerely striving to do nothing but improve the language, but even that trust leaves room for a fear of being left in the dust. Hearing an explicit confirmation that you understand the “inevitability” dynamic is really reassuring.

[mark-i-m]

I’m not sure this is entirely possible. A return None with a Option<Option<Value>> return type would work with auto-wrapping or without. Similar conditions can arise with Result and other types as well.

Hmm… That seems to suggest that auto-wrapping would make it easier to write a new class of bugs. Do we know how common such patterns are in the wild?

[vorner]

Do we know how common such patterns are in the wild?

I don’t know about others, but I meet nested results from time to time, it’s definitely not an exception. Just today I wrote a commit that had at least two instances of these.

And even quite common libraries contain such types and interfaces: https://docs.rs/futures/0.1.17/futures/stream/trait.Stream.html#tymethod.poll (poll is type def for Result<Async<T>>).

So I’d guess these do exist in practice.

[newpavlov]

If we introduce Ok wrapping in try blocks it’s reasonable to make this wrapping mandatory and to cover only one level of wrapping, i.e. this code will result in a compilation errors:

try fn foo() -> Result<u32, E> {
    Ok(1u32)
}

try fn foo2() -> Result<u32, E> {
    Err(e)
}

try fn bar() -> Option<Option<u32>> {
    1u32
}

At first it could look a bit strange, but without this strict rule it will be much harder to reason about code behaviour. Thus you example will look like this:

try fn foo() -> Result<Result<u32, E1>, E2> {
    // returns Err(e1)
    if a { throw e1; }
    // returns Ok(Err(e2))
    if b { return Err(e2); }
    // returns Ok(Ok(1u32))
    Ok(1u32)
    // writing simply `1u32` will result in a compilation error
    // same goes for `return Ok(Ok(1u32))` and `return Ok(Err(e2))`
}

[mark-i-m]

I think this misses the point a bit… Suppose I start with the following function, which I now want to convert to be fallible:

fn foo() -> Result<u32, E1> {
  Ok(0u32)
}

If I simply change the signature, it still compiles, but might not be what the author expects:

try fn foo() -> Result<Result<u32, E1>, E2> {
  Ok(0u32)
}

This might be somewhat undesirable when doing large refactorings…

[newpavlov]

I think your example is overly artificial. You assume that two big changes will be introduced simultaneously: migrating to try fn and changing function return type. I believe such cases will be extremely rare to care about.

[phaylon]

You don’t need two changes:

fn foo() -> Result<Result<i32, String>, String> { Err("foo".into()) }

would still compile when you add try. The same is true for

fn foo() -> Option<Option<i32>> { None }

And, thinking about it, so would

fn foo() -> Option<i32> { 23.into() }

because impl<T> From<T> for T is available. Fortunately, you can’t go from a T to a Result<T, _> via Into.

I think that last one actually bothers me even more.

[josh]

A return None with a Option<Option<Value>> return type would work with auto-wrapping or without

This is one of many reasons I don’t want to see auto-wrapping of any kind.

[atagunov]

Forbid try functions/blocks where 2 or more levels of nested types implement Try? E.g. do not allow this?

try fn foo() -> Result<Result<u32, E1>, E2> {
    if a { throw e1; }
    if b { return Err(e2); }
    Ok(1u32)
}

P.S. This is the syntax to sway me from an opponent to a supporter. Also +1 for try and throw:

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
}

A tax on learners justified by a gain in ergonomics.

[mark-i-m]

Forbid try functions/blocks where 2 or more levels of nested types implement Try? E.g. do not allow this?

That would be a weird exception, right? Imagine I’m writing code. Everythings humming along. I’m planning to use this feature for consistency with the rest of my codebase. And… it doesn’t work because my return type happens to be Result<Option<T>, E>? That seems like poor UX. What would the compile error even be for that?

[glaebhoerl]

You don’t need two changes:

fn foo() -> Result<Result<i32, String>, String> { Err(“foo”.into()) }

would still compile when you add try. The same is true for

fn foo() -> Option<Option<i32>> { None }

These would also still compile if you, e.g., add a Some() around the None in the second case, or probably a variety of similar edits. Why is the case with try worse?

[nikomatsakis]

fn foo() -> Option<Option<i32>> { None }

I’m glad we’re talking about specific possible mistakes and confusions! This helps me quite a bit to understand what @josh means when talking about “type-based reasoning”.

I think these examples are interesting, but that patterns like Option<Option<u32>> already carry some element of risk. Consider what I and others have reported: that we almost always forget to write the final Some and Ok in a function that uses ?. In that case, there is a pretty decent chance that this function (which type-checks) is wrong, and it should have returned Some(None):

fn foo() -> Option<Option<u32>> {
    let x = process()?;
    let y = process()?;
    None
}

Personally, I have found in practice that nesting types like option (Option<Option<..>>) and result (Result<Result<...>>) is pretty confusing at best. When I find myself tempted to do so, I usually wind up creating newtypes or custom enums anyhow, precisely to catch mishaps like the one above, and to make the overall intent clearer.

[nikomatsakis]

I find that even as a supporter of the feature there are some questions that I really don’t know the answer to.

I want to clarify one more thing: I support the feature “for my personal use”, to some extent. One of the questions I don’t feel I know the answer to is whether this feature would “carry its weight” in terms of learnability, language surface area, overall impact on ergonomics, etc.

Ergonomically, I do think that we can do better when it comes to error handling in Rust, and that this feature would help – but I also think a big part of the problem arises around iterators that yield results and other related areas, and this feature wouldn’t help at all with that.

I am not yet sure if this would be a boon for learnability or not. I can see specific scenarios where it helps (e.g., working with libraries early on), but it also does increase the set of things to know, and that always comes at a cost.

[abe_egnor]

I want to add to Aaron’s excellent post that this thread has nullified my productivity since I started it. I wrote this sketch in 30 minutes, its nowhere near the end of the line, and there’s absolutely nothing inevitable about it. The reaction like this is both unwarranted and uncollegial.

I expected to receive a smattering of comments, constraints, iterations, etc, that I could review between other tasks during the week. I was faced with this deluge of feedback that had to become my primary focus. I also found it emotionally exhausting, because I have felt that every time I try to drill deeper into the nuance of the question I in turn receive very reactive, dramatic broad-strokes responses that don’t seem willing to drill down with me into the finer grain details of the trade offs involved.

What’s really unfortunate is that what this thread demonstrates to me that when an idea is at the “30 minute sketch” stage, if I suspect it will be at all controversial, I can’t post it on this forum or dealing with that thread will be what I am doing all week. I’m likely to turn to this forum less for early stage feedback like this. Instead I will develop ideas in a more private way and post them only when I can roll out elaborate and convincing narratives to go with them. This does not increase the influence of this community over the direction of my work.

I absolutely sympathize with the unpleasant surprise this was, but this is a deeply discouraging response. I had hoped that the Rust team would respond to this by iterating on feedback structure and shepherding, rather than by retreating into secrecy.

[nikomatsakis]

I absolutely sympathize with the unpleasant surprise this was, but this is a deeply discouraging response. I had hoped that the Rust team would respond to this by iterating on feedback structure and shepherding, rather than by retreating into secrecy.

I would also be sad if the end result of this process were a retreat into secrecy, but I don’t think that’s really what anybody has in mind. It is important to recognize though that the current process can be a stressful and tiring endeavor for everyone involved. I for one appreciate @withoutboats being honest about the cost to themselves – Rust team members are only human, after all – and I also appreciate @josh and others for sharing their similar feelings of frustration.

In any case, I do think it’s worth thinking more if there are changes we can make to try and get a more collegial (to use @withoutboats’s word) setup. We’ve talked in the past about “motivation RFCs” and also looked at other interesting precedents, such as the TC39 Process, which has explicit stages like “strawman” and so forth, where the only goal is to get people to accept that there’s an interesting problem that may be worth solving.

In the past when we’ve tried this, we’ve often found that separating “the motivation” from “possible solutions” is hard – it’s hard to describe the problem without sketching alternatives. But it may be worth taking another stab in that direction regardless.

I sort of like the idea of an explicit phase in the process that is aimed just at showing the problem, with the explicit premise that any possible solutions being shown are just there to demonstrate the vague kind of solution we have in mind.

I admit I don’t quite know what this looks like yet – it seems like something we have to try and few times.

[phaylon]

Why is the case with try worse?

Because there’s (at least for me) usually a relation of the expression and the return value. If we add things like try, we’ll add additional points into that relation.

Plus, the point was about “making sure things don’t compile for half-refactored code” concerning error handling.

[phaylon]

I think these examples are interesting, but that patterns like Option<Option<u32>> already carry some element of risk. Consider what I and others have reported: that we almost always forget to write the final Some and Ok in a function that uses ?. In that case, there is a pretty decent chance that this function (which type-checks) is wrong, and it should have returned Some(None):

Of course, but that’s not a good argument to me for making it more risky. If you change None to Some(None) you’re actually changing logic. If you go from try to non-try or vice-versa, you’re trying to not change the logic.

Personally, I have found in practice that nesting types like option (Option<Option<…>>) and result (Result<Result<…>>) is pretty confusing at best. When I find myself tempted to do so, I usually wind up creating newtypes or custom enums anyhow, precisely to catch mishaps like the one above, and to make the overall intent clearer.

Sure, so do I, but that won’t work for combining two traits that both have associated types that have to be combined and are Option<T>.

What do you think about the 23.into() case for Option<i32>?

[atagunov]

I have found in practice that nesting types like option (Option<Option<..>>) and result (Result<Result<...>>) is pretty confusing

…and since it’s an obscure corner case - is it the lesser evil to ban try on such functions?