`try bikeshed`: What should the syntax be?

[scottmcm]

(Sub-issue of #149488)

Obviously bikeshed shouldn't literally be the syntax 🙃

Colon

Obviously the default choice for introducing types is a colon, like in let, leading to something like ``try : anyhow::Result<_> {`

However, the core trouble here is that let x: _ = and let x = are always the same, whereas try { and try: _ { would be different, as the former is homogeneous (rust-lang/rfcs#3721) and the latter heterogeneous. That inconsistency isn't great.

Arrow

Another option would be the closure-like try -> anyhow::Result<_> {, similar to || -> anyhow::Result<_> {.

At least to me that looks aesthetically nicer than the colon, but it has a similar problem: || { … } and || -> _ { … } are the same, so it doesn't give the "and there's a conversion of some sort" happening intuition.

As

Niko originally hypothesized this feature in the form of try as anyhow::Result<_> { … } back in #70941 (comment)

That's nice because it's already the case that x and x as _ are different -- the latter introduces a conversion of sorts, and as _ as _ never type-checks -- which gives a similar intuition to how try { … } and try as _ { … } would be different. Plus try as _ { try as _ { … }? } also doesn't compile for the same reason that as _ as _ doesn't compile.

Other words

Because try is the keyword and the other form is try {, anything that's not { would work -- it doesn't need to be a keyword. (This is why bikeshed is working on nightly.) So we're not limited to existing reserved words (like in or whatever) if you have a good idea.

[glaebhoerl]

• Is the try part set in stone? catch as anyhow::Result<_> { ... } reads a lot more cleanly. (To be clear, this would also make the unannotated one catch { ... } then, not two separate keywords.)

• My favored solution would be that the choice of desugaring simply depends on whether the try block is syntactically in a checked vs. synthesized position (in the sense of bidirectional typechecking). So let foo: Foo = try { ... }, return try { ... } (given annotated return type), foo(try { ... }), and so on: heterogeneous; let foo = try { ... }, try { ... }.foo(), and so on: homogeneous. (Then try: Foo { ... }, if we still want it, would just be sugar and work the same way as its let counterpart). I assume this is not being considered due to technical infeasibility or something like that?

[kennytm]

Is the try part set in stone?

This has been discussed to death back in rust-lang/rfcs#2388. The fact that try is a keyword and catch not pretty much tells the conclusion.

My favored solution would be that the choice of desugaring simply depends on whether the try block is syntactically in a checked vs. synthesized position

If the try { ... } block can switch between homogeneous and heterogeneous depending on the context I'd prefer not having this bikeshed syntax at all, and instead rely on type ascription type_ascribe!(try { ... }, anyhow::Result<_>). But yeah I doubt the type-checker algorithm is able to handle this kind of fallback.

[yoshuawuyts]

I spent some time this week writing up a post about a potential more general effect notation: An effect notation based on with-clauses. I don't yet know exactly how this would translate to the heterogenous try-block proposal specifically, but perhaps some of the insights might be readily applicable.

One observation I make in the post is that try can be thought of as a specialized variation of a co-routine. Where co-routines are just functions (routines) which "step out" to the caller rather than "step into" a callee. Rust already has a shorthand notation to describe functions in the form of Fn{,Once,Mut}() -> (). I don't think it would be entirely outrageous to try and model both the (heterogenous) try and gen features after that.

[scottmcm]

• I assume this is not being considered due to technical infeasibility or something like that?

The big complication to me is that because it's from a combination of things it mixes poorly with macros.

As the one calling foo!(try { … }) I expect that to be homogeneous and foo!(try bikeshed anyhow::Result<_> { … }) to be heterogeneous. If the former might be heterogeneous because it expanded out into let x: something = try { … }; that would, IMHO, be weird and confusing -- plus a strange footgun for macro authors.

Certainly if before we ship try bikeshed the types team and the new-solver team come up with a clever new system that allows it to default to homogeneous but allow heterogeneous when needed then that'd be great and we could replace both with just that -- where what you described would just work -- but there's no timeline or concrete plan for that right now, so I think it's fine to work on the "ask specifically" form now, and if we can make it often-unnecessary sometime later that's great.

[kennytm]

with a clever new system that allows it to default to homogeneous but allow heterogeneous

Actually I would suppose the context-aware try would default to heterogeneous and fallback to homogeneous if the former is found to be ambiguous. I picture that being similar to an integer literal ({integer}) by default allow any of u8 | i8 | ... | u128 | i128 but fallback to i32 whenever there is no unique solution.

[scottmcm]

default to heterogeneous and fallback to homogeneous if the former is found to be ambiguous

TBH I don't know how much of a difference there is between the two framings 🤷

[Kivooeo]

I think I like as more here, because it makes it feel like this form is actually doing something, not just adding a type annotation. : and -> both read more like "same thing, but typed", while try {} vs try as T {} are meaningfully different.

[liigo]

Nothing

just try anyhow::Result<_> { … }, i.e. try TYPE { ... }. (Should have a reason if this is not an option.)