Stream: t-lang

Topic: `try` block inference


rpjohnst (Mar 24 2020 at 18:43, on Zulip):

I'm not able to find the original discussion at this point, and I don't want to add to the noise in the tracking issue (https://github.com/rust-lang/rust/issues/31436), but was there ever any attempt to fix the try inference problem with an inference default?

rpjohnst (Mar 24 2020 at 18:44, on Zulip):

(also asked on discord but I guess people are here more now?)

nikomatsakis (Mar 24 2020 at 19:45, on Zulip):

I'm not aware of anyone trying that, perhaps because I would've discouraged any such attempt :)

nikomatsakis (Mar 24 2020 at 19:45, on Zulip):

Mostly because I have an allergic response to more inference fallback

nikomatsakis (Mar 24 2020 at 19:46, on Zulip):

It also comes pretty late in the type-checking pipeline so it's not a "great" user experience somehow, though we could conceptually make changes there

rpjohnst (Mar 24 2020 at 19:50, on Zulip):

ah thanks, that's what I was wondering. alternatively (based on recent discussion in the tracking issue) could it perhaps be inferred from any ?s within the block? or would that run into the same problems?

nikomatsakis (Mar 24 2020 at 19:55, on Zulip):

@rpjohnst well, it depends I suppose on the design of the Try that we ultimately wind up with

nikomatsakis (Mar 24 2020 at 19:55, on Zulip):

the current one makes the type of value being ?'d against irrelevant to the output type

nikomatsakis (Mar 24 2020 at 19:55, on Zulip):

I'm not very happy with the current design for a variety of reasons

nikomatsakis (Mar 24 2020 at 19:55, on Zulip):

Some of the earlier designs would have made it so that, in practice, there was more of a 1-to-1 relationship (e.g., a Result always had to use a Result in the output type, albeit potentially with a different error)

nikomatsakis (Mar 24 2020 at 19:56, on Zulip):

Though this was always going to be something that was inferred based on the extant impls, which we will do, but which is somewhat dicey (it causes problems for e.g. From)

nikomatsakis (Mar 24 2020 at 19:56, on Zulip):

though at this point we're pretty committed to that, the most we could ever do is to add an annotation to Into/From to disable inference for those particular traits

nikomatsakis (Mar 24 2020 at 19:56, on Zulip):

i'm not "up to speed" though with the latest proposals for the trait, @scottmcm was following up with that more than I

nikomatsakis (Mar 24 2020 at 19:57, on Zulip):

one could also imagine a syntax for try that requires the result type to be written explicitly

nikomatsakis (Mar 24 2020 at 19:57, on Zulip):

e.g. try { } implies Result, and try as Option<_> { .. } uses Option

nikomatsakis (Mar 24 2020 at 19:57, on Zulip):

or something like that

nikomatsakis (Mar 24 2020 at 19:57, on Zulip):

I... might favor that

rpjohnst (Mar 24 2020 at 19:57, on Zulip):

oh, that would have the same practical benefits as an inference fallback but without the implementation concerns?

nikomatsakis (Mar 24 2020 at 19:58, on Zulip):

well the main downside would be if you use try with Option types I guess, in which case it'd require annotation, but then today it requires annotation anyway

nikomatsakis (Mar 24 2020 at 19:58, on Zulip):

so I guess "yes" is the answer :)

nikomatsakis (Mar 24 2020 at 19:58, on Zulip):

there would be some contexts where it'd require strictly more annotation

rpjohnst (Mar 24 2020 at 19:58, on Zulip):

mostly I'm just trying to think through ways to let try {} work without forcing (nearly) every use site to write try: Result or whatever

nikomatsakis (Mar 24 2020 at 19:58, on Zulip):

nikomatsakis said:

there would be some contexts where it'd require strictly more annotation

though we could even address those

nikomatsakis (Mar 24 2020 at 19:58, on Zulip):

e.g., you could make it so that foo(try { ... }) takes the "expected type" from context, potentially.. hmm, not sure, that's a bit tricky-ish

nikomatsakis (Mar 24 2020 at 19:59, on Zulip):

but certainly plausible

nikomatsakis (Mar 24 2020 at 19:59, on Zulip):

rpjohnst said:

mostly I'm just trying to think through ways to let try {} work without forcing (nearly) every use site to write try: Result or whatever

yes this is indeed a good design goal

nikomatsakis (Mar 24 2020 at 19:59, on Zulip):

I'm pretty sure that uses of things like Option are distinctly secondary

nikomatsakis (Mar 24 2020 at 19:59, on Zulip):

and it feels "ok" to me to call them out

nikomatsakis (Mar 24 2020 at 19:59, on Zulip):

though I'd be happy with other solutions

scottmcm (Mar 24 2020 at 20:30, on Zulip):

Yeah, I think we should probably change it to more of a hybrid between the two solutions that were discussed in the RFC thread

scottmcm (Mar 24 2020 at 20:32, on Zulip):

Something like having the associated type for the Ok side, but with a place for more of a generic or carrier type thing for the Error side

scottmcm (Mar 24 2020 at 20:34, on Zulip):

There are a bunch of different ways that we could keep the "Result-ness" of things around

Last update: Jun 05 2020 at 23:15UTC