Repository navigation
Tracking Issue for try_trait_v2, A new design for the ? desugaring (RFC#3058) #84277
Description
This is a tracking issue for the RFC "try_trait_v2: A new design for the ? desugaring" (rust-lang/rfcs#3058).
The feature gate for the issue is #![feature(try_trait_v2)].
This obviates rust-lang/rfcs#1859, tracked in #42327.
About tracking issues
Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Steps
- Implement the RFC
- Add the new traits and impls
- Update the desugar in ast lowering
- Fixup all the tests
- Add nice error messages in inference
- Improve perf with enough MIR optimizations
-
Delete the old way after a bootstrap updateRemove theTryV2alias #88223
- Not strictly needed, but a mir-opt to simplify the matches would really help: LLVM/MIR optimizations to simplify the new RFC3058
?desugaring #85133 - Add more detailed documentation about how to implement and use the traits
- Decide whether to block return types that are
FromResidualbut notTry - Fix rustdoc to show the default type parameter on
FromResidualbetter (Issue rustdoc removes Try from <Self as Try>::Residual in std::ops::FromResidual #85454) - Before stabilizing, ensure that all uses of
Infallibleare either fine that way or have been replaced by! - Stabilizing this will allow people to implement
Iterator::try_fold- As part of stabilizing, document implementing try_fold for iterators (perhaps reopen Document implementing
try_foldfor iterators for internal iteration #62606) - Ensure that the default implementations of other things have the desired long-term DAG, since changing them is essentially impossible later. (Specifically, it would be nice to have
foldbe implemented in terms oftry_fold, so that both don't need to be overridden.)
- As part of stabilizing, document implementing try_fold for iterators (perhaps reopen Document implementing
- Adjust documentation (see instructions on rustc-dev-guide)
- Stabilization PR (see instructions on rustc-dev-guide)
Unresolved Questions
From RFC:
- What vocabulary should
Tryuse in the associated types/traits? Output+residual, continue+break, or something else entirely? - Is it ok for the two traits to be tied together closely, as outlined here, or should they be split up further to allow types that can be only-created or only-destructured?
From experience in nightly:
- Should there be a trait requirement on residuals of any kind? It's currently possible to accidentally be
FromResidualfrom a type that's never actually produced as a residual (Fix the types in one of theFromResidualimplementations rwf2/Rocket#1645). But that would add more friction for cases not using theFoo<!>pattern, so may not be worth it.- Given the trait in Make
array::{try_from_fn, try_map}andIterator::try_findgeneric overTry#91286, that might look like changing the associatedtype Residual;totype Residual: Residual<Self::Output>;.
- Given the trait in Make
Implementation history
- Basic traits and impls added, Add the
try_trait_v2library basics #84092 - Removing
try_traitfromstdarch, Remove#![feature(try_trait)]from a test stdarch#1142 - Implementing the desugaring, Implement the new desugaring from
try_trait_v2#84767
Activity
Auto merge of rust-lang#84767 - scottmcm:try_trait_actual, r=lcnr
Auto merge of #84767 - scottmcm:try_trait_actual, r=lcnr
artemii235 commentedon Jul 22, 2021
We have a problem in our project related to the new question mark desugaring. We use the
track_callerfeature inFrom::fromimplementation of the error types to collect stack traces with generics and auto and negative impl traits magic implemented by @sergeyboyko0791 (https://github.com/KomodoPlatform/atomicDEX-API/blob/mm2.1/mm2src/common/mm_error/mm_error.rs).After updating to the latest nightly toolchain this stack trace collection started to work differently. I've created a small project for the demo: https://github.com/artemii235/questionmark_track_caller_try_trait_v2
cargo +nightly-2021-05-17 runoutputsLocation { file: "src/main.rs", line: 18, col: 23 }as we expect.cargo +nightly-2021-07-18 runoutputsLocation { file: "/rustc/c7331d65bdbab1187f5a9b8f5b918248678ebdb9/library/core/src/result.rs", line: 1897, col: 27 }- thefrom_residualimplementation that is now used for?desugaring.Is there a way to make the track caller work the same way as it was before? Maybe we can use some workaround in our code?
Thanks in advance for any help!
cuviper commentedon Jul 23, 2021
That's interesting -- maybe
Result::from_residualcould also have#[track_caller]? But that may bloat a lot of callers in cases that won't ever use the data.thomaseizinger commentedon Jul 23, 2021
From the description:
@artemii235 Do you mind opening a separate issue?
artemii235 commentedon Jul 23, 2021
No objections at all 🙂 I've just created it #87401.
crlf0710 commentedon Jul 28, 2021
May i suggest changing
branchmethod's name to something else? When searching for methods, it's a little not obvious to seeOption::branchorResult::branchis not the method one should usually call...167 remaining items
valarauca commentedon Aug 20, 2026
If this isn't settled (according to OP it isn't). I would like this to not be the case, as it is extremely helpful.
Why?
One can setup an either-future (playground link). This permits doing async things, where the construction of the future is seperate from the underlying future.
In a nutshell it lets you separate:
A secondary useful effect is related to lifetimes.
Futures with lifetimes associations carry scheduling & running baggage. While in most cases, especially for non-trivial payloads (say HTTP post requests) passing bodies by reference can be useful. Presently, this is problematic (playground link) as passing your arguments by reference, creates this coupling.
While the
FromResidual& aforementioned either-future (playground link) machinery create a nice escape hatch for this. Permitting you to borrow while constructing/preparing a future, without coupling any errors (or synchronous actions) to the underlying future's execution: example (playground-link). As doing this withasynckey work (or de-sugaredasync).MusicalNinjaDad commentedon Aug 24, 2026
I've been asked, and agreed, to take the Point-of-Contact role for the related 2026 goal: rust-lang/goals#654
Feel free to reach out on zulip for any coordination related topics or overlaps with other needs/activities.
Rollup merge of rust-lang#162174 - MusicalNinjaDad:try_is_never, r=nn…
Rollup merge of rust-lang#162174 - MusicalNinjaDad:try_is_never, r=nn…
Rollup merge of rust-lang#162174 - MusicalNinjaDad:try_is_never, r=nn…
Unrolled build for #162174 in rollup 162284
Rollup merge of #162174 - MusicalNinjaDad:try_is_never, r=nnethercote
MusicalNinjaDad commentedon Sep 6, 2026
@rustbot label +I-lang-nominated
I'm the new project goal owner for rust-lang/goals#654 and am keen to help drive this forwards without stepping on anyone's toes. I'm acutely aware of both how much effort has gone into
Trytraits so far and how busy those involved are.I see the following points which are blocking and probably need more talking than coding in the near future. Before I start actively working them and reaching out to people, I'd like 5-10 minutes with t-lang to check whether there are any concerns:
Poll)try{}: What does homogeneity mean forPoll? #155368Output) (potentially useful for In-place initialization goals#395)Thanks,
Rollup merge of #162174 - MusicalNinjaDad:try_is_never, r=nnethercote
traviscross commentedon Sep 30, 2026
We discussed this in the lang call today. Thanks to @MusicalNinjaDad for picking up this important work and for checking in with us.