Pre-RFC: flexible `try fn`

[newpavlov]

Take Record example, how do you see Try<Return, Throw> implemented for it? Also it allows type to implement only one trait if needed.

[CAD97]

Ah, right, because it’s a many-many relationship between return-cases and throw-cases.

But what would implementing just one mean? Would this then be return coercion with TryReturn and throw coercion with TryThrow?

Could you have a fn -> Return where Return <: ThyThrow, !TryReturn?

[newpavlov]

Would this then be return coercion with TryReturn and throw coercion with TryThrow ?

Yes, it will be.

And yes, technically it will be possible to create types which implement only TryThrow. If try fn returns such type, the only way to “return” something from this function will be through throw, which seems quite useless. Ideally we would like to put restriction on TryThrow “can be implemented only if at least one TryOk implementation exists”, but AFAIK we can’t express it in the current Rust.

[scottmcm]

I don’t think this is “extreme” at all – I was planning on writing something very similar once the initial async fn and try {} implementations landed in the compiler.

More prior art:

• RFC #2107, Ok wrapping: Improved support for writing code from an error handling mindset
• Pre-RFC: Throwing Functions

My proposed direction: async and try are both effects, and should work similarly

• You never need to use async nor try nor await nor ?; you can use combinators instead, or call methods, or just match, or implement the traits directly
• You “undo” async with await; you “undo” try with ?
• Both have carrier types: For async/await it’s impl Async<Output = T>; for try/? today it’s impl Try<Ok = T> (though likely to change – see below – maybe impl Bubble<Output = T>)
• There are both “delayable” effects: you can call foo() at one point – maybe not even in async/try context – then await/? it later
  • (In comparison, const and unsafe don’t have carrier types and can’t be delayed – you of course can’t do let x = foo(); let y = unsafe { x }; the way you can do let x = foo() let y = x?; or let x = foo(); let y = await!(x);)
• Today we have .try_from() and TryFrom naming conventions where there’s conflicts with infallible; I wouldn’t be surprised to also get .read_async() and ReadAsync naming conventions where there’s conflicts with synchronous
• Accepted RFCs have it so that you can use an async {} block to write asynchronous code in “similar to synchronous” style, and so that you can use a try {} block to write fallible code in “similar to infallible” style, with explicit markers in both cases for the things that are actually async/try
  • (Note that “what happens with return in a try block?” was a point of contention in the try RFC, and it’s just not allowed in an async block, so one simple and can-always-be-loosened-later option would be to prohibit it in try blocks too, initially.)
• If a whole function or closure wants that style, then it can be defined as async fn or async ||, and, I would propose try fn or try ||
  • The async RFC decided that it’s async move ||, so it should also be try move ||
• The body of such a function, block, or closure is automatically wrapped in the appropriate carrier type – it’s async { 4 } or try { 4 }, not async { Poll::Ready(4) } or try { Some(4) } – including a return expression in a function or closure

One difference is that await is only allowed in a context that’s explicitly been marked async, whereas ? can be used with just a compatible return type. We certainly shouldn’t remove that immediately, but I’d definitely be in favour of an opt-in clippy lint to block use of ? outside of try, because today ? is more than a fallibility marker, it’s also a “I’m thinking of the code here in the success-is-continue model”. And I think that an individual call is the wrong granularity for that choice: it should be a block (including, perhaps, the block that’s the body of a function). I personally find something like return Err(foo()?) dissonant, since the ? implies that continuing on is success, but then it’s not. (I also wonder if those opposed to ? would be less so if there was try as a “warning, you should expect ?s in here” marker around any use thereof.)

Similarly, I think it would make sense to start with a throw expression that’s allowed only in try context, since that immediately gets rid of the “when should I write throw x instead of return Err(x) question”. Whether it would stay that way I don’t know, though, since @Centril pointed out that it makes it harder to use in a broadly-applicable macro.

The other big question is how to write return types. RFC 2394 calls it a “complicated question”, ending up picking -> T instead of -> impl Async<Output=T> because of lifetime elision implications and a lack of need for polymorphic return. I’ve yet to see a -> T throws E syntax I’m happy with, so prefer just -> Result<T, E>. Interestingly, I think try hits exactly the opposite arguments as async here: a try fn doesn’t need to capture all the input lifetimes, so there aren’t the same gotchas with the full type, and since ?and try{} are polymorphic today, I think it’s important for a try fn to also support non-Result return types.

As for the traits, see the try_trait tracking issue. Specifically, this comment for your TryOk and this comment for your TryThrow. They’re roughly similar, though with some different choices around associated types and bounds to achieve goals like "typeof(x?) depends only on typeof(x), not on context". (And note the mention of “try functions” in that thread as well )

(Oh man, that came out way longer than I was expecting…)

[newpavlov]

Great comment!

I’ve called the proposed approach “a bit extreme”, due to the (usually unneeded) flexibility introduced by using generic type parameter instead of the associated type in the Try traits. Regarding return type we can’t use -> T throws E, because we would like for this feature to work at least with Option<T> and ideally with custom types as well, so this is why I think using an exterior type for try fns is the most sensible choice.

As for forbidding ? outside of the try contexts, I think it’s an interesting option, which is definitely will be worth exploring after stabilization of try language features as preparation to the post-2018 epoch.

[DDOtten]

For Return this changes

• return Ok(x) into return x;
• return Err(y) into throw y;

and to be honest I don’t really think that would be an improvement at all. This would create two different ways of doing things without becoming more readable or more ergonomic. This would also allow another thing before fn with would lead to things like unsafe const async try fn where it would be very hard to remember the order these things should go in.

To be honest I am against Ok wrapping in general because it reduces local reasoning and increases the complexity of the language just to save 4 characters, including the braces.

I also think that @repax’s named block proposal is a beter option than adding the try keyword mostly because it uses an existing underused language feature instead of adding an entirely new thing. It also really fits with the way other returns allow you to use labels.

[bill_myers]

For the return types problem, one could have syntax like this:

async(MyFuture) fn foo() -> i32 {...}

try(MyResult) fn bar() -> i32 {...}

[Centril]

This would create two different ways of doing things

This is true, but I also don’t believe it will become a problem in practice. It is clear to me that given the choice between fn + return Ok(x) and try fn + Ok(x), we should heavily lint in favor of try fn as the idiomatic choice. This eliminates the “analysis paralysis” / “decision fatigue”.

becoming more readable or more ergonomic

This is debatable. I think the winnings in terms of simple syntax for being generic over Try carriers is important.

Another major benefit, from my perspective is that it removes the noise of Ok and Err, which is just pure plumbing in your computation, and instead allows you to focus on your problem domain. The focus on the problem domain will also show in the code and thus make it more readable. This is fundamentally what monads are about, they get rid of the plumbing. Since we Rust isn’t a pure functional language, monads won’t work well here, so we use something more tailored for Rust.

Furthermore, try scales better. It is just one annotation at one place; If you have many early return and failure paths, then it can become quite noisy.

Finally, I think this is a case of a major increase to readability globally. While you might not “save more than a few characters” at each point, try fn will (I predict) become so commonplace that the net win becomes quite large.

Here’s an example using try fn and postfix macros to clean up some code from rfcbot real nicely:

impl Team {
    try fn validate(&self) -> DashResult<()> {
        use domain::schema::githubuser::dsl::*;
        let conn = &*(DB_POOL.get()?);

        for member_login in self.member_logins() {
            let test = githubuser.filter(login.eq(member_login))
                                 .first::<GitHubUser>(conn);
            test.unwrap_or! { err =>
                error!("unable to find {} in database: {:?}", member_login, why);
                throw err
            }
        }
    }
}

This would also allow another thing before fn with would lead to things like unsafe const async try fn where it would be very hard to remember the order these things should go in.

This is not a problem. It is easily solved by just allowing any permutation of unsafe const async try. In terms of BNF:

effect  ::= "unsafe" | "const" | "try" | "async" ;
vis     ::= "pub" | ... ;
fundecl ::= vis? effect* "fn" ... ;

To make code more uniform and readable, rustfmt will then normalize unsafe const async try into a standard form. But while writing code, it should not be a hindrance.

To be honest I am against Ok wrapping in general because it reduces local reasoning and increases the complexity of the language just to save 4 characters, including the braces.

Would you similarly be fine with typing function instead of fn? The latter only saves 6 characters.

How does it reduce local reasoning and is fallibility-plumbing important for the reasoning? It is true that reasoning becomes function-local instead of expression local, but that hardly seems like a big problem if you don’t write absurdly long functions (but then you have other reasoning problems on your hand…).

[phaylon]

I just want to reiterate my position that Ok, Err, Some and None are not seen as “noise” by everyone. Personally, I find them to be important markers in code.

The rfcbot code is a good example. It took me a moment to see how and where it’s decided that things are valid. A trailing Ok(()) is a simple marker communicating “everything is ok if the function makes it to the end.”

[Centril]

It took me a moment to see how and where it’s decided that things are valid

With try fn, the assumption is that if not stated otherwise, everything went OK.

I find this easier to reason about, and it is also the way you reason in many mainstream languages with exception handling (but we can also get the benefits of errors as values and eat our keep it…).

The moment this took you could (you know yourself best of course…) also be a factor of being used to the current model of writing Ok(..).

[phaylon]

With try fn , the assumption is that if not stated otherwise, everything went OK.

In my opinion putting the Ok at the point of decision (in other words: the end) is the superior signal. Especially since it’s a signal that works everywhere. If a match arm decides success, there’s return Ok. It works the same for functions, closures, blocks, assignments, function arguments, and all block or expression macros.

Similarly, in this coding style, the absence of Ok, Err, etc. means something else makes the decision.

[newpavlov]

Aside from somewhat subjective notion regarding noisiness of Ok(()) (though I certainly will not miss it) and ability to focus on the problem at hand, another argument for Ok wrapping discussed in the @withoutboats’s “catching functions” thread is a shorter editing distance between fallible and infallible functions. Imagine this function:

fn foo() -> u64 {
    // N returns here
   let data = bar().unwrap();
   // M returns here
   if !check_stuff() { panic!("check failed") }
   // K returns here
}

Now we want to make this function fallible (e.g. we decided to remove unwraps after initial prototyping), today we’ll have to find all returns and do Ok wrapping manually. While with this proposal we’ll just write:

try fn foo() -> Result<u64, MyError> {
    // N returns here
   let data = bar()?;
   // M returns here
   // or Err(MyError("check failed"))? if we decide to drop `throw` keyword`
   if !check_stuff() { throw MyError("check failed"); }
   // K returns here
}

It’s clear that try fn allows much faster refactoring of the code in such cases. Arguably good IDE could help with such changes, but in my opinion it’s a bad argument.

[troiganto]

What worries me somewhat about this proposal is that not only error types get converted automatically when returned via throw, but success types as well. Specifically, this example from the OP:

// converts `1` and `"ok"` into `Foo` automatically
try fn foo1() -> Foo {
    if true { return 1; }
    return "ok";
}

Because From::from() is a potentially expensive operation, I feel this goes too much against Rust’s tendencies to make such operations explicit. This is why we don’t automatically convert from &str to String, for example.

My (subjective) opinion is that at least in this example, I would prefer seeing the .into() on both returns, noisy as they may seem to others.

[phaylon]

My arguments against the editing distance point would be:

• I’ll still have to update all call sites anyway.
• Having a review of the function is a good idea anyway when you introduce a new early return or add error handling. In your example not doing this might lead to a missed panic site.
• I’d consider writing convenience less important than clarity when reading.

[newpavlov]

What worries me somewhat about this proposal is that not only error types get converted automatically when returned via throw , but success types as well.

I think you misunderstood the proposal a bit, in Foo example author will have to explicitly opt into such conversions by implementing Try traits for Foo as he sees fit, it will not be done automatically. For Result and Option there is no automatic conversion for TryOk, and into() is used only for errors, which is equivalent to that ? currently does.

I’d consider writing convenience less important than clarity when reading.

My example was about an objective advantage of try fn, as for subjective I personally think that try fn will make reading and understanding code easier, not harder, because it will allow to focus on happy path, which usually contains the most important program logic. (i.e. I agree with @Centril )

[Ixrec]

I’ve heard this “editing distance” argument before, but I’ve never seen a post that actually demonstrated it. Since you’ve left out the “do Ok wrapping manually” case and are hiding most of the snippets behind comments, I have no way of seeing that there’s a significant benefit here unless I’ve already been convinced that try functions are a win.

Could you flesh out your example so those of us who are not convinced can see what you’re seeing?

[phaylon]

My example was about an objective advantage of try fn , as for subjective I personally think that try fn will make reading and understanding code easier, not harder, because it will allow to focus on happy path, which usually contains the most important program logic.

Sure. I was just stating that that while having to write less is/can be a plus, when weighing it against the downsides it has for me, I’ll always prefer to write out those Oks, Errs and so on.

The “happy path” argument I believe also has its downsides. While you can often simply consider the happy path, once you start hiding the unhappy path it of course becomes harder to notice it. And the points where happy and unhappy paths diverge are the most important to me. I wouldn’t want to hide the points where unhappiness gets involved when I’m mutating things, for example.

[troiganto]

I think you misunderstood the proposal a bit, in Foo example author will have to explicitly opt into such conversions by implementing Try traits for Foo as he sees fit, it will not be done automatically. For Result and Option there is no automatic conversion for TryOk , and into() is used only for errors, which is equivalent to that ? currently does.

I see, thanks for the clarification!

[newpavlov]

It’s kinda hard to write artificial example for this, and on small examples it does not look impressive. Good isolated examples will be:

fn do checks() {
    if !check1() { panic!("check1") }
    if early_return() { return; }
    if !check2() { panic!("check2") }
    // etc..
}
//lets make it fallable
fn do checks() -> Result<(), MyError> {
    if !check1() { Err(MyError::Check1)? } // ugh, strange pattern
    if early_return() { return Ok(()); } // I don't care about `Ok`, just end!
    if !check2() { return Err(MyError::Check1); } // too verbose...
    // etc..
    Ok(()) // argh, always forget to add this line...
}
// with try fn
try fn do checks() -> Result<(), MyError> {
    if !check1() { throw MyError::Check1; } // intention is crystal clear
    if early_return() { return; } // with minimal changes
    if !check2() { throw MyError::Check2; } // and easy to read
    // etc..
    // no weird (especially for beginners) `Ok(())` at the end
}

fn foo(val: Foo) -> Bar {
    match val {
        // several match arms
        Foo::K => {
            // do stuff
            if condition() { return Bar::D; }
            // do stuff
            Bar::K
        },
        // more match arms
       _ => panic!("unexpected variant"),
    }
}
// Again lets make it fallible
fn foo(val: Foo) -> Result<Bar, MyError> {
    // ehm, maybe I should write `let bar = match val { .. }; Ok(bar)`...
    Ok(match val {
        // several match arms
        Foo::K => {
            // do stuff
             // again, always forget those returns buried  in a middle
             // of the function body, esp. if block was folded
            // even worse if there is many such returns, repeating Ok(..)
            // becomes quite annoying
            if condition() { return Ok(Bar::D); }
            // do stuff
            Bar::K
        },
        // even more match arms
       _ => Err(MyError::UnexpectedVariant)?,
    })
}
// with `try fn`
try fn foo(val: Foo) -> Result<Bar, MyError> {
    // no changes required, no `Ok` noise
    match val {
        // several match arms
        Foo::K => {
            // do stuff
             // everything stays as is
            if condition() { return Bar::D; }
            // do stuff
            Bar::K
        },
        // even more match arms
       _ => throw MyError::UnexpectedVariant,
    }
}

Isolated it does not seem like much, but when writing code I often get bitten by such papercuts, and it is not fun.

[MajorBreakfast]

fn foo(data: &[u8]) -> Record {

Missing try keyword. (This is in the proposal. I haven’t read the thread yet)