Stream: project-error-handling

Topic: Wishlist for `?`/`try{}`/`Try`?


view this post on Zulip scottmcm (Nov 24 2020 at 07:08):

Hi folks! I've been intending to write a new pre-RFC for making Try work differently to support some additional stuff.

The blog post made me think I should drop by here first to see if you have anything your group had been thinking about.

One thing on my list, for example, was that it would be nice to be able to write a type that can accept _any_ error type, rather than the From restrictions that currently exist.

view this post on Zulip Jane Lusby (Nov 24 2020 at 19:21):

I'm interested but for the most part we've decided that Try and company are out of scope for this project grou

view this post on Zulip Jane Lusby (Nov 24 2020 at 19:21):

thats more of a lang team thing, but I'm curious what you mean by "accept any error type rather than with From restrictions"

view this post on Zulip scottmcm (Nov 24 2020 at 23:59):

Right now Result<_, E> -> Result<_, F> in ? needs F: From<E>, but it's hard to add blankets to that. I was imagining, for example, a type that could be used in main that would allow essentially anything to be ?'d.

view this post on Zulip Jane Lusby (Nov 24 2020 at 23:59):

sure

view this post on Zulip Jane Lusby (Nov 25 2020 at 00:00):

and this is kinda what anyhow::Error / eyre::Report do, though they explicitly don't impl Error to manage it

view this post on Zulip Jane Lusby (Nov 25 2020 at 00:00):

i guess,

view this post on Zulip Jane Lusby (Nov 25 2020 at 00:00):

go on?

view this post on Zulip Jane Lusby (Nov 25 2020 at 00:00):

like, how would you modify Try to manage this, and how does it differ from Box<dyn Error> and similar types

view this post on Zulip Yoshua Wuyts (Nov 30 2020 at 11:00):

Last time I tried try {} I remember it didn't infer types when I expected it to. Not sure if that's still the case tho.

view this post on Zulip Mario Carneiro (Nov 30 2020 at 11:22):

does break-to-labeled-block fall under this category? This is really the core functionality that I need when there are multiple try {} scopes in play at once. (Also break inside a closure, although that seems harder.)

view this post on Zulip Yoshua Wuyts (Nov 30 2020 at 12:59):

I think most of the other things on my wishlist for Try/ try {} are all future extensions:

view this post on Zulip Yoshua Wuyts (Nov 30 2020 at 13:06):

Particularly in Tide endpoint examples the combination of async + errors becomes real noisy. Example:

//! HTTP echo server

// current
let mut app = tide::new();
app.at("/echo").post(|req| async move { Ok(req)});
app.listen("127.0.0.1:8080").await?;
Ok(())

// desired
let mut app = tide::new();
app.at("/echo").post(async try |req| req);
app.listen("127.0.0.1:8080").await?;

view this post on Zulip Josh Triplett (Nov 30 2020 at 19:25):

In that particular case, it doesn't seem like try makes it any less noisy.

view this post on Zulip Josh Triplett (Nov 30 2020 at 19:25):

You remove Ok(req) in favor of req, but then have to add try.

view this post on Zulip Josh Triplett (Nov 30 2020 at 19:26):

It's not obvious why you need try closures for that, rather than just a try block.

view this post on Zulip scottmcm (Nov 30 2020 at 20:33):

Yoshua Wuyts said:

Last time I tried try {} I remember it didn't infer types when I expected it to. Not sure if that's still the case tho.

Yeah, ? loses the "result-ness" of things. I'd like to do something about that, though error-conversion makes it hard in general.

view this post on Zulip Josh Triplett (Nov 30 2020 at 20:53):

@scottmcm I'd like to see that as well, but I'm wondering if there's any forward-compatible way we could go ahead and start supporting try blocks now, even if they usually need some help figuring out their return type, and later figure out a way to do better inference.

view this post on Zulip Josh Triplett (Nov 30 2020 at 20:53):

What do you see as the current blockers for try blocks, if we don't try to improve inference?

view this post on Zulip Yoshua Wuyts (Dec 01 2020 at 11:26):

@Josh Triplett ah, I think there may be a difference between the experience reading and the experience writing
-- I agree they indeed look similar enough, but writing async |x| try { } instead of async try |x| feels messier. Mixing keywords in front of the closure, after the closure, brackets where a regular closure requires none. It'd be nice if eventually this could be smoothed out.

view this post on Zulip Josh Triplett (Dec 01 2020 at 16:04):

I understand, but I don't personally think that that motivates adding a new kind of closure.

view this post on Zulip Joshua Nelson (Dec 01 2020 at 16:38):

personally, I think async move { Ok(req) } is the most clear out of any of those

view this post on Zulip Joshua Nelson (Dec 01 2020 at 16:38):

but I can see how it would be annoying if you have to write it a lot

view this post on Zulip Josh Triplett (Dec 01 2020 at 16:39):

FWIW, I would be more amenable to the idea of omitting braces in specific circumstances than I would be towards introducing a new kind of closure.

view this post on Zulip Josh Triplett (Dec 01 2020 at 16:40):

For instance, async try {} rather than async { try { } }.

view this post on Zulip scottmcm (Dec 01 2020 at 18:28):

Josh Triplett said:

What do you see as the current blockers for try blocks, if we don't try to improve inference?

No hard blockers (given the possibility of edition changes), just forward hazards -- if we wanted the default to be more restrictive to be able to infer better, for example.

view this post on Zulip Joshua Nelson (Dec 01 2020 at 18:39):

personally I would love for try not to use Into for converting errors

view this post on Zulip Joshua Nelson (Dec 01 2020 at 18:39):

that's a backwards-compatible way to get rid of type inference issues and also decrease some of the codegen bloat

view this post on Zulip Josh Triplett (Dec 01 2020 at 19:56):

@Joshua Nelson That seems reasonable to me; as long as ? still uses Into, try doesn't need to.

view this post on Zulip scottmcm (Dec 01 2020 at 20:43):

try doesn't use Into today. All that try does is the ok-wrap (and where it breaks to)

view this post on Zulip scottmcm (Dec 01 2020 at 20:44):

I think it's the Into (well, From, technically) in the ? that needs to not happen to get the inference under control.


Last updated: Jan 29 2022 at 09:51 UTC