Tracking issue for `?` operator and `try` blocks (RFC 243, `question_mark` & `try_blocks` features)

[nikomatsakis]

Tracking issue for rust-lang/rfcs#243 and rust-lang/rfcs#1859.

Implementation concerns:

• ? operator that is roughly equivalent to try! - #31954
• catch { ... } expression - #39849
  • resolve do catch { ... } syntax question
    • Resolved as try { .. }, - #50412
  • resolve whether catch blocks should "wrap" result value (#41414)
• settle design of the Try trait (rust-lang/rfcs#1859)
  • implement new Try trait (in place of Carrier) and convert ? to use it (#42275)
  • add impls for Option and so forth, and a suitable family of tests (#42526)
  • improve error messages as described in the RFC (#35946)
• reserve try in new edition
• block try{}catch (or other following idents) to leave design space open for the future, and point people to how to do what they want with match instead

[reem]

The accompanying RFC discusses a desugaring based on labeled return/break, are we getting that too or will there just be special treatment for ? and catch in the compiler?

EDIT: I think labeled return/break is an excellent idea separate from ? and catch, so if the answer is no I will probably open a separate RFC for it.

[nikomatsakis]

Labeled return/break is purely for explanatory purposes.

On Fri, Feb 5, 2016 at 3:56 PM, Jonathan Reem notifications@github.com
wrote:

The accompanying RFC discusses a desugaring based on labeled return/break,
are we getting that too or will there just be special treatment for ? and
catch in the compiler?

—
Reply to this email directly or view it on GitHub
#31436 (comment).

[glaebhoerl]

Another unresolved question we have to resolve before stabilizing is what the contract which impls of Into have to obey should be -- or whether Into is even the right trait to use for the error-upcasting here. (Perhaps this should be another checklist item?)

[petrochenkov]

@reem

I think labeled return/break is an excellent idea ... I will probably open a separate RFC for it.

Please do!

[thepowersgang]

On the subject of the Carrier trait, here is a gist example of such a trait I wrote back early in the RFC process.
https://gist.github.com/thepowersgang/f0de63db1746114266d3

[petrochenkov]

How this is treated during parsing?

struct catch {
    a: u8
}

fn main() {

    let b = 10;
    catch { a: b } // struct literal or catch expression with type ascription inside?

}

[eddyb]

@petrochenkov Well, the definition couldn't affect parsing, but I think we still have a lookahead rule, based on the second token after {, : in this case, so it should still be parsed as a struct literal.

[petrochenkov]

Also

let c1 = catch { a: 10 };
let c2 = catch { ..c1 }; // <--

struct catch {}
let c3 = catch {}; // <--

+ rust-lang/rfcs#306 if (when!) implemented.
It seems like there are no conflicts besides struct literals.

Given the examples above I'm for the simplest solution (as usual) - always treat catch { in expression positions as start of a catch block. Nobody calls their structures catch anyway.

[durka]

It would be easier if a keyword was used instead of catch.

[bluss]

This is the keywords list: http://doc.rust-lang.org/nightly/grammar.html#keywords

[durka]

@bluss yeah, I admit none of them are great... override seems like the only one that is close. Or we could use do, heh. Or a combination, though I don't see any great ones immediately. do catch?

[bluss]

do is the only one that seems to be close IMO. A keyword soup with do as prefix is a bit irregular, not similar to any other part of the language? Is while let a keyword soup as well? That one feels ok now, when you are used to it.

[est31]

port try! to use ?

Can't ? be ported to use try! instead? This would allow for the use case where you want to get a Result return path, e.g. when debugging. With try! this is fairly easy, you just override the macro at the beginning of the file (or in lib/main.rs):

macro_rules! try {
    ($expr:expr) => (match $expr {
        Result::Ok(val) => val,
        Result::Err(err) => {
            panic!("Error occured: {:?}", err)
        }
    })
}

You will get a panic stack trace starting from the first occurrence of try! in the Result return path. In fact, if you do try!(Err(sth)) if you discover an error instead of return Err(sth), you even get the full stack trace.

But when debugging foreign libraries written by people who haven't implemented that trick, one relies on try! usage somewhere higher in the chain. And now, if the library uses the ? operator with hardcoded behaviour, getting a stacktrace gets almost impossible.

It would be cool if overriding try! would affect the ? operator as well.

Later on when the macro system gets more features you can even panic! only for specific types.

If this proposal requires an RFC please let me know.

[rpjohnst]

Ideally ? could just be extended to provide stack trace support directly, rather than relying on the ability to override try!. Then it would work everywhere.

[durka]

Stack traces are just one example (though a very useful one, seems to me).
If the Carrier trait is made to work, maybe that can cover such extensions?

On Sun, Feb 7, 2016 at 4:14 PM, Russell Johnston notifications@github.com
wrote:

Ideally ? could just be extended to provide stack trace support directly,
rather than relying on the ability to override try!. Then it would work
everywhere.

—
Reply to this email directly or view it on GitHub
#31436 (comment).

[est31]

Without wanting to speculate, I think that it could work, albeit with some issues.

Consider the usual case where one has code returning some Result<V,E> value. Now we would need to allow for multiple implementations of the Carrier trait to coexist. In order to not run into E0119, one has to make all implementations out of scope (possibly through different traits which are per default not imported), and when using the ? operator, the user is required to import the wished implementation.

This would require everybody, even those who don't want to debug, to import their wished trait implementation when using ?, there would be no option for a predefined default.

Possibly E0117 can be an issue too if wanting to do custom Carrier implementations for Result<V,E>, where all types are outside bounds, so libstd should provide already provide a set of implementations of the Carrier trait with the most used use cases (trivial implementation, and panic! ing implementation, perhaps more).

Having the possibility to override via a macro would provide a greater flexibility without the additional burden on the original implementor (they don't have to import their wished implementation). But I also see that rust never had a macro based operator before, and that implementing ? via a macro isn't possible if catch { ... } is supposed to work, at least not without additional language items (return_to_catch, throw, labeled break with param as used in RFC 243).

I am okay with any setup which enables one to get Result stacktraces with an Err return path, while having only to modify a very small amount of code, prefferably at the top of the file. The solution should also work unrelated to how and where the Err type is implemented.

[rphmeier]

Just to chime in on bikeshedding: catch in { ... } flows pretty nicely.

[durka]

catch! { ... } is another backcompat choice.

[durka]

Also, not that I expect this to change anything, but a note that this is going to break multi-arm macros that were accepting $i:ident ?, in the same way that type ascription broke $i:ident : $t:ty.

[dgrunwald]

Don't overdo the backwards compatibility, just treat catch as a keyword when followed by { (possibly only in expression position, but I'm not sure if that changes much compatibility-wise).

I can also imagine some possible problems that don't involve struct literals (e.g. let catch = true; if catch {}); but I prefer a minor breaking change over a more ugly syntax.

Didn't we have a for adding new keywords, anyways? We could offer some kind of from __future__ opt-in for new syntax; or specify a rust language version number on the command-line / in Cargo.toml.
I highly doubt that in the long term, we'll be able to work with only those keywords that are already reserved. We don't want our keywords to have three different meanings each, depending on context.

[glaebhoerl]

I agree. This isn't even the first RFC where this has come up (rust-lang/rfcs#1444 is another example). I expect it won't be the last. (Also default from rust-lang/rfcs#1210, although it's not an RFC I'm in favor of.) I think we need to find a way to add honest-to-god keywords instead of trying to figure out how to ad-hoc hack the grammar for every new case.

[rkjnsn]

Wasn't the whole argument for not reserving several keywords prior to 1.0 that we'd definitely be introducing a way to add new keywords to the language backward compatibly (possibly by explicitly opting in), so there was no point? Seems like now would be a good time.

[aturon]

@japaric Are you interested in reviving your old PR and taking this on?

[japaric]

@aturon My implementation simply desugared foo? in the same way as try!(foo). It also only worked on method and function calls, i.e. foo.bar()? and baz()? work but quux? and (quux)? don't. Would that be okay for an initial implementation?

[eddyb]

@japaric What was the reason for restricting it to methods and function calls? Wouldn't parsing it be easier as a general postfix operator?

[earthengine]

As all check boxes are ticked in the top post, when would us move forward? If there are still unresolved issues we need to have new check box(es) added.

[Centril]

There are probably plenty of remaining unresolved questions not recorded.
For example, the ok-wrapping behavior is not settled within the lang team, the design of the Try is not finalized, and so on. We should probably split this issue up into several more targeted ones as it has likely outlived it's usefulness.

[mark-i-m]

Hmm... it bothers me that these questions haven't been recorded.

[Centril]

@mark-i-m So to clarify, I think they have been somewhere; but not in one location; it's a bit scattered atm in various RFCs and issues and such, so what we need to do is record them in the proper locations.

[scottmcm]

The design of the backing trait is tracked in #42327; there's extensive discussion there about weaknesses in the current one and a possible new direction. (I'm planning of making a pre-RFC for a change there once 2018 settles a bit.)

So I think only try{} is left here, and the only disagreement I know of for that are things that were settled in the RFC and re-confirmed in one of the above-mentioned issues. It could still be good to have a distinct tracking issue, though.

I'll add a checkbox for the one pending implementation task I know still needs to be done...

[Centril]

@scottmcm I know @joshtriplett had concerns about OK-wrapping (noted in the try RFC) and I'd personally like to restrict break in the initial stabilization of try { .. } so that you can't do loop { try { break } } and such.

[earthengine]

@Centril

so that you can't do loop { try { break } }

Right now, you cannot use break in a non-loop block, and it is correct: break should only be used in loops. To early leave a try block, the standard way is to write Err(e)?. and it forces that early leaves are always in the "abnormal" control path.

So my proposal is the code you shown should be allowed, and it should break the loop, not just leaving the try.

The immediate benefit, is when you see break you know it is going break from a loop, and you can always replace it with a continue. Also, it removes the need to having to label the break point when using try blocks inside a loop and you want to exit the loop.

[joshtriplett]

@Centril Thank you for raising those.

Regarding break, I personally would be fine with simply saying that try doesn't care about break and it passes through to the containing loop. I just don't want break to interact with try at all.

As for Ok-wrapping, yes, I'd like to address that before stabilizing try.

[scottmcm]

@Centril Yes, I'm aware. But it's important to remember that that's re- re- raising the issue. The RFC decided to have it, it was implemented without it, but then the original intent was taken again, and the implementation changed to follow the RFC. So my big question is whether any material facts have changed, especially given that this is one of the noisiest topics I've ever seen discussed on RFCs+IRLO.

[Centril]

@scottmcm Of course, as you know, I agree with retaining Ok-wrapping ;) and I agree that the issue should be considered settled.

[fschutt]

I just wanted to comment on this, not sure if this is the right thing:

Essentially, a situation I have is callbacks in a GUI framework - instead of returning an Option or Result, they need to return a UpdateScreen, to tell the framework if the screen needs to be updated or not. Often I don't need logging at all (it's simply not practical to log on every minor error) and simply return a UpdateScreen::DontRedraw when an error has occurred. However, with the current ? operator, I have to write this all the time:

let thing = match fs::read(path) {
    Ok(o) => o,
    Err(_) => return UpdateScreen::DontRedraw,
};

Since I can't convert from a Result::Err into a UpdateScreen::DontRedraw via the Try operator, this gets very tedious - often I have simple lookups in hash maps that can fail (which isn't an error) - so often in one callback I have 5 - 10 usages of the ? operator. Because the above is very verbose to write, my current solution is to impl From<Result<T>> for UpdateScreen like this, and then use an inner function in the callback like this:

fn callback(data: &mut State) -> UpdateScreen {
     fn callback_inner(data: &mut State) -> Option<()> {
         let file_contents = fs::read_to_string(data.path).ok()?;
         data.loaded_file = Some(file_contents);
         Some(())
     }
    
    callback_inner(data).into()
}

Since the callback is used as a function pointer, I can't use an -> impl Into<UpdateScreen> (for some reason, returning an impl is currently not allowed for function pointers). So the only way for me to use the Try operator at all is to do the inner-function trick. It would be nice if I could simply do something like this:

impl<T> Try<Result<T>> for UpdateScreen {
    fn try(original: Result<T>) -> Try<T, UpdateScreen> {
        match original {
             Ok(o) => Try::DontReturn(o),
             Err(_) => Try::Return(UpdateScreen::DontRedraw),
        }
    }
}

fn callback(data: &mut State) -> UpdateScreen {
     // On any Result::Err, convert to an UpdateScreeen::DontRedraw and return
     let file_contents = fs::read_to_string(data.path)?;
     data.loaded_file = Some(file_contents);
     UpdateScreen::Redraw
}

I am not sure if this would be possible with the current proposal and just wanted to add my use-case for consideration. It would be great if a custom Try operator could support something like this.

[KrishnaSannasi]

EDIT:
I made a mistake.

---

Ignore this post

---

Could this play better with type inference, it fails even in simple cases.

fn test_try(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };
    
    let x // : Option<_> // why is this type annotation necessary
    = try { div? + 1 };
    
    println!("{:?}", x);
}

If this is re-written to use a closure instead of the try block (and in the process loose auto wrapping), then we get

fn test_closure(a: u32, b: u32) {
    let div = if b != 0 {
        Some(a / b)
    } else {
        None
    };
    
    let x =  (|| (div? + 1).into())();
    
    println!("{:?}", x);
}

Which doesn't require a type annotation, but it does require that we wrap the result.

playground

[Nemo157]

@KrishnaSannasi your closure based example has a type inference failure as well (playground) because Into doesn't constrain the output and you don't use it anywhere that does later.

This seems to mostly be an issue with the Try trait rather than try blocks, similar to Into it doesn't propagate any type information from the inputs to the output, so the output type must be determinable by its later usage. There's a lot of discussion in #42327 about the trait, I haven't read it so I'm not sure if any of the proposals there could fix this issue.

[KrishnaSannasi]

@Nemo157

Yes, I did a last minute change to my code, to make it use into, and didn't test that. My bad.