Pre-RFC: Catching Functions

[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?

[ssokolow]

While pure has been retracted, nobody seems to have mentioned one of the most fundamental intuitiveness issues it had:

Things like let, match, try!, catch, return, throw, raise, wrap, etc. are consistently verbs. pure is an adjective like public, mutable, or static, which generally implies it to be part of a type or function signature.

Having a consistent ruleset for relating programming language grammar and natural language grammar is the first layer that contributes to intuitiveness.

Also, since that comment could come across as an implicit “I’m in favour… given the right bikeshedding”, I’ll clarify that, having read the entire thread, I share the fundamental concerns expressed by @chriskrycho and @H2CO3 and the mindset expressed by @ranweiler and @josh

[ssokolow]

I have to agree with that. Even having contributed to the discussion in several RFCs (eg. analogizing .. and ..= to < and <=), “Pre-RFC” feels so formal that I still found myself caught up in a “this is too important to risk waiting for an RFC” pseudo-panic and the only thing holding me back was the knowledge that I didn’t really have much to say that hadn’t already been said better by someone else. (Though it did lead me to stay up hours beyond bedtime, religiously liking the replies I agreed with.)

Perhaps just Idea: as the prefix? It’d still be a distinctive string but, at the same time, feels quite informal to me. (More in the vein of “This came to me while I was on the bus. What does everyone think?”)

It would also have the benefit of possibly increasing suggestions, since, not really knowing what the rules are for a “Pre-RFC”, I’ve been operating under the assumption that I’m not even qualified to write one without embarassing myself.

(I have no background in language design and my programming experience has been results-oriented, so I never spent any time in “language theorists’ playground” languages like Haskell or more than one single-semester beginner’s C/C++ class in “you’ll eventually either sink or figure out some aspect of the machine model” languages.)

[josh]

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

Agreed completely.